Extreme Java

Today mission: JBoss Portal. My first impression: negative. I’ve tryed its live demo and, after two minutes, I render it useless. How? Follow the steps:

1. Login as admin/admin
2. Go to the admin page
3. Remove the administration portlet

What you got? A portal with a layout that can’t be changed… That’s typical from JBoss community: they create a simple kernel and everything is extension. JBoss Application Server is a microkernel that manages JMX beans. Everything else is JMX. Likewise, JBoss Portal is just a portlet container. You need that ugly and unintuitive manager (as ugly and unintuitive as AS managers) to manage everything.

BTW, that management portlet does a lot of roundtrips to the server (yep, no AJAX). If you plan to use it on your server, create a page that contains only the manager portlet.

JBoss Portal 2.4 is off my list. I will try 2.6alpha2.

One of the most frustrating things I have tryed to do was to use a Java Portal. I haven’t found a JSR-168 compliant portal that could work at all. I have simple needs:

1. The portal must run on JBoss: I’m renting a shared JBoss server;
2. I need to put a “virtual-host” tag in every jboss-web.xml: this is how JBoss will map my domain to my applications;
3. I must have total control over JNDI/JMX naming conventions: “default” names are unacceptable, since other “clients” may want to use the same implementation;
4. The portal must NOT create any files on the filesystem: JBoss runs with an specific user that does not have write access to my private folders; and
5. Memory and CPU consumption must be light: obviously.

What I found:

• JBoss Portal:
  • Prós: Runs on JBoss (of course) and seems to be light
  • Cons: UGLY. Portal layout is defined with some weird arrows on an weird admin page
• Liferay
  • Pros: beautiful, lots of AJAX, lots of out-of-box portlets
  • Cons: invasive (needs to create a lot of files), eats CPU and memory like I eat chocolate and creates JMX in runtime (but does not release them on undeploy). “Professional” version (WAR) takes 30 minutes to deploy, “Enterprise” version (EAR) crashed the server (yikes) and requires a lot of customization to run on a shared server
• eXo
  • Pros: like Liferay, it’s beautiful, lots of AJAX, lots of portlets, and have an awesome “desktop” version
  • Cons: I have to compile EVERYTHING and do a lot of digging on its source to customize it to my needs. I simply can’t understand its compilation steps. Poor documentation. I could only test tomcat version, since I could not compile an working version…
• Gridsphere
  • Pros: dunno
  • Cons: runs only on Tomcat

This is amazing… With JavaEE version 5, I thought I could find a portal that could be deployed as easy as 1-2-3:

1. Download a WAR/EAR file;
2. Add some jboss-web.xml (to map JNDI and virtual host) - this is my “deployer” role on an JavaEE application lifecycle (as defined by JavaEE specs);
3. Deploy the file on server.

But step 1 is non-existent on portals like GridSphere. Step 2 becames steps 2.a to 2.zzzz on eXo and Liferay… Every portal wants the user to download a package bundled with tomcat/jboss or to follow this recipe:

1. Download source (WORA, anyone?)
2. Compile using Maven (yet-another-build-automation-tool)
3. Package using Maven (its “custom” tasks does not allow me to add a jboss-web.xml, since even web.xml is generated by it)
4. Deploy on tomcat (JBoss sometimes)

Why?? Is that hard to create a REAL JavaEE-compliant application that implements JSR-168??? That’s a thumb down to Java Portals (and JSR-168)…