WebSphere Portal isn’t as horrible as I thought…

I remember several years back I was flipping through the pay cable channels and lucked into a stand-up show by Paul Rodriguez at San Quentin prison.

Through the magic of Google, here’s a link to the DVD. The concert was in 1995, apparently, so I guess it really was a while ago.

As I recall, he did a fantastic job. Unlike a lot of comedians visiting prisons, he came across as quite comfortable, neither overly nervous nor condescending. It was great.

He did one excellent routine in particular about getting older and having to visit the doctor for a, shall we say, rather invasive test. He talked about how he had no choice but to try to be a man about it, rooting for them to go deeper, but then came the best part:

(paraphrasing from vague memory) “Just then, the worst possible thing in the world started to happen.”

(dramatic pause)

“It started to feel good.”

As you might imagine, that cracked everybody up.

I’ve been thinking about that routine a lot this week. What triggered such an odd memory? This week I just finished teaching a class in Portlet development in IBM’s Rational Application Developer (RAD6).

I was sorely tempted to blog about the class last week, but my comment might not have been diplomatic given that one of the students this week might stumble across my blog. Last week I wound up blowing two full days just installing RAD6, then updating it, then installing the WebSphere Portal Server 5.1 test environment. As I discovered, I had to do the multi-hour installs in that order, too, or the server wouldn’t start.

I mean that literally, by the way. I lost two full days just to the installation and diagnosing bizarre errors. Then, I got to my class this week, only to find that the installed test server in RAD6 wouldn’t start either. That basically meant all of Monday was going to be shot, even assuming I could get the thing to work at all. As Bill Simmons would say, not good times.

Fortunately (?), half the class (okay, two of the four, and maybe a third also) didn’t have the proper background for this course. Therefore I had a fallback position for Monday. I could spend the day in a good, solid Java review, complete with a discussion of server-side concepts, web applications, and so on, and use the actual courseware just for the background motivation and product description sections. I’ve been doing this stuff for a while now; I knew I could do something very productive for this group of students for one day of a five day class. That’s about all the slack I had, though.

All the while, I was uninstalling, downloading, and installing the software, and swearing that I would never, under any circumstances, ever be stupid enough to agree to deal with this horrible, buggy, massive IBM software again. My frustration with IBM has been building up for months now, and this was the worst possible situation for me.

As it turned out, the students really did need the background and were glad for the review, not to mention the examples I went through. I made it as interactive as possible, even though I didn’t have actual workshops for them to do. We got through it.

Then they left, and it was time to start the install/update process. Other circumstances were forcing me to leave by 5 pm, but I could get everything started and come back later in the evening to babysit the install and switch disks when necessary.

There were some bumps along the way, but finally, at about 1:30 am, everything worked. I at least had a working product, so the course could continue. I think the good image was successfully distributed to the student machines by 2:30 or 3 am, so I could crash until class started again at 8.

We then worked our way through the materials. I did a lot of hand-holding on the labs, doing them with the students interactively in many cases. That re-claimed some time, and helped the students see the forest for the trees.

By about Thursday afternoon, though, the strangest thing started to happen. Maybe it was the fatigue, or maybe I’d worked through the exercises just enough times for the concepts to really sink in, but just like Paul Rodriguez above, I had a bizarre reaction.

For the first time, I started to actually like WebSphere portlets.

The code involves a complicated combination of API calls, JSP custom tag libraries, and XML configuration files, not to mention working with services in the portlet container. The whole system has a nasty learning curve. But suddenly I just kind of “got it” and it didn’t all seem so bad any more.

I’m still blown away by this. I now thinking it might be worth it to install RAD7 and WPS 6 and really dig into the JSR 168 spec and write a portal for my own site. I may actually do that, too, despite the fact that there isn’t yet a good redbook available describing the process. I can almost see the benefits of working with what I would have described last week as a frustrating, dead-end technology.

As I tell my students, I’m wrong a lot, but I don’t stay wrong.

I haven’t decided on the details. I may experiment with JBoss portal server instead, or even the Sun app server. But a week ago you couldn’t have forced me to deal with portlets, and certainly not with IBM. Now I’m thinking about freeing up some time in July to see what I can do with them.

First I have to get used to the horrible feeling that this stuff is starting to feel good. 😉

The Spring Framework outranks private

I’ve been using the Spring framework for about a year now (or maybe more — it’s amazing how fast time goes by these days). I’ve also been teaching courses in it using Capstone Courseware materials.

As is normal with Capstone materials, they tend to skip quickly through the “Hello, World!” version of whatever technology they’re discussing, preferring to go on to applications that much more closely represent the real world. That way they can discuss subtleties and best practices while still communicating the basics.

A simple example is the way Spring can enforce the Singleton design pattern or not, regardless of the way the underlying Java bean is written. Say we have a Java bean that looks like:

public class MyBean {  private static final MyBean INSTANCE = new MyBean();

  private MyBean() {}

public static MyBean getInstance() {

    return INSTANCE;

  }

}

MyBean is a classic example of a Singleton. It has a private constructor, a static attribute to hold the shared instance, and a public static getter method to return it. As far as Java code is concerned, there will never be more than one instance of this class.

Spring gets along with singletons quite well. In fact, by default all Spring-managed beans are singletons. The fun part, though, is when we tell Spring that this bean is to use scope=”prototype”, implying that it should return a separate instance each time a bean is requested.

<beans xmlns=…>
<bean id=”MyBean” class=”cc.beans.MyBean”
factory-method=”getInstance” scope=”prototype” />
/>

The question is, what happens in the code when factory.getBean(“MyBean”) is called twice? Does Spring return two references to the same object (rejecting the “prototype” designation) or does it return two separate instances (rejecting the private constructor)? Who wins?

Spring does, which probably doesn’t come as much of a surprise to anyone who has played with reflection before. All you need to do is to get the Class reference for the bean, retrieve the private constructor, and call setAccessible(true) on it and it’s yours. Spring does what it’s told to do, working around any supposed limitations in the Java code.

That’s either troubling, or pretty cool, depending on your point of view. What I can say is that it comes as quite a surprise for most students in class.

Of course, my real point is that the Capstone materials discuss this case in detail, which is not necessarily the sort of issue you’d expect to see in a training course.

The materials talk about a wide range of Spring issues, including major sections on the web (MVC) framework, the DAO layer (with templates), and a bit about integrating with ORM tools.  The bottom line is that after having taught that class probably a dozen times in the past eight or nine months, I felt I had a pretty good handle on the framework.

Well, yes and no.

(Or, as I tell my students, “that turns out not to be the case.”  The phrase “that turns out not to be the case” is the most diplomatic way to tell your boss he’s completely wrong.  You can even preface it with “I can see why you might think that, but” if you like.  Try not to roll your eyes while doing so.)

The other day, I attended a meeting of our local Connecticut Java Users Group.   The meeting featured a presentation by Mark Fisher, a consultant with Interface21, the creators of the framework itself.  I knew I wanted to see that, because even if he spent all his time talking about areas I’ve already used, I knew he’d say lots of things I didn’t know.

I’ll say more about that soon.  This post is getting rather long.

When is EJB not Java EE?

The answer is, when it’s and EJB3 plug-in inside JBoss 4.

I’ve been playing with the EJB3 spec a lot recently, especially working with the Java Persistence API (JPA) portion for entities. I’ve said it before here, but I’ll say it again — I really like the way it’s put together.

(With one exception, of course, and I’ve talked about that, too. Someday someone will explain to me why the powers that be decided to make unidirectional one-to-many relationships impossible to implement with two tables related by a simple foreign key. My Order class has a collection of OrderLine instances. Why in the world should my OrderLine class have to know what Order it is a part of just so I can use the @ManyToOne annotation in the OrderLine class?? Or, equally silly, why should I have to use a link table in the database to connect Orders to OrderLines when a simple foreign key will do? Please, someone enlighten me.)

When I helped write the EJB 3.0 courseware for Capstone Courseware, we needed a container that supported the spec.  At the time, that meant the Java EE reference implementation — the Sun Java Application Server, also known as Glassfish.

Now, Glassfish is actually a pretty slick server. I like it, especially when compared to earlier versions of the reference implementation. I still plan to eventually move my site to it, once I get a free moment. The thing is, though, it has essentially zero market share.

Admittedly, I don’t actually have data to back that up. I only know what I encounter when I move from company to company in my training classes and occasional consulting engagements. My sense is that, sadly, WebSphere is still the market leader, though they must be losing market share as the new Java EE 5 spec gains popularity. I still meet a fair number of clients who love WebLogic, for good reason. Recently I did an Ajax class at a company that used Oracle 10g AS, which looks solid as well.

Ironically, given that they’re such a database company, Oracle’s commitment to Java is evident on many fronts. One of which, relevant for my purposes, is that by far my favorite EJB 3.0 book, Pro EJB3, was co-written by two Oracle employees, Mike Keith (the co-spec lead) and Merrick Schinariol, the lead engineer for Oracle’s EJB 3 offering. Of course, they better than anyone would be able to explain the bizarre unidirectional many-to-one problem described above, but that’s a different question.

I increasingly encounter companies that use the definitive open-source database, JBoss. Sure, Glassfish is open source too, but it’s taking time to catch on. The Apache foundation has Geronimo, but it’s still awfully new.  Most developers I encounter haven’t yet heard of it, much less considered adopting it.  JBoss, though, shows up in more and more companies. I don’t know if that has anything to do with the fact that it’s now a division of Red Hat or not, but there it is.

I’ve been using JBoss for a few years now, off and on. I really liked the book JBoss at Work and have even sent Scott Davis fan-boy email about it. 🙂 That book used a very early version of JBoss 4.0 and built an increasingly sophisticated application from the ground up. Maintenance is a breeze, configuration is easy, and performance seems to be fine, though I admit I haven’t had cause to push it hard.

That brings me, at long last, to my subject line. We would like to port our EJB 3.0 courseware to JBoss. Not that there’s anything wrong with Glassfish, but a lot of potential clients already use JBoss and they’re exactly the sort of people who like to adopt innovations like EJB 3. Sounds like a win all around.

Even better, the latest version of the O’Reilly book on EJBs (Enterprise JavaBeans 3.0, 5th edition) is now co-authored by Richard Monson-Haefel (of course) and Bill Burke. According to the author bios, Mr. Burke is the chief architect for JBoss, which is really saying something. The book even has a “JBoss workbook” built in, full of example programs to learn EJB 3.0.

So, I naively thought, I’ll just build one of our EAR files in our courseware, configure an appropriate datasource in JBoss, pop it into the server/default/deploy directory, and watch the magic happen.

Except it didn’t. Nothing happened, actually. The web tier ran and loaded all the JSPs and servlets, but no data was to be found.

The first thing I checked was to see that I had the right version of JBoss. The book recommends version 4.0.*, with the EJB 3.0 plug-in. Recently JBoss released version 4.2, which already had the EJB plug-in included, so I grabbed that. It still didn’t work.

I checked that the datasource was operational. Yup, no problem there.

The code compiled cleanly, and all the JSPs were displaying, just no data.

At long last, rooting around in the forums at JBoss, I discovered the problem. Here it is, in a nutshell:

JBoss 4.* is not a Java EE 5 container. It’s still just an old J2EE 1.4 container, with a plug-in to handle the EJB 3.0 stuff.

In practice, that meant that my nice little initialization servlet, which relied on dependency injection (the sweet @EJB annotation) to access the stateless session bean I used to get all the data, was coming up empty. No dependency injection, so no access to the bean, so ultimately no data. It’s back to the Bad Old Days of JNDI lookups, and I loath JNDI with a deep and abiding passion I normally reserve for airport security lines, patent trolls, and the New York Yankees.

My reactions to this realization were:

1. Duh. I knew that JBoss 4 was a J2EE container.   I’ve known it for years.  I hate when I have to learn the same lesson over and over again.  Duh, and duh again.

2. What the heck are they doing writing a book (with a JBoss workbook, no less, designed to be deployed on JBoss 4) on the EJB 3.0 spec if the app server doesn’t even support Java EE 5?

So I went to my downloaded code associated with the workbook, and what did I find? Lo and behold, they skipped the entire web tier! There ain’t a bloody servlet or JSP in the bunch. Every example, and I mean every single example, uses a client side Java class with a main method in it to access the EJBs. I mean, why not? After all, nobody ever does that in practice. They have to, though, because they can’t support the web tier normally associated with the Java EE 5 spec.

The natural move for us, therefore, is either rewrite our own web tier examples to use JNDI, or wait for JBoss to finally release JBoss 5, which is a Java EE 5 container. As you might imagine, I decided to download JBoss 5.0.0Beta2.

I don’t normally do that. Beta software makes me nervous. I’m very reluctant to recommend that a client classroom set up beta software, especially when I know I’m not going to be there to fix any problems. Still, if it’s truly a Java EE 5 container, and we really are relying on the spec, then everything ought to work right out of the box, right?

The answer is, yes and no.  I had some issues with the JDK version (it turns out that JBoss 5 doesn’t yet support JDK 1.6, which is the default in Glassfish), but once I resolved that my simple application worked fine.  My more complex application failed due to some constraint violation that I’m still trying to track down.

Of course, none of the apps work in JBoss 4 without additional modifications.  We’re currently evaluating whether the effort to do that is worth it or not.  I suspect not, especially when JBoss 5 is already out in beta.  The release version shouldn’t be too long in coming.

That also means that within a few months, I expect to see a version of JBoss, WebLogic, Oracle AS, Glassfish, and Geronimo all supporting the Java EE 5 specification.  The one major hold out will then be WebSphere.  Of course, as several IBMers have recently told me, according to their party line (1) IBM is not a technology driven company (!) and (2) their customers don’t want the new Java EE 5 spec anyway.

That’s a rather self-fulfilling prophecy, I’d say.  If I want Java EE 5, and I do, I know to avoid IBM.

Fortunately, soon that will leave me with lots of choices.  Now that MyEclipse 5.5 is out, I also have a development environment that supports the spec, too, and I’m sure Netbeans 6 will do the same.

In the meantime, I’ll stick with Glassfish.  The J2EE/EJB3 hybrid offered by JBoss causes me as many problems as it solves at the moment.

%d bloggers like this: