Menu
▾
▴
Re: [Wrapper-user] Trouble running as a service an app that replaces a standard java class
|
From: Leif M. <le...@ta...> - 2004-02-16 15:19:50
|
Chris,
This one was easy. :-) Take a look at the Java command that the
Wrapper is
generating to launch the JVM. When the Wrapper is running as a
service, the
COUGAAR_INSTALL_PATH environment variable does not appear to be
defined. Because of this several of your system properties along with the
-Xbootclasspath are not being set correctly:
DEBUG | wrapper | 2004/02/16 09:12:54 | command:
"C:\WINDOWS\system32\java.exe"
-Dorg.cougaar.system.path=%COUGAAR_INSTALL_PATH%\sys
-Dorg.cougaar.install.path=%COUGAAR_INSTALL_PATH%
-Dorg.cougaar.core.servlet.enable=true
-Dorg.cougaar.lib.web.scanRange=100 -Dorg.cougaar.lib.web.http.port=8800
-Dorg.cougaar.lib.web.https.port=-1
-Dorg.cougaar.lib.web.https.clientAuth=true
-Dorg.cougaar.core.logging.config.filename=log.properties
-Xbootclasspath/p:%COUGAAR_INSTALL_PATH%\lib\javaiopatch.jar -Xms50m
-Xmx100m -Djava.library.path="..\lib" -classpath
"..\lib\wrapper.jar;c:\bb\MetricsOperationsCenter\classes;C:\cougaar_10.4.2\lib\bootstrap.jar;C:\cougaar_10.4.2\lib\core.jar;C:\cougaar_10.4.2\lib\glm.jar;C:\cougaar_10.4.2\lib\planning.jar;C:\cougaar_10.4.2\lib\toolkit.jar;C:\cougaar_10.4.2\lib\util.jar;C:\cougaar_10.4.2\lib\webserver.jar;C:\cougaar_10.4.2\lib\webtomcat.jar;C:\cougaar_10.4.2\lib\community.jar;C:\cougaar_10.4.2\lib\javaiopatch.jar;C:\cougaar_10.4.2\sys\log4j.jar;C:\cougaar_10.4.2\sys\servlet.jar;C:\cougaar_10.4.2\sys\tomcat_40.jar"
-Dwrapper.key="497dMLKMPftbRjqo" -Dwrapper.port=32000
-Dwrapper.debug="TRUE" -Dwrapper.service="TRUE"
-Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1
mil.darpa.bb.metrics.ServiceNode -c -n LsiNode
How is this environment variable being set when running as a console
app?
Is it being set in your batch file? There are a couple ways to get this
working
when running as a service.
The first is to set the environment variable in the System control
panel. Make sure
it is set as a system wide variable or in the environment of the user
running the
Wrapper, usually SYSTEM.
The second option is to tell the Wrapper to set the variable when it
runs. This
can be done by defining a property: set.COUGAAR_INSTALL_PATH=C:/xxx
You can set the property in the wrapper.conf file. But most likely this
is available
the batch file you are using to run the wrapper, so will will want to
pass it as a
parameter to the Wrapper when it is used to install itself as a
service. The Wrapper
will store any and all parameters in the registry so they can be reused
later when
the service is actually run.
Your batch file would contain a line like the following:
Wrapper.exe -i ../conf/wrapper.conf set.COUGAAR_INSTALL_PATH=C:/xxx
Cheers,
Leif
Chris Brundick wrote:
> I've attached the wrapper.log generated with debug=true. Let me know
> if you discover anything.
>
> Thanks,
> Chris
>
> */Leif Mortenson <le...@ta...>/* wrote:
>
> Chris,
>
> Chris Brundick wrote:
>
> > Thanks for the reply Leif. I did as you suggested and attempted to
> > run after removing the -Dwrapper.key and it ran just fine. It's
> only
> > within the wrapper that I appear to have problems.
> >
> > I'm using the -Xbootclasspath:/p option on the java command line to
> > insert my class in front of the standard rt.jar, is it possible
> that
> > the wrapper has an issue with this?
>
> Playing with the core java classes completely destroys the
> portability
> of the program
> so it is not something that I have ever played with. I am sure you
> have
> a reason for
> doing so though. There are some security related issues that I would
> expect could arise
> because the main method is called from the wrapper's helper class
> which,
> unless you
> make it so, is not privileged code. However, as you say that running
> the same
> command generated by Wrapper works, I doubt this is the problem.
>
> I don't have any ideas on what might be causing this at the moment.
> Could you
> enable the wrapper.debug=true property in your conf file and then
> post
> the resulting
> debug output from a single launch of the JVM? I may have some ideas
> once I have
> seen the error in context.
>
> Cheers,
> Leif
>
> >
> > */Leif Mortenson /* wrote:
> >
> > Chris,
> > In general, that is not something you are supposed to do. But I
> > assume you
> > know that. :-)
> >
> > Normally, the rt.jar jar file is not located on the class path. I
> > believe it is looked at
> > before anything else on your classpath (??) I actually would not
> > expect
> > what you are
> > doing to work even when running Java manually, so I am not sure
> > why you
> > are only
> > having problems running with the Wrapper.
> >
> > Set the wrapper.debug=true property in your wrapper.conf file. This
> > will cause
> > the Wrapper to display the full Java command used to launch the
> > JVM in
> > the log.
> > Copy that full command into a fresh batch file. You will need to
> > remove the
> > -Dwrapper.key property from the command, but other than that you
> > should not
> > make any changes.
> > Now try running that script. It should behave exactly as it does
> > when running
> > under the Wrapper, only the Wrapper is now out of the equation. You
> > can then
> > fiddle with that batch file until you have things working. When you
> > know what the
> > problem was it should be easy to make the changes to the
> wrapper.conf
> > file to get
> > things working.
> >
> > Let me know if you have any questions while doing the above.
> >
> > Cheers,
> > Leif
> >
> > Chris Brundick wrote:
> >
> > > I'm very close to being able to run my application as a service in
> > > WinXP but I'm having an issue. I am replacing one of the standard
> > > java classes in java.io with my own version. I place my jar
> > > containing this class in the wrapper.java.classpath list in my
> > > wrapper.conf but it doesn't appear to recognize it. It seems to
> > work
> > > just fine in the console. Any thoughts?
>
|
