Extreme Java When vanilla Java is not enough

6Mar/070

Thumbs down to Java Portals

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)...

Comments (0) Trackbacks (0)

No comments yet.


Leave a comment

(required)


*

No trackbacks yet.