Details
-
Bug
-
Status: Open
-
Critical
-
Resolution: Unresolved
-
1.0-dev (Tomcat)
-
None
-
None
-
Operating System: All
Platform: All
-
17957
Description
THERE IS NO PLACE TO LOG A BUG AGAINST THE commons-launcher CODE!!!!!!!!!!!!!!
There is a rather bad bug in commons-launcher-0.9. Its bad
if you want to get notified when the child JVM dies
because of an Error (like java.lang.OutOfMemoryError).
I need such information because I am using Java
Service Wrapper,
http://wrapper.tanukisoftware.org/doc/english/,
which allows one to wrap their java code in a platform
specific native wrapper which, for example, detects
the printing of the string "java.lang.OutOfMemoryError"
by the child JVM and restarts the child (if thats the
behavior you want). Its a rather perfect fit with
commons-launcher; I use the wrapper to launch the
launcher and all of the java classpath, system
properties, etc. variability is located in the
java application specific launcher.xml file.
Any way, the bug:
When the child java application has an Error thrown,
it propagates up the thread stack until it reaches
the ThreadGroup class ExitOnErrorThreadGroup, which is
a commons-launcher class. Here the ThreadGroup method,
public void uncaughtException(Thread t, Throwable e)
Is redefined to call the Launcher code to print out the
Error object's information. Specifically, it calls,
Launcher.error(Throwable e);
Well, two problems.
The first, and less serious, the parent java process, the one
that executed ChildMain as a child java process, actually
initialized the Launcher class' log - the child java process
never initialized its own copy of the Launcher class' log.
So if one expects the error message to go to the same place as
the parent process' log - mayby it will maybe it won't.
The second is a more serious problem. When the child java process
gets to calling Launcher.error(e) for the first time, well
this is the first time that the Launcher class has been loaded
by the child process so it and all objects it depends upon
must be loaded. Well, it uses Ant's project class so basically,
the child process has to have Ant in its class path. If it does
not, then the Error message is NEVER printed because a different
exception is thrown while the JVM is trying to load the Ant
class (since it can not find them since they are not on the
classpath).
If the Error message is NOT printed, then the Java Service
Wrapper never sees the message and the Java application is
not restarted - which is why I discoved the bug in the
first place after some searching around.
The solution:
Recommending that users of the commons-launcher allways include
Ant in their class path I think is a no starter.
The solution I would like is for the ExitOnErrorThreadGroup
class' uncaughtException(..) method simply to print
the Error message to System.err.