[opencms-dev] Changes to make OpenCms work properly on Jboss (or probably any other app server)

[Sverker Abrahamsson]

Hi Alexander and all others,
I first started to look at OpenCms about 1.5 years ago for using with an application running on a Jboss server but OpenCms, although nice in many ways, did not cooperate that well with Jboss. I was looking into making it behave more in the J2EE way but run out of time.

I've kept an eye on the development since then, testing the alphas as they were released and now I have a new project where I'm interested to use OpenCms for the frontend. Again the application is running on Jboss so I started to look into how to integrate OpenCms.

I discovered the following problems:
  a.. OpenCms "hijack" System.out and System.err while the setup wizard run to capture the output when importing workplace. That is not acceptable since it steal all console output from Jboss. I have worked it through so that instead of redirecting System.out and System.err to a pipe, a PrintWriter directed to the pipe is passed along to all neccesary objects.
  b.. When OpenCms was set up, all logging stoped working including the console. That turned out to be due to the log4j configuration in opencms.properties, if used it overide log4j configuration of Jboss. It was quite easy to solve, just set log.log4j.configuration property to empty and OpenCms will not set it's own logging configuration. Instead setup logging in Jboss log4j.xml. I also added a property log.prefix to be able to separate logging from two different OpenCms instances running in the same app server.
  c.. Jboss unpacks deployed packages such as war files to a temporary directory and run them from there. It gives them a name like tmp34324opencms-exp.war. I added some code to CmsSystemInfo.init to extract the correct name of the webapp (in this case opencms). I can't figure out exactly how the context path work though to deploy to root context, I thought setting WebApplicationContext would do the trick but then all links are generated without the host part. I temporary solved it by setting DefaultWebApplication to the same as the webapp name. I need support for this since I need to deploy as part of an ear so that I can use separate class loaders for each ear file. Otherwise deploying two applications using OpenCms would crash if they don't use the exact same class files.
  d.. Since Jboss unpack the war file to a temporary directory, it cause a problem for OpenCms since it changes e.g. it's configuration files when the setup wizard run, index files etc. The solution was to add a context parameter to web.xml called DataDir which control where OpenCms keep it's data. If not set it will be WEB-INF as before but I set it to ${jboss.server.data.dir}/opencms to get all data files under ${jboss.dir}/server/default/data (if I run with the default configuration). I can then easily have different instances of OpenCms use different data dirs. The other alternative would be to put all settings into the db but that would be a lot more work. The data dir is copied from the default values under WEB-INF at startup.
  e.. A minor bug occured in the workplace, I don't know what the reason is to read it's resources from an export dir instead from vfs like everything else but I made it very simple and added a ckeck if the export dir exsist, if not the resources are loaded from vfs.
  f.. Another minor bug was some classes that were stored in the session were not Serializable, causing tomcat to throw an ugly stacktrace when shutting down and starting because it tries to store all sessions to be able to restore them again. I added implements Serializable to those classes I saw this happen on.
  g.. Two new utility classes were created, CmsDataDirUtil.java and PropertiesCmsStringMapper.java, which are used when managing the data dir.
  h.. In CmsConfigurationException the error message set by throwing class was not included in the message returned by getMessage().
I think that covers all. All patches are attached as well as the two new classes (goes into src/org/opencms/util/).

I've now been running with these changes for some time and it works excellent. I am very satisfied. If these patches get accepted, this are the next areas I'll look in to:
  a.. Struts integration. Altough it is possible to use OpenCms with Struts today it's a bit cumbersome. I want to be able when I use the workplace to add a Struts action (not the class itself, that would have to be deployed with the other jars), set up it's parameters and point it's forwards to where I want them to point on this specific instance. That way the power and flexibility of Struts can really shine in combination with OpenCms. I think that the way to acomplish that would be to make a CmsStrutsLoader class and some management glue. It would still be possible to use Struts as it is used today.
  b.. Integration with J2EE style authentication & authorization. Neccesary to be able to call EJB's which use container managed security. Can be a bit tricky but should be possible to do without breaking backward compatibility.
  c.. Later make a vfs module which use Hibernate so that it can make use of JbossCache and Jboss clustering functions.
Thats's all I have for now. Keep up the good work.
Best regards
Sverker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20050304/4c375f0b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opencms-out.patch
Type: application/octet-stream
Size: 72440 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20050304/4c375f0b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opencms-datadir.patch
Type: application/octet-stream
Size: 18697 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20050304/4c375f0b/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opencms-log.patch
Type: application/octet-stream
Size: 5515 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20050304/4c375f0b/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opencms-misc.patch
Type: application/octet-stream
Size: 3579 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20050304/4c375f0b/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PropertiesCmsStringMapper.java
Type: text/java
Size: 2060 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20050304/4c375f0b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CmsDataDirUtil.java
Type: text/java
Size: 1248 bytes
Desc: not available
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20050304/4c375f0b/attachment-0001.bin>