Blogging Roller

Red Hat has released another Java product: the Red Hat Enterprise Portal Server. The product seems to be closely related to the Redhat Content Management System (formerly the ArsDigita Community System). I say this because the whitepaper was written by former ArsDigita employees (Jim Parsons and Richard Li) and the process for developing a portlet involves writing PDL. The product includes porlets for discussion forum, document management, resource scheduling, tasks, bookmarking, and chat.

Given the anti-Java bias that I have noticed among many Linux devotees (and especially on Slashdot) over the years, I find it interesting and encouraging that all of the "Red Hat Enterprise Applications" (all two of them) are pure Java. Also, the Red Hat Web Application Framework is Java.

For a number of reasons, I'm trying to come up to speed on Portal technology and the status of the Java Portlet API specification. I've done a little research and this is what I have gathered so far. Your comments and corrections are welcome.

What is a Portal?

A Portal is a web site that provies a starting point for access to information and applications. Registered users of a Portal are able to create their own personal views of the Portal and are able to customize both the content and layout of these views. A Portal Server provides the infrastructure for building a Portal. A Portlet is a component that plugs into a Portal Server and may then be included in a users personal views.

The Porlet API specification

The Java community has been working to standardize Portal technology for years now. So far there have been three JSR's for a Portlet API spec, JSR-162 which was withdrawn, JSR-167 which was withdrawn, and now JSR-168 which has been cooking for over a year now. JSR-168 is still private, but a public draft is expected any day now.

The Portlet API specification will make Portlets the fundamental unit of execution in a Portal Server just as the Serlvet API made Servlets the fundamental unit of execution in a Web Application Server. If you write your Portlet using the Portlet API, you'll be able to deploy it without code changes to any standard Java Portal Server just as you can deploy a Servlet to any Java Web Application Server.

Portal Servers and the Reference Implementation

The abscence of a Portal Server standard has not stopped the big J2EE players from pushing ahead with Portal Server products. Here is a quick summary of the offerings from the big players:

• Jakarta: Jetspeed - Based on the Turbine Framework. Javadocs.
• IBM: Websphere Portal - based on Jetspeed. Has it's own Portlet interface. Javadocs.
• BEA: Weblogic Portal - has it's own Portlet interface. Javadocs.
• Sun: Sun One Portal Server - doesn't define a Porlet interface. Javadocs.

Every Java spec is accompanied by a Reference Implementation (RI) and often the RI is released as an open source product.  Stefan Hepper of IBM, who is the Specification Lead for the Portlet API has proposed a new Jakarta sub-project called Pluto to develop an RI for the Portlet API. Pluto will be implemented using technology from the existing Jakarta Jetspeed product. Jetspeed committer Andy Oliver has done a nice job of summarizing the various mailing lists discussions concerning Pluto on the Pluto Talk Page.

Speculation

The Portlet API is still a secret guarded by the Java Community Process, but it is likely that the final API will look a lot like the Websphere Portal's API. After all, the specification lead works for IBM, Jetspeed is favored for the RI, and the Websphere Portal is based on Jetspeed. Based on this speculation, the best source for information on Portlet development is probably IBM's Websphere Portal Zone.  There you will find a recent interview with the lead architect of the Websphere Portal team, a very recently revised Portlet Development Guide, and an article on Developing a Struts Application for Websphere Portal 4.2.

Update: Floyd Marinescu wrote in to recommend a ServerSide article Portal Standards by Thomas Schaeck and Portlet API spec lead Steffan Hepper.

is available for <a href= "http://download2.eclipse.org/downloads/drops/R-2.1-200303272130/index.php">download.

Matthew Porter: Right now, I really want to blog about the way we manage Hibernate sessions in JLCP. My problem with the currently suggested Hibernate patterns was that they broke fine-grained DAOs, notabley in unit tests and when DAOs call other DAOs. I also did not like the non-OO nature of all the static methods. Until then, check out the HibernateSessionManager and HibernateSession in the code.

I really want you to blog about that too.

Chris Grindstaff will be giving an in-depth tutorial at the RTP Websphere Users Group tomorrow night, March 25, 2003. Details are on the RTP-WUG meeting page.

Sang Shin's slides (with speaker notes) from the TechEngage Dot-Net vs. J2EE shootout are online on the RTP-WUG download page.

Simon Brown: As authors, many of us are now in the situation where our work may never be published, or at least published in the form that we expected. Of course this isn't good, but don't forget about those staff at Wrox that have lost their jobs - they are in a much worse position than ourselves. I wish them all the luck for future.

alang: What a load of ill-conceived, patronising, self-serving and naive poppy-cock!

There have been <a href= "http://www.raibledesigns.com/page/rd/20030315#re_wrox_going_under">numerous weblog posts and news articles about the demise of WROX Press. This is sad news, but I'm not giving up on Professional JSP 2.0 yet. There is still some small chance that another publisher will pick up the book or that the authors will band together to publish the book. Hopefully, I'll know the fate of my chapters (Data Access with JDBC and Performance and Debugging) in the next couple of weeks.

No matter what and regardless of the whip count in the security council, blogger Stuart Halloway will be talking Java Classloaders tonight at the Triangle Java Users Group Meeting. Here is the scoop:

Java's class loader architecture provides a dynamic and extensible mechanism for building applications. You will learn how to use class loaders to deploy multiple versions of classes side-by-side in the same VM, and how to redeploy components withtout shutting down servers. You will also learn how to troubleshoot class loading problems such as inversion. You will learn to use the context class loader to correctly implement factory methods, and how to load non-code resources. [more...]

The shootout was a bit too long and a little too fluffy, but I enjoyed it. I took 20 pages of notes and I will probably write them up for you later but for right now, I'll just give you some quotes from the J2EE team:

Mark Fleury: The worst dog of them all is SOAP.

Sang Shin: Security is not an industry problem, it is a Microsoft problem.

Mark Fleury: C# to be the number one language in two years: give me a freaking break!

Mark Fleury: JBoss is a responsible, moral, and open player.

Sang Shin: Web services is like teenage sex, everybody is talking about it but nobody is doing it.

Sang Shin: My grandmother called me last night to tell me that she is doing web services.

Mark Fleury: ADO sucks, Dot-Net caching is not there.

Greg Ackerman: C# is great, very Java like.

eclipse.exe -vmargs -Xverify:none -XX:+UseParallelGC -XX:PermSize=20M  
 -XX:MaxNewSize=32M -XX:NewSize=32M -Xmx96m -Xms96m

Sosume applies some new GC configuration settings, written about in JavaWorld and recommended for Netbeans to improve Eclipse performance in his post: Improving Eclipse performance by using vm arguments. I'm trying these settings myself now, but with -Xmx256m.

Ted explains how to plug JRocket into an existing JDK 1.4.1 JRE:

Ted Neward: First, I created a subdirectory in my standard JDK 1.4.1 install structure, j2sdk1.4.1/jre/bin/jrockit. Into this directory I copied the jvm.dll and Xusage.txt files that came from JRockit itself. Then, after adding a line "-jrockit KNOWN" into my JDK 1.4.1's jvm.cfg file (so that the launcher would recognize "-jrockit" as a viable command-line option), I fired up the standard Sun JDK java launcher with the command line "java -jrockit Hello". Sure enough, it worked.

From Computer World's interview with BEA's CEO Alfred Chuang:

What Linux trends are you seeing with BEA software?

Huge adoption curve climbing very fast for BEA over the last six to nine months. A lot of focus in the financial services marketplace, where there's a lot of experimentation and initial deployment going on with Linux on Intel. And I think the motivation in that arena is simplification and cost reduction, so they are looking to buy significantly less expensive hardware.

What's the breakdown of platforms on which BEA software is running?

About 50% is on Sun, and about 23%, 24% is on Hewlett-Packard. Hewlett-Packard has both Intel and non-Intel platforms in there. And then it drops off pretty quick. IBM hardware, I think, is 5% or 7%. In some countries, we sell a lot of IBM's hardware.

What about the Linux operating system?

Linux is around the 15% to 20% range, which has climbed pretty quickly.

Get 'em while they're hot. The Server Side reports that Sun has finally released <a href= "http://jcp.org/aboutJava/communityprocess/final/jsr031/index.html">JAXB 1.0. The JAXB reference implementation <a href= "http://java.sun.com/webservices/docs/1.1/ReleaseNotes.html#redistribute">is redistributable, but is it open source?

The Server Side also reports that Sun has released Java Server Faces (JSF) Early Access 3, a tutorial, and a public draft of the JSF spec.

As usual, Matt is on top of the Jakarta news. He notes that new Tomcat 5.0.1 alpha and Ant 1.5.2 are both available for download.

<a href= "http://www.computerworld.com/developmenttopics/development/java/story/0,10801,78943,00.html">Computer World summarizes the Meta Group study by writing that Borland, IBM, and Oracle are the "clear leaders" while Sun and Jetbrains are the "distant challengers."

Looks like another great Eclipse-oriented talk at the Research Triangle Park Websphere Users Group (RTP-WUG) meeting Tuesday. Sridhar Iyengar of IBM and Randy Miller of TogetherSoft will speak about Model Driven Architecture and the Eclipse Modelling Framework. Full details on the RTP-WUG web site.

I found this very interesting read on the history of AWT, Swing, and SWT fom an undisclosed source via Roller user <a href= "http://blog.xesoft.com/page/jon.lipsky/20030221#a_good_read_about_history">Jon Lipsky's blog. Here is a tasty excerpt:

Alan Williamson's mysterious "source close to IBM": At IBM we hated Swing from day one. Big, buggy, and looks [like] crap. Initially our tools such as VisualAge for Java were all written in Smalltalk ( which used native widgets ) so when we started to migrate these to a Java codebase we need a widget set. All of the IBM developers are the same crowd who used to work with Smalltalk, and we reluctantly under management orders built our WebSphere Studio tools using Swing. It was a terrible, buggy, monster. In our initial previews when it was demo'd against Microsoft Visual Studio products all our users hated it just because of how it looked, never mind what it let you do. Most shoppers don't like to get in car that looks and smells terrible, even if it does have a nice engine.

UPDATE: <a href= "http://blog.xesoft.com/page/jon.lipsky/20030221#a_good_read_no_truth">Jon Lipsky was contacted by somebody at Sun who claims there are many and major inaccuracies in the above story.

(via Lance) This quote from Free Software Foundation lawyer Eben Moglen seems to clarify the issue of using an LGPL jar in a non-GPL application (such as Roller). As long as the jar is LGPL, rather than GPL, you can include it in your application and then license your application however you choose. Here is the key quote:

Eben Moglen: If the author of the other code had chosen to release his JAR under the Lesser GPL, your contribution to the combined work could be released under any license of your choosing, but by releasing under GPL he or she chose to invoke the principle of "share and share alike."

Some conversations at the last RTP bloggers lunch left some doubt in my mind about LGPL, but the above quote clears it up nicely.