The quest for the Java Portal - inside Liferay, ep. 1

Liferay is running slowly on my JBoss server, crashes lots of times, but works. I have decided to play with its source code, maybe optimizing here and there. NetBeans Profiler is perfect for this job, but Liferay was written with Eclipse. NetBeans project importer worked, but it didn't help, because the Liferay source structure is monolithic. Since I had some free time this weekend, I'm manually converting the project. I converted about 15%, but look what I found so far:

• Tab size = 8. This is a HUGE tab size. Usually Java projects use 4. But this is a matter of taste.
  
• Actually, this is what I didn't found: documentation. No JavaDocs on classes I opened. I don't know how they can work on classes without any documentation. I always forget the use of any class I don't open often... :)
  
• Lots of third part libraries. And I'm not talking about the classic ones (like commons-logging). I found things like EasyConf (looks like Java Preferences API), OSCache (object cache that works on cluster environments) and Trone (yet another Collections framework). This explains the need for a bigger PermSize.

Liferay is a great product, but it really needs a good cleanup. Some of their optimization tricks creates overheads, like using Colt (yet another Collections framework - yes, they have TWO different YACF). Colt have some "sync collections" that works using the same synchronization principle as Hashtable and Vector. The question is: why they leave synchronization to the collection? What about using the "synchronized(xxx)" structure?

I will follow GrOG's tip (in last blog's comments): report my discoveries to the community. I preferred to report only after deciding which Portal I will use, but the decision is taking me too deep on each implementation I'm testing.

The quest for the Java Portal - JBoss Portal 2.6 live

No changes in JBoss Portal 20070307 nightly build. I saw JBoss ajax4jsf and JBoss Rich Faces and could not imagine why these incredibly cool components aren't used by JBoss Portal.

The quest for the Java Portal - JBoss Portal 2.6

JBoss Portal version 2.6 is still alpha, but I tryed it (since it claims to have a better user experience). I've downloaded its binary version - a JBoss' SAR archive. Out-of-box installation was a matter of copy datasource definition and the SAR file to my deploy folder.

It has the same limitations as 2.4:

• Delete the management portlet and your layout is locked;
• You can delete ALL users and have a nice NPE;
• The layout arrangement is not inline (needs the management portlet).

But, as I expected, it is pretty light. Unlink Liferay, the startup was really quick. If it was more AJAX-aware, JBoss Portal could be my portal of choice. Well, according to Grog, beta 1 will be released soon. I'm downloading a nightly build and I'll try it again.

The quest for the Java Portal - JBoss Portal

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.

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

NetBeans Code Folding

Tired of lose the fight against NetBeans MDR stuff, I decided to check out Code Folding. Pretty easy, indeed. I haven't done a full code fold example, but I was able to use NB 'editor-fold' pseudo-tag. Considering that you have the syntax support (see NBP Tutorials), the steps are:

1. On your SettingsInitializer, you need to add this line:
   

   settingsMap.put(SettingsNames.CODE_FOLDING_ENABLE, Boolean.TRUE);

   This is not obvious, but it is the most important step. Without it, you will never activate folding (this was hard to find out - like any other "non-layer.xml" stuff).
   


2. On your EditorKit, you need to implement the SyntaxUpdateTokens class and put it as a document property. Like this:
   

   public class MyEditorKit extends NbEditorKit {
       [ ... ]        
   
       protected void initDocument(BaseDocument doc) {
           doc.putProperty(SyntaxUpdateTokens.class, new SUT());
       }
       
       public class SUT extends SyntaxUpdateTokens {
   
           private List list;
           
           public void syntaxUpdateStart() {
               list = new ArrayList();
           }
   
           public List syntaxUpdateEnd() {
               return list;
           }
   
           public void syntaxUpdateToken(TokenID tid, TokenContextPath tcp,
                   int offset, int len) {
               if (tokenID == MyTokenContext.LINE_COMMENT) {
                   list.add(new TokenInfo(tid, tcp, offset, len));
               }
           }
       }
   }

   This will tell CustomFold which tokens it must use to find the pseudo-tag.
   


3. You need to create a three-line class to add the sidebar to the editor:
   

   public class MyFoldingSideBarFactory implements SideBarFactory {
       public JComponent createSideBar(JTextComponent jTextComponent) {
           return new CodeFoldingSideBar(jTextComponent);
       }
   }

   This is a weird step. I don't know why there's no ready-to-go class to do this job.
   


4. Now, glue everything in your layer.xml, under "Editor/MIME" folder:
   

   <folder name="SideBar">
       <file name="mypkg-MyFoldingSideBarFactory.instance"/>
       <attr name="org-netbeans-editor-GlyphGutter.instance
           /mypkg-MyFoldingSideBarFactory.instance"
           boolvalue="true"/>
   </folder>
   <folder name="FoldManager">
       <file name="org-netbeans-editor-CustomFoldManager$Factory.instance"/>
   </folder>

   FoldManager can be chained, just like the SideBar. Making it easy to add a "real" code fold based on tokens.
   

First post - current misson brief

This is the first post. I don't have any ready tip yet, but I'll post my "current mission":

I'm trying to understand how to add a new language to NetBeans. I want everything Java Editor has: Code Completion, Code Folding, etc. In theory, it's simple: I just need to add editor support and create a metamodel to feed other subsystems.

The first part is well explained on NetBeans Platform web site (actually, it's incredibly simple to add syntax highlight), but there aren't good docs about how the "Java Language Model" works on NB.

And now my problem: I've created a metadata repository using NetBeans' MDR stuff, but I simply do not know how to populate the repository using source files (and how to create source files from the repository).