After porting jboss.org to use the popular PHP-based PostNuke community software, the JBoss Group decided to write their own J2EE port of PostNuke due to scalability problems with the PHP-based solution. An article on onjava.com describes their porting experiences and the architecture of the Nukes on JBoss CMS/Portal software.

Read Nukes: the Open Source Java CMS.

Oddly enough, after some hand-wringing about how "shocking" the PHP code was, they go on to generate their HTML with a bunch of print statements inside a servlet rather than using one of the many templating systems available. They also store all documents in an RDBMS so they have to be edited through a browser form. I've never used the PHP PostNuke, but it's hard to believe this is a step forward.

Perrin, I think the intention here was to do a straight port and make some improvements on the way, not necessarily completely rearchitect the thing. Although I agree that a templating system is pretty essential.

However, what's wrong with storing content in the DB? On TSS we store people's posts in the DB but actual articles are stored on within our filesystem. This is actually a headache as our EAR file is full of all this static content. We'd like to move away from this eventually, and putting in the DB is one potential option (with judicious use of mid-tier caching of course).

Floyd

How about using a XML DB to store the articles?

xml is good by why would you want to store textual content with an ID + a clob?
We had the same problem at work. Rather including the text files in the EAR we store the text in db. The file system just act like a cache...
 
  if (!(text in fs)) {
     pull text from db..
     and put into fs ..
  }
  ssi text..

this resolve the problem for not being need to care about the the huge armount of text files sitting in the fs..

The problem is that there are tons of great tools for working with files (editing, searching, versioning, syncing, diffing...) and none of them work with an RDBMS. It's one thing to store small chunks of text like comments in a database, but putting entire HTML documents in there usually leads to frustration down the road. It's better to store pointers to the file and metadata in the database than the actual file itself.

From the article, it sounds like Nukes is JBoss-dependent. Does anyone know for sure?

Kito D. Mann
kmann at virtua dot com
Author, JSF in Action

Yes, we are dependant from JBoss to use its highly advanced features.

JBoss-system : microkernel stuff
JBossCMP : tuning the queries

julien

For the record, I have spent quite a bit of time with Julien Viet over the email talking about our ideas for a better CMS engine and I think he deserves a lot more credit than he's getting here. I've pored over the guts of his codebase and seen a lot of what it offers. There are some definite gems in there relating to the JMX infrastructure--specifically relating to Juha's XMBean ideas (nonexistant outside of JBoss) and how they can be used for highly modular and easily configured designs.

Besides, the guy's only been working on it for an entire . . . what? Four months? By himself? And it's done already, running on an extremely high-traffic site and doing a damn good job for the most part. That's got to be worth something. So don't slam Julien Viet. He's a cool guy and he knows his shit. In fact, you'd all better shake his hand at JavaOne and buy him a beer. I know I certainly will.

(please flame me in a nice flaming chunk of hate mail if I'm wrong)

Cheers, Julien.

P.S. Why didn't you get any credit at the bottom of that article, Julien? I hate it when people don't get credit for their work.

--
N. Alex Rupp (n_alex_rupp at users dot sf dot net)

If you did bother to read by blog entry:

http://www.freeroller.net/page/ceperez/20030605#nukes_a_microcosm_of_jboss

that's exactly what I said about the JMX implementation, "innovative" and "something worthy of further study".

Of course the CMS folks are in uproar about the remark "no open source Java CMS engine source when we looked". So you can understand them for taking jabs at the Nukes implementation. That's equally unfair, after all alot of the web stuff are artifacts of the original implementation.

Of course, you brought up another intriguing question, if Julien wrote all of it, then why wasn't he given due credit?

This is just a typing mistake, not important.

julien

well done Julien. I am looking at nukes for my phase 2 of my site (comercial site - in 6 months when content has been established - outside of the scope of nukes).
I was originaly looking to run postnuke within jboss using jetty cgi servlet etc .... but nukes has saved the day.
Well Done.
What ..??? no FUD by trolf ???
Keep up the good work!
k

More on this topic from several weblogs:

http://www.freeroller.net/page/ceperez/20030605#nukes_a_microcosm_of_jboss
http://blogs.browsermedia.com/page/patrick/20030606#choosing_content_management
http://roller.anthonyeden.com/page/aeden/20030605#jboss_nukes_or_what_happens
http://blogs.atlassian.com/rebelutionary/archives/000145.html

Here is one more for ya, jmatt

For folks who want something that provides most (and soon more) of the functionality of PHPNuke, but build with a more Java-centric architecture, should look into the Javalobby Community Platform (JLCP):

http://www.jlcp.org

There's a very recent article describing the project and its philosophy and goals on Javalobby.com itself:

http://www.javalobby.org/members/nl/jlnews_20030604.html

There's also going to be a JavaOne session around the project, for folks who are going to be in the Bay Area next week.

Sorry, thought TSS would automatically hook up the URLs with links. For your double-clicking pleasure:

Javalobby Community Platform, http://www.jlcp.org

Community In A Can, http://www.javalobby.org/members/nl/jlnews_20030604.html

So far I know of

Jboss Nukes ( too Jboss specific -- my web hosting company does not use Jboss)

OpenCMS
JavaLobby

What else ?

Regards
-manish

I haven't tried either of these.

Check out Liferay (http://www.liferay.com)and BasicPortal (http://basicportal.sourceforge.net/).

After years spent making portals with BroadVision, Oracle Portal, Microsoft Content Management Server and so on I decided to put all things I liked of those blasoned portal/cms servers (too expensive for what people, including me, uses them for) in a single product. We (me and my group) are working on OpenFrame (openframe.sourceforge.net) with the goal of:
being simpler than Oracle Portal, more powerful than BroadVision, more customizable than... etc, etc.
On sourceforge there's still just an early release and an home page (I'm a bit ashamed of both, they are ugly!) - we decided to not publish until the first *serious* release is stable. First (public) release candidate is due by the end of the month.
Give it a look, it wouldn't hurt.

Some clarifications about the servlet style that many people don't like.

Postnuke is written in that way (yes for a template language, Postnuke guys use servlet style code), when a module is ported, we take it as is.
That means keep the same HTML and rewrite + optimize the PHP code into Java+EJB.

That's why there is so much servlet like in Nukes. Howerver that does not dictate the module developer to use it. Template engine like velocity can be used very well.

julien

Using JBoss for Nukes is cool and makes for an interesting excercise in producing mass market solutions with EJB technology. The problem is that it is expensive to host JBoss solutions on the internet so unfortunately its not likely to be as widely used as something that doesn't use the JBoss framework (like JLCP from javalobby).

Not true, I found cheap hosting for nukes. On www.jcentric.com you can have a Virtual Private Server for cheap. With that you have a full redhat with total control on it.

So I purchased a pro subscription (cheap less than 40 bucks per month) and got a nukes running really fastly with the preinstalled version. I did a wget on sourceforge, unzipped it and ran it.

julien

Just to mention that I completely agree with
 this article about open source CMS: there are currently too many open source java based initatives in the field of blogs, web cms, web portals and whatever is closely related to content management for too few developers/customers projects.

This was also said at OSCOM a few days ago. I have no problem with dozens of different projects that aims to different market niches. The main problem is to reinvent the wheel each time on the architecture level. Why not putting all our efforts on some Apache libraries (Slide; Cocoon; Lucene and soon the future reference implementation for the JSR 168 and 170) and then "fight" at the front end level with different "packages"? Python has Zope (& derivatives), PHP has Nuke (& derivatives), Java has... a dozen of unrelated open source CMS frameworks. Perhaps due to the same amount of various web application frameworks in Java (Struts, Turbine; Tapestry; Webwork;...)...

My 2 cts

Stéphane - Jahia.org - another open CMS/Portal initative.

I fully agree, drop jahia and join Nukes.

julien

i am totally against "putting all resources" into a hand full projects like cocoon, slide, etc.

the reasons:

* not all people/customers have the same requirements, environments and _taste_ and the requirements, environments and tastes are highly dynmaic

* as to reinventing the weel:
  - on the architectural level => think of it as "trial and error", i.e. the basic mechanism behind evolution
  - on the implementation level => as long as people provide modular sources and good documentation, fresh projects can use code nuggets of older projects, so the weel is not reinvented here.

* man-hours != project quality. Instead, most projects only need a few man-months to reach beta-quality. At this point the community desides. The project takes off or not. (The latter case does not necessarily equal failure, but it indicates that it does not fulfil requiremens of the mainstream better than existing software)


Bottom line: diversity is great, diversity and flexibility is the key for success of Open source. Flexibility also includes dropping a project and restarting from scratch if one feels it's necessary.

of course, the real super-star-projects are those who live and grow for years. However, i think nobody can predict generally which projects will succeed this way and which ones not. Therefore it is *impossible* to point out projects which should get all the attention and support.


However, one important thing is to increase the visiblity of existing projects, so that nobody starts a project just because he is not AWARE of another project that covers his/her needs. Even experienced developers have something troubles to gather info about the current state of the art. Sure, SF supports structured directories for this purpose, etc but it would be cool if somebody finds a way to further ease this process.

just my 2 cents.
joe