<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1458" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=725132120-06032005>If you deploy opencms.war as an unpacked war some of
your problems will not occur and it works perfect without any
patches.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=725132120-06032005></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=725132120-06032005>--Marcus</SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=de dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>Von:</B> opencms-dev-bounces@opencms.org
[mailto:opencms-dev-bounces@opencms.org] <B>Im Auftrag von </B>Sverker
Abrahamsson<BR><B>Gesendet:</B> Freitag, 4. März 2005 23:06<BR><B>An:</B>
Alexander Kandzior; The OpenCms mailing list<BR><B>Betreff:</B> [opencms-dev]
Changes to make OpenCms work properly on Jboss (orprobably any other app
server)<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2>Hi Alexander and all others,</FONT></DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I discovered the following problems:</FONT></DIV>
<UL>
<LI><FONT face=Arial size=2>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.</FONT>
<LI><FONT face=Arial size=2>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 <FONT
size=2>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.</FONT></FONT>
<LI><FONT face=Arial size=2>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.</FONT>
<LI><FONT face=Arial size=2>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.</FONT>
<LI><FONT face=Arial size=2>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.</FONT>
<LI><FONT face=Arial size=2>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.</FONT>
<LI><FONT face=Arial size=2>Two new utility classes were created,
CmsDataDirUtil.java and PropertiesCmsStringMapper.java, which are used
when managing the data dir.</FONT>
<LI><FONT face=Arial size=2>In CmsConfigurationException the error message
set by throwing class was not included in the message returned by
getMessage().</FONT></LI></UL>
<DIV><FONT face=Arial size=2>I think that covers all. All patches are attached
as well as the two new classes (goes into src/org/opencms/util/).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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:</FONT></DIV>
<UL>
<LI><FONT face=Arial size=2>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.</FONT>
<LI><FONT face=Arial size=2>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.</FONT>
<LI><FONT face=Arial size=2>Later make a vfs module which use Hibernate so
that it can make use of JbossCache and Jboss clustering
functions.</FONT></LI></UL>
<DIV><FONT face=Arial size=2>Thats's all I have for now. Keep up the good
work.</FONT></DIV>
<DIV><FONT face=Arial size=2>Best regards</FONT></DIV>
<DIV><FONT face=Arial size=2>Sverker</FONT></DIV>
<DIV> </DIV></BLOCKQUOTE></BODY></HTML>