|
From: Prashant <pra...@pr...> - 2004-02-17 05:16:28
|
Leif, Is it not a good idea to print th Java command used to invoke the Client program, instead of associating this with debug=true? Even better some property to print the commad only wrapper.print.javacmd = true ? - true could be the default value. It will be very straight forward to resolve any path conflicts. May be then you would not get so many posts asking whats wrong when you run a program as a Wrapper service. :) Prashant Leif Mortenson wrote: > 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? >> > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |