[opencms-dev] OpenCms writes in the webapp directory considered a major problem

[Christoph Schönfeld]

Dear fellow list members and OpenCms developers,

I would like to share my thoughts on a topic which is on my mind since I 
start to understand how OpenCms works.

It is the fact that OpenCms writes to its web application context 
directory ($CATALINA_HOME/webapps/opencms). To be precise, the 
problematic fact is not that OpenCms writes to a directory but that it 
mixes deployed files and production data.

I will first first try to list all situations where OpenCms does this 
and explain which problems are caused by those write accesses. 
Afterwards I will propose several ideas on the solution to these 
problems and finally detail on the gains.

Writes access situations:
1. After installation OpenCms disables the setup code in 
WEB-INF/config/opencms.properties.
2. OpenCms changes configuration files in WEB-INF/config/ and takes 
backup copies of these in WEB-INF/config/backup.
3. OpenCms writes its log files to WEB-INF/logs (setup.log, opencms.log)
4. OpenCms writes often needed workspace files to resources/ and static 
export files to export/
5. It writes exported module ZIP archives to WEB-INF/packages/modules
6. It writes module ZIP archives uploaded via HTTP to 
WEB-INF/packages/modules
7. When publishing a module, OpenCms writes the module's classes and 
classpath resource files to WEB-INF/classes and the module's libraries 
to WEB-INF/lib.

Problems:
I) First and above all, updating the web application is complicated and 
error-prone. It is impossible to just redeploy the opencms.war file. 
This would destroy the installation.
II) You need to reload the OpenCms context or even restart Tomcat when 
you make classpath relevant changes to a module. This makes testing and 
bug fixing very inefficient.
III) It is impossible to include opencms.war as part of an J2EE EAR file.
IV) It is very difficult to set up a development environment and a build 
process for OpenCms module development which includes an IDE and a 
version control system.
V) It is quite unprobable but possible to get errors almost impossible 
to track down if two modules have conflicting versions of files, 
classes, or libraries (same path or conflicting versions). Publishing of 
the modules is a last-one-wins situation.


These problems are a major headache to me during development and they 
will continue to be during maintenance of the system I am currently 
developing on top of OpenCms. However, they can be solved.

 From my current view the following measures would do it:
A) Separate the log files and configuration data from the OpenCms 
context. This could be a standard location, for example /home/opencms or 
a similar directory with sub folders like config/ and logs/. This 
measure is concered with items 1, 2, and 3. Let us call it OPENCMS_HOME.
B) Separate resources/ and export/ from the OpenCms context and put them 
into a second web application context to which OpenCms is allowed to 
write. This measure is concered with item 4.
C) Since the module ZIP archives in WEB-INF/packages/modules/ are not 
used for any purpose after setup they should be removed completely from 
RFS. OpenCms should load the module classes, classpath resources and 
libraries with a custom ClassLoader for each module directly from the 
VFS. This measure is avoids write access situations 5 to 7. (The module 
ClassLoaders would build on the defined module dependencies.)
D) There could be a 'hot module folder' watched by OpenCms for updates 
just like the deploy/ folder with JBoss, e.g. in $OPENCMS_HOME/modules. 
(optional)

Benefits:
- Simple redeployment/upgrade of opencms.war without fear of breaking 
the installation.
- You could simply include opencms.war in a J2EE EAR file.
- Simple backup/replication of A) and B).
- Simple development/testing of modules without reloading of the OpenCms 
web application. OpenCms would just drop the old module ClassLoader and 
reload the new module version.
- Easier start for developers new to OpenCms.

I know that these are challenging proposals which have to be discussed 
in detail before starting anything. However, I think that it is possible 
and the result will be a much improved, even more reliable OpenCms and a 
development process closer to the one we are all used to.

I am looking forward to a lively discussion. I would certainly like to 
contribute to a solution.

Thanks for your attention.

Christoph

-- 
Christoph Schönfeld
Softwareentwicklung

Sylphen GmbH & Co. KG
Lippmannstr. 57
22769 Hamburg

E-Mail cschoenfeld at sylphen.com
http://www.sylphen.com