JBoss 3.2.0 - A quick guide to changes
Having had to do things the hard way, here are a few tips about getting things moved over. And to think, I'd just got 3.0.6 operating on Thursday.
This text is more or less a copy of a post in Installation/configuration but I was asked to put this in the FAQ. It is intended to be a migration viewpoint of the changes rather than a detailed developer's view.
For starters, you will probably need to revisit all your EJB deployment descriptors. ejb-jar.xml now needs a DOCTYPE in it for JBoss to accept it. That was about 2 hours work in our case to go through all the descriptors - I guess it is reasonable but a big pain. The jboss.xml container definitions have also changed so you will need to revisit these if you have local definitions in your deployment descriptors. Otherwise you get IllegalState messages when you try to call your EJBs. We use jboss.xml mainly because we want to throttle the maximum number of beans created.
If you have MBeans that use the CategoryWriter, the Logger now drops the getCategoryWriter method so check on your use of that.
The data source configuration has also changed. In our case, the postgres-service.xml has disappeared to be replaced with postgres-ds.xml. It is simpler but some of the standard definitions supplied don't cover the minimum and maximum connection specs. Fill these in with <min-pool-size>1</min-pool-size> and <max-pool-size>10</max-pool-size> or whatever are your preferences.
The JMS configuration does not seem to have changed in any way. So that is one less migration headache.
The Tomcat and JBoss integration works fairly well. However, it doesn't support a ROOT context. Static content one directory down can be supported by putting the content in the deploy directory with a subdirectory of dirname.war, that also contains the WEB-INF directory and contents that you would expect for a proper WAR unpack for Tomcat. Your URL for the content will be http://yourserver:8080/dirname depending on whether you have the standard Tomcat port configuration.
Application response is faster with the integrated Tomcat-JBoss and at least the distribution is with a current Tomcat release. The tradeoff is that on startup, the system takes up much more physical memory (at least measured on a Linux system) than a separated JBoss 3.0.6 and Tomcat 4.1.24. I measured an RSS of 120Mb on start. After half a day of operation, this had dropped to 91Mb. The steady-state memory consumption is comparable with a separated configuration - however that initial Memory hump on startup does not occur with a separated installation. Anyway, I can still run this release reasonably with Redhat Linux 7.2 on a Pentium II 600MHz with 192M - unlike some commercial application servers. I hope JBoss doesn't become bloatware - the charter echoes the sentiments so I remain hopeful.
To configure your embedded Tomcat, the "server.xml" is in the jbossweb-tomcat.sar/META-INF/jboss-service.xml file. Most Tomcat server.xml tags work except for the Context definition. For your Tomcat certificate service, use something like keystoreFile="/conf/tomcat-cert.key" so that the certificate exists under your JBoss server instance's conf directory.
As of Tomcat 4.1.12, the default servlet context that serves unmapped servlets at http://myserver:8080/servlet/myunmappedservlet has been disabled. You can re-enable it if you wish but it does provide some possible security holes. This is all a bit beyond the scope of this document to cover but you can find more information here - http://www.fawcette.com/javapro/2002_11/online/servletsjsp_bkurniawan_11_08_02/default_pf.asp.
Remember to put an INFO threshold for your server.log appender in production - in log4j.xml. We generated 6 Mb of server.log output on startup with the default settings. After configuration, this dropped to 170Kb. It may not be much if you don't find yourself disk IO bound but our little demo server was struggling to get running.
One final thing - JBoss 3.2.0 complains if you don't properly close off your JDBC statements before you release connections back to the pool. This is a good thing. We picked up a possible bug with one of our more complex EJBs this way - well at least the code didn't look balanced and internally complete. So remember to close your statements/prepared statements, etc before you close your pooled connection (release it back to the pool).
