Discussions

JBoss Inc. has announced the final Nukes on JBoss 1.0 release. Nukes aims to provide an easy-to-use, powerful and robust content management system. If you think about it, Nukes is more general and provides an infrastructure to enable collaboration among applications. The project lead, Julien Viet also answers some questions about his work.

Julien answers:

- What is Nukes?
- Why did you decide to create Nukes?
- Is Nukes a direct port of PostNuke or a rewrite?
- What templating systems can you use for Nukes modules?
- What features do you feel are most impressive in Nukes?
- Why did you use JMX as the core technology behind Nukes?
- How would I create a basic Nukes module?
- Describe how security works in Nukes. How would I secure that Nukes module?
- Are there any sites besides JBoss.com using Nukes? Which ones?
- What other features do you plan to see in 2.0?
- Where can I find other information, such as how to install and configure Nukes?
- What other open source projects have you contributed to?
- How impressed were the girls at the Cheetah when you told them that you were, indeed, the creator of Nukes? huh? :)

A survey with 25 answers is not what I call a very informative and interesting one... (and 13/25 dont know).
For me, currently, Java can't compete with other offers like Zope/Plone/Python when considering open source Content Management Systems... (its fun to note that the site with the survey is powered by Plone...).

I also took a brief look at JBossNuke some time ago, and was unimpressed both by HTML code in the wrong places/wrong way, and also the lack of attention to component oriented approaches. PHP is thriving on energy, the only problem it has is everyone is reinventing the wheel repetitively. Java can pull ahead on standards and interoperability, but this is not the way to do it.

> We initially tried PHP PostNuke for the website,
> but the performance was really bad and it did
> not scale at all.

What a lame comment. Everyone knows that this is pure bullshit and propaganda. Statements like the above have no value at all. If you critize something, try to give us some facts instead of just yelling 'we are the best' (jboss (tm)).

What facts? I know that PostNuke has some issues on scalability. But it doesn't mean that it cannot be made scalable. JBoss found some issues and decided that PHP is not scalable because PostNuke has some flaws in it's design. Something that Yahoo!, Sourceforge, Lufthansa etc. do not agree. I don't. Neither should anyone of you, IMHO. It seems like the other JBoss' coders are starting to sound like Mr. Fleury. I mean the attitude that keeps me away from any of their products.

> > TSS about scaling PHP applications. If you bother,
> > you'll find facts inside it.
>
> What facts? I know that PostNuke has some issues on scalability. But it doesn't mean that it cannot be made scalable. JBoss found some issues and decided that PHP is not scalable because PostNuke has some flaws in it's design. Something that Yahoo!, Sourceforge, Lufthansa etc. do not agree. I don't. Neither should anyone of you, IMHO. It seems like the other JBoss' coders are starting to sound like Mr. Fleury. I mean the attitude that keeps me away from any of their products.
>
> Some discussion related to this scalabiliity myth:
> http://www.onjava.com/pub/a/onjava/2003/10/15/php_scalability.html

Aaop, just so that you are absolutely understand Julien's comments: The article above talks about PHP scalability. I do not disagree that PHP can probably be made scalable. PostNuke is another story, unless they have done a complete rewrite.

What version of MySQL were you running?
What web-server (and version) were you running?
Did you execute PHP-code via web server module (including FastCGI etc.) or plain CGI?

Did you try to optimize MySQL indexes (and what kind of tables were you using)?

What version of PostNuke did you try to use?

(and why didn't you help to improve PostNuke project?)

I know that there is much larger sites than yours (jboss.org) that are running PostNuke and they are not experiencing the same problems as you. So it's quite hard to figure out what went wrong with your installation as you don't tell anything about it.

I have heard that PostNuke community is working on 0.8 release that is going to take advantage of ADOdb caching and Smarty Template compilation. They are also improving the SQL-queries.

If I can get answers to these, then I can understand your statements better.

There *have* been a great number of well-known problems with PHP nukes including security (especially this) and performance. We looked at hosts of tools for pushing simple content out to the web for the Open Source projects we host and develop. Our systems guys told me in no uncertain terms that PHP Nukes was out of the question because of those issues. I've been eagerly awaiting JBoss nukes to solve ths problem for us as many of the other solutions were a lot more than I needed.

So I guess I don't think it is propaganda. By the way, the Open Source Lab has no relationship currently with JBoss.org or the JBoss group. Nor do we use JBoss.

Jason McKerr
The Open Source Lab
"Open Minds. Open Doors. Open Source."

>
> > We initially tried PHP PostNuke for the website,
> > but the performance was really bad and it did
> > not scale at all.
>
> What a lame comment. Everyone knows that this is pure bullshit and propaganda. Statements like the above have no value at all. If you critize something, try to give us some facts instead of just yelling 'we are the best' (jboss (tm)).

It is not propaganda. This wasn't a knock on the performance of PHP iteself, but on PostNuke. Last, year, we switched www.jboss.org to use PHP PostNuke because we wanted the simple content management of the platform. Our website went from being able to handle at least 300 concurrent users with low CPU utilization, to not even scaling beyond 30 users with PostNuke. PostNuke, at least last year's version, did not do any caching what-so-ever and hit the database at least once with every page access.

That's fine. But that doesn't really answer my question. Did you choose GPL so any changes people made to Nukes/JBoss would have to be available for your tree? I don't really see much need for customization right now, but people may want to.

GPL doesn't really bother me. I was just curious, since most of the stuff JBG puts out is LGPL. Are most apps released on top of JBoss itself going to be GPL? Or is this just a one-shot?

He's overly aggresively fighting with competitive projects. All that propaganda about 'PHP Nukes sucks etc.', sending lawyers against Apache Foundation... I don't like it at all. It's definitely NOT the FOSS way...

I Already stated how fast is Jboss Nuke. Now that I digged in every line - I found that It does not scale and coding an extra module is a nightmare . Rendering should be left to JSP or any other component rather than an MBean or servlet . Image yourself building a Portal on JbossNuke... I will take ages to make a single portlet.
Faisal

I am following the development of Nukes right from the beginning.
For me it is a dead born child. If the guys at jboss would have taken the
ideas and principles from PostNuke and port this to Java then it might would
be a reasonable project. BUT they just took the code and changed it to Java.
If you look inside the code you will find PHP as comments (maybe fixed for the
v1.0 release but it was there in the last release I've downloaded).
My all time favourite is this code snippet:
Api api = getApi();

Oh, and this way how to render the pages. I thought that this way of
generating HTML (very nice hardcoded in your Java code) is now prohibited
by law? Maybe there are some intentions to include the goold old ECS from
jakarta?

Porting an application one on one from PHP to Java is just crap.

A wise man said:
If changing your programming language does not change your mind it is not
worth changing

> For me it is a dead born child. If the guys at jboss would have taken the
> ideas and principles from PostNuke and port this to Java then it might would
> be a reasonable project. BUT they just took the code and changed it to Java.
> If you look inside the code you will find PHP as comments (maybe fixed for the
> v1.0 release but it was there in the last release I've downloaded).
> My all time favourite is this code snippet:
> Api api = getApi();
>
> Oh, and this way how to render the pages. I thought that this way of
> generating HTML (very nice hardcoded in your Java code) is now prohibited
> by law? Maybe there are some intentions to include the goold old ECS from
> jakarta?
>
> Porting an application one on one from PHP to Java is just crap.
>
That's a bit hard comment. Look at it as a port project done the XP way: They gave us a free port of phpnukes that works very well after all ("show me the code"). OK for now the code has not a state-of-the-art architecture, but at least they delivered a good starting point, and with very good (external) quality, i.e. does the job and solves the scalibility problem. Now they can start refactoring their heart out ("keep it simple, then refactor to patterns"). The current (internal) quality is maybe so-so for the moment, but that is because it still reflects the PHP code structure, which of course lacks good OO coding style simply because that is not the way things are done in PHP.

You are right, we have delivered Nukes 1.0 with a stable architecture and we focused on the functionnalities : i.e the forums are here, the html module which is very good too.

To our mind this is what makes a CMS attractive, the plugged modules. We did not spend 90% of our time developing the core but we rather spent 90% of our time working on the modules.

The next releases : 1.1, 1.2, etc.. will bring additional modules because this is what makes a CMS !!!
A lot of CMS focuses on the architecture (which is important !) but have poor quality modules.

All the improvement we did on the core have always been driven by the needs given by the development of modules.

The next major release will see improvements on the core architecture, because now thanks to the modules we have, we know where are the area in the codebase that need changes/improvements. Already we have a template engine for several months adapted from PHPBB and we will give access to JSP in the near future. That means that most of the print() code has already been removed from the codebase.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.