Direct Project Stock Apache James 3.0 Java Service Wrapper Fixes

[GoogleCodeExporter]

The Apache James 3.0 Beta 4 that comes with the Direct Project stock assembly 
must be started using apache-james-3.0-beta4/bin/run.sh. James should be 
started using apache-james-3.0-beta4/bin/james, but several tweaks need to be 
made in order for this to work. Using the "james" script is important/useful as 
it allows for the creation/use of a very simple init.d script for James, etc.

I am requesting that these fixes (or better ones) be incorporated into the 
Direct Project stock assembly.

Here is what I've figured out:
1. Due to an old version of Apache Camel in use by James, an old version of the 
JAXB RI implementation must be used as well 
(http://stackoverflow.com/questions/7810599/null-pointer-when-parsing-camelconte
xt-xml-file-during-startup). I've had success using JAXB RI 2.1.13 
(http://jaxb.java.net/2.1.13/). jaxb-impl.jar simply needs to be copied into 
conf/lib.

2. apache-james-3.0-beta4/bin/run.sh works because it calls 
apache-james-3.0-beta4/bin/setenv.sh, if it exists. The "setenv" script is 
crucial as it sets the classpath string (conf/lib/*) to prepend to the main 
classpath (conf:lib/*). The "james" script doesn't call the "setenv" script nor 
does it include libraries under conf/lib in the classpath. This can be fixed by 
adding the line "wrapper.java.classpath.120=../conf/lib/*" at the end of 
conf/wrapper.conf. Technically, this classpath entry should come before all of 
the lib/<*> entries (as wrapper.java.classpath.3), but then all of the 
remaining entries would have to be shifted down.

Original issue reported on code.google.com by michal.kotelba@esacinc.com on 8 Jan 2013 at 7:19

[GoogleCodeExporter]

James 3 is still listed as "experimental" in the Java RI release notes, and I 
cannot guarantee it is being used correctly; this type of feedback is helpful.  
The Java RI 2.1 release will incorporate the requested changes.

Original comment by gm2...@cerner.com on 23 Jan 2013 at 1:04

• Changed state: Accepted
• Added labels: Area-Gateway, OpSys-All, Project-Java

[GoogleCodeExporter]

I forgot to include two logging-related fixes specific to 
apache-james-3.0-beta4/conf/wrapper.conf. Since these are effectively fixing 
James' baseline configuration, I will also report them to the James project for 
fixing upstream (if not already done).

1. The line:

wrapper.logfile=log/wrapper.log

should be changed to:

wrapper.logfile=../log/wrapper.log

in order to get wrapper.log to be properly written to the logs directory 
instead of failing (since there is no apache-james-3.0-beta4/bin/log directory) 
and defaulting to the current directory during runtime 
(apache-james-3.0-beta4/bin).

2. Although not strictly a bug, it would be nice if the line:

wrapper.java.additional.15=-Dderby.stream.error.file=../log/derby.log

were added such that the Derby log file gets written to the logs directory 
instead of defaulting to the current directory during runtime.

Original comment by michal.kotelba@esacinc.com on 25 Jan 2013 at 9:34

[GoogleCodeExporter]

One more:

3. apache-james-3.0-beta4/bin/james is not having its file mode changed to be 
executable prior to direct-project-stock archive creation.

Original comment by michal.kotelba@esacinc.com on 25 Jan 2013 at 9:37

[GoogleCodeExporter]

Updating these changes.

Original comment by gm2...@cerner.com on 5 Feb 2013 at 4:39

[GoogleCodeExporter]

Closing

Original comment by gm2...@cerner.com on 25 Jun 2013 at 2:22

• Changed state: Done