AW: [opencms-dev] Changes to make OpenCms work properly on Jboss (orprobably any other app server)

[Marcus Redeker]

If you deploy opencms.war as an unpacked war some of your problems will not
occur and it works perfect without any patches.
 
--Marcus


  _____  

Von: opencms-dev-bounces at opencms.org
[mailto:opencms-dev-bounces at opencms.org] Im Auftrag von Sverker Abrahamsson
Gesendet: Freitag, 4. März 2005 23:06
An: Alexander Kandzior; The OpenCms mailing list
Betreff: [opencms-dev] Changes to make OpenCms work properly on Jboss
(orprobably any other app server)


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:

*	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. 

*	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. 

*	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. 

*	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. 

*	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. 

*	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. 

*	Two new utility classes were created, CmsDataDirUtil.java and
PropertiesCmsStringMapper.java, which are used when managing the data dir. 

*	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:

*	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. 

*	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. 

*	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/20050306/f3a6d12b/attachment.htm>