Well, JBoss 3.0 is old hat by now, but I've finally started playing with it again. Got it up and running on the home server. For some bizarre reason, it seems that I installed Kaffe, forgot to install The Sun JSK, and now JBoss is running. If it is really running under Kaffe, this is quite cool. I will post a follow up if it does in fact work.

But an interesting question is: what more needs to be done to get a completely Free version of JBoss up and running. What classes, what hacks to the build system etc.

I really need to get my mind around this JDO thing. The problem is I don't want to introduce yet another technology. The counter problem is that I don't want to reinvent JDO, and most of our optimizations seem to be leading that way.

Radnom Musings: Do JDO and Entity EJB solve different problems? Should we Wrap JDO with Entity beans in certain cases? Shoud we completely disregard Enitity beans and only Use JDO?

The problem with JAWS (JBoss CMP EJB implementation) is that Populating an entity is incredibly time expensive, on the border of 1/2 a second or so. For beans that that are short lived, this is not acceptable.

Still need to look into JBoss 3 to see if they've solved this. Bulk loading of entities is vital for better performance.

OK, SO at work I've started looking into moving from JBoss 2.4 to 3.0, and I want to use this as a place where I record what I've learned about it.

    The Hot deploy feature seems to be the biggest step forward. I'm not sure if it falls under the Java Management Extension (JMX) Architecture or what. AFAICT the old jboss.jcml has been replaced with putting smaller xml files into the deploy directory. I played around a little bit with the file for the Postgresql data source and got to the point where I could get it to deploy.

As I see it, this is the thing that has been missing from J2EE. ATG has a very nice architecture for configuring objects before they are deployed, as opposed to the JavaBean Architecture of JSP/Servlet API. Now, for any object that you need, you should be able to write a deployment script to store it in the JNDI namespace, and call it up.

I assume that these things will be accessed by JNDI lookups, and available from JSP code. Again, the braindead architechture of the JavaBean stuff may mean that you have to access them through custom tags, and that means late binding. Actually, that is OK, since it will push us to do stuff in the JBoss layer.