Re: [Wrapper-user] Console messages

[Anastasios Angelidis <voodoo@vi...>]

Thanks it's just that the 3rd party app I'm trying to wrap is very 
verbose on the console...

But it has it's own logs... I'm sure it loags it's own exceptions! 
Unless you saying I wont see crash duimps of the wrapper...


Leif Mortenson wrote:

> Anastasios,
>    Try this:
> wrapper.logfile.loglevel=STATUS
>
>    You will still see the output in the console, but it will not be 
> shown in the log file.
> The problem with doing this is that you may lose other information 
> that you really do
> want to see.  For example crash dumps etc.
>
>    A better solution may be to do something like this:
> wrapper.logfile.maxsize=1m
> wrapper.logfile.maxfiles=1
>
>    By doing this, the wrapper.log file will always be renamed to 
> wrapper.log.1
> when it exceeds 1Mb in size.  The max files specifies the maximum 
> number of
> rolled log files that will be kept around.  By doing this, you will be 
> able to see
> all recent log output, but will also be able to guarantee that the 
> wrapper's log
> files will never use more than 2Mb of disk space.
>
> Cheers,
> Leif
>
> Anastasios Angelidis wrote:
>
>> Is there a way to stop the wrapper from outputting console messages 
>> to the log? I'm using a 3rd party app which outputs alot to the 
>> console. So everything gets logged to the wrapper log which I dont 
>> want it to! Thanks
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wrapper-user@...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

RE: [Wrapper-user] Log4j problem.

[Doug Tanner <doug.tanner@be...>]

Leif,

Yes, my log4j.xml is in the same folder as the wrapper.exe.  I know the=20
-Dlog4j.configuration=3Dlog4j.xml is correct b/c if I try to run my
program without the wrapper, it runs just fine.

Here is the command I use to run my program:

Java -Dlog4j.configuration=3Dlog4j.xml -Dlog4j.debug=3Dtrue=20
-Dconnection.properties=3Dtest.connection.properties =
-classpath=3D[insert
all jars that I have included in the wrapper.conf file] -Xmx256m
bf.cbm.util.shecduler.SchedulerManager

I actually have a .bat file that runs the command.

Also, while trying to figure out this log4j problem, I have encountered
a new error.  Please see attachment for this new error.

Thanks for the help,

Doug Tanner

-----Original Message-----
From: wrapper-user-admin@...
[mailto:wrapper-user-admin@...] On Behalf Of Leif
Mortenson
Sent: Monday, January 30, 2006 9:35 PM
To: wrapper-user@...
Subject: Re: [Wrapper-user] Log4j problem.

Doug,
    I 'm not a bit log4j user myself.  I had to read over the log to=20
even see what
your problem is.  I assume it is the following two lines?

INFO   | jvm 1    | 2006/01/30 08:42:25 | log4j:WARN No appenders could=20
be found for logger (bf.cbm.util.io.Loader).
INFO   | jvm 1    | 2006/01/30 08:42:25 | log4j:WARN Please initialize=20
the log4j system properly.

    This is most likely because of a log4j configuration problem.  Ie=20
the configuration
is invalid or more likely, the config file is not being found.   Log4j=20
can locate its
configuration on the classpath or in your case by specifying a specific=20
log file
using a system property.

    I assume that the -Dlog4j.configuration=3Dlog4j.xml syntax is=20
correct.  This will be
looking for a file ./log4j.xml in the same directory as your=20
wrapper.exe.   Is that where
it is located?  Remember that all relative paths are relative to the=20
location of the
wrapper.exe.

Cheers,
Leif

Doug Tanner wrote:
>
> I have read the different threads dealing with Log4j problems, but=20
> none of them seem to have posted the fix/conclusion to the problem.
>
> =20
>
> Here is my wrapper.log file:
>
<snip log file>
>
>  =20
> Can anyone tell me if they see a problem with this setup?  I cannot=20
> seem to get the wrapper to use the log4j.xml file so that I can=20
> monitor the output of the java program that it is running.
>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=3D=
121642
_______________________________________________
Wrapper-user mailing list
Wrapper-user@...
https://lists.sourceforge.net/lists/listinfo/wrapper-user


*************************************************************************=
***************
BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is =
intended only for the individual or entity to which it is addressed and =
may contain information that is confidential and protected by law. =
Unauthorized review, use, disclosure, or dissemination of this =
communication or its contents in any way is prohibited and may be =
unlawful. If you are not the intended recipient or a person responsible =
for delivering this message to an intended recipient, please notify the =
original sender immediately by e-mail or telephone, return the original =
message to the original sender or to bfpostmaster@..., and =
destroy all copies or derivations of the original message. Thank you.  =
(BFeComNote Rev. 08/01/2005)
*************************************************************************=
**************

Re: [Wrapper-user] Log4j problem.

[Leif Mortenson <leif@ta...>]

Doug,
    I 'm not a bit log4j user myself.  I had to read over the log to 
even see what
your problem is.  I assume it is the following two lines?

INFO   | jvm 1    | 2006/01/30 08:42:25 | log4j:WARN No appenders could 
be found for logger (bf.cbm.util.io.Loader).
INFO   | jvm 1    | 2006/01/30 08:42:25 | log4j:WARN Please initialize 
the log4j system properly.

    This is most likely because of a log4j configuration problem.  Ie 
the configuration
is invalid or more likely, the config file is not being found.   Log4j 
can locate its
configuration on the classpath or in your case by specifying a specific 
log file
using a system property.

    I assume that the -Dlog4j.configuration=log4j.xml syntax is 
correct.  This will be
looking for a file ./log4j.xml in the same directory as your 
wrapper.exe.   Is that where
it is located?  Remember that all relative paths are relative to the 
location of the
wrapper.exe.

Cheers,
Leif

Doug Tanner wrote:
>
> I have read the different threads dealing with Log4j problems, but 
> none of them seem to have posted the fix/conclusion to the problem.
>
>  
>
> Here is my wrapper.log file:
>
<snip log file>
>
>   
> Can anyone tell me if they see a problem with this setup?  I cannot 
> seem to get the wrapper to use the log4j.xml file so that I can 
> monitor the output of the java program that it is running.
>

Re: [Wrapper-user] RESTART not wanting to work

[Leif Mortenson <leif@ta...>]

David,
    Thanks for the log.  I'm pretty sure this problem is now fixed.  I 
added a note
about this problem to the release notes as well.

    Glad you have found the wrapper useful. :-)

Cheers,
Leif


David McCullars wrote:
> Thanks for such a speedy reply!  I added the debugging as requested 
> and attached the output of the error.  But good news, I tried the 
> latest build as you suggested, and it has worked several times in a 
> row.  I am assuming since it seems to be working you don't wish a log 
> file for it, but I'll be happy to send you one if you desire.
>
> So I guess I'll just use this latest version until 3.2.0 becomes 
> available.  (Makes me feel a little better to know the problem wasn't 
> between the keyboard and chair.)  Anyway, absolutely love this 
> application -- it kicks ass!
>
> David

Re: [Wrapper-user] RESTART not wanting to work

[David McCullars <dmccullars@ch...>]

Thanks for the feedback.  However, we actually already had JBoss
outputing to the console, so the wrapper was seeing the OOME -- it was
shuting down just fine upon detection of the OOME, just not coming back up.

The good news, though, is that Leif's latest changes mentioned below
fixed the issue.  So if anyone else is having this issue, you'll want to
upgrade to 3.2.0.

David

Richard Emberson wrote:

> If you are using JBoss and its logging to a file, then the wrapper
> will not see
> the OOME error log message. You MUST also log (at least at the error
> level)
> to the console for the wrapper to see the OOME error message.
> We just discovered this truth. Restart on OOME used to work. Then someone
> change the log4j.xml file (no longer logging to console). Then the JBoss
> system stopped restarting on OOME. It took a while to figure out that
> the left hand did not know why the right hand had set up the log4j in a
> certain way.
> good luck.
>
> RME
>
>
> Leif Mortenson wrote:
>
>> David,
>>    Reviewing the code of 3.1.2 and the latest trunk, I think that I
>> may have fixed this
>> while implementing another change.  Could you please add the
>> following properties:
>> wrapper.debug=true
>> wrapper.state_output=true
>> wrapper.loop_output=true
>>
>>    This will kick out a lot of output, but it will tell me exactly
>> what is happening.
>> Once you have reproduced the problem, tar.gz the resulting
>> wrapper.log file and
>> then send it to me directly off list.
>>
>>    I have also created a snapshot of the latest build undergoing
>> testing for the next
>> release.  I would appreciate any feedback about whether or not it is
>> fixed using this
>> version.  If not, then I would also like to see the same output as
>> for the 3.1.2
>> version above.
>> http://wrapper.tanukisoftware.org/tmp/3.2.0-c/wrapper-linux-x86-32-3.2.0-c.tar.gz
>>
>> (This version will NOT be supported once the 3.2.0 release is out.)
>>
>> Cheers,
>> Leif
>>
>>
>> David McCullars wrote:
>>
>>> I've got the wrapper working well on a CentOS 3.6 system to wrap
>>> JBoss 4
>>> (with Sun's Java 1.5.0_05-b05).  It starts and stops perfectly, but I
>>> was really needing the restart filter to work on out of memory errors
>>> (something we've had a problem with historically).  I added the
>>> trigger,
>>> and it attempts to do a restart when I create an OOME, but the wrapper
>>> crashes 9 times out of 10 when it checks to see if the JVM halted:
>>>
>>> Shutdown complete
>>> Halting VM
>>> Critical error: wait for JVM process failed (No child processes)
>>>
>>> I've tried all sorts of wrapper.conf settings to see if something
>>> works,
>>> but it's only restarted twice, and it never did it more than once in a
>>> row.  Here's the latest config file for what it's worth.  I'm really
>>> hoping I'm just doing something stupid because JSW kicks ass!
>>>
>>> set.JAVA_HOME=/usr/local/java
>>> set.JBOSS_HOME=/usr/local/jboss
>>> wrapper.java.command=%JAVA_HOME%/bin/java
>>> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>>> wrapper.java.classpath.1=../lib/wrapper.jar
>>> wrapper.java.classpath.2=%JBOSS_HOME%/bin/run.jar
>>> wrapper.java.classpath.3=%JAVA_HOME%/lib/tools.jar
>>> wrapper.java.library.path.1=../lib
>>> wrapper.java.additional.1=-Dprogram.name=run.sh
>>> wrapper.java.additional.2=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl
>>>
>>> wrapper.java.additional.3=-Djava.endorsed.dirs=%JBOSS_HOME%/lib/endorsed
>>>
>>> wrapper.java.additional.4=-verbosegc
>>> wrapper.java.initmemory=1024
>>> wrapper.java.maxmemory=1024
>>> wrapper.app.parameter.1=org.jboss.Main
>>> wrapper.console.format=M
>>> wrapper.console.loglevel=INFO
>>> wrapper.logfile=../jboss.log
>>> wrapper.logfile.format=LTM
>>> wrapper.logfile.loglevel=INFO
>>> wrapper.logfile.maxsize=10m
>>> wrapper.logfile.maxfiles=4
>>> wrapper.syslog.loglevel=NONE
>>> wrapper.filter.trigger.1=java.lang.OutOfMemoryError
>>> wrapper.filter.action.1=RESTART
>>> wrapper.restart.delay=30
>>>
>>> If anyone can throw some light my way, I'd be most indebted!
>>>
>>> David
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> Wrapper-user mailing list
>> Wrapper-user@...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>
>

Re: [Wrapper-user] RESTART not wanting to work

[Richard Emberson <remberson@ed...>]

If you are using JBoss and its logging to a file, then the wrapper will 
not see
the OOME error log message. You MUST also log (at least at the error level)
to the console for the wrapper to see the OOME error message.
We just discovered this truth. Restart on OOME used to work. Then someone
change the log4j.xml file (no longer logging to console). Then the JBoss
system stopped restarting on OOME. It took a while to figure out that
the left hand did not know why the right hand had set up the log4j in a
certain way.
good luck.

RME


Leif Mortenson wrote:

> David,
>    Reviewing the code of 3.1.2 and the latest trunk, I think that I 
> may have fixed this
> while implementing another change.  Could you please add the following 
> properties:
> wrapper.debug=true
> wrapper.state_output=true
> wrapper.loop_output=true
>
>    This will kick out a lot of output, but it will tell me exactly 
> what is happening.
> Once you have reproduced the problem, tar.gz the resulting wrapper.log 
> file and
> then send it to me directly off list.
>
>    I have also created a snapshot of the latest build undergoing 
> testing for the next
> release.  I would appreciate any feedback about whether or not it is 
> fixed using this
> version.  If not, then I would also like to see the same output as for 
> the 3.1.2
> version above.
> http://wrapper.tanukisoftware.org/tmp/3.2.0-c/wrapper-linux-x86-32-3.2.0-c.tar.gz 
>
> (This version will NOT be supported once the 3.2.0 release is out.)
>
> Cheers,
> Leif
>
>
> David McCullars wrote:
>
>> I've got the wrapper working well on a CentOS 3.6 system to wrap JBoss 4
>> (with Sun's Java 1.5.0_05-b05).  It starts and stops perfectly, but I
>> was really needing the restart filter to work on out of memory errors
>> (something we've had a problem with historically).  I added the trigger,
>> and it attempts to do a restart when I create an OOME, but the wrapper
>> crashes 9 times out of 10 when it checks to see if the JVM halted:
>>
>> Shutdown complete
>> Halting VM
>> Critical error: wait for JVM process failed (No child processes)
>>
>> I've tried all sorts of wrapper.conf settings to see if something works,
>> but it's only restarted twice, and it never did it more than once in a
>> row.  Here's the latest config file for what it's worth.  I'm really
>> hoping I'm just doing something stupid because JSW kicks ass!
>>
>> set.JAVA_HOME=/usr/local/java
>> set.JBOSS_HOME=/usr/local/jboss
>> wrapper.java.command=%JAVA_HOME%/bin/java
>> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>> wrapper.java.classpath.1=../lib/wrapper.jar
>> wrapper.java.classpath.2=%JBOSS_HOME%/bin/run.jar
>> wrapper.java.classpath.3=%JAVA_HOME%/lib/tools.jar
>> wrapper.java.library.path.1=../lib
>> wrapper.java.additional.1=-Dprogram.name=run.sh
>> wrapper.java.additional.2=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl 
>>
>> wrapper.java.additional.3=-Djava.endorsed.dirs=%JBOSS_HOME%/lib/endorsed
>> wrapper.java.additional.4=-verbosegc
>> wrapper.java.initmemory=1024
>> wrapper.java.maxmemory=1024
>> wrapper.app.parameter.1=org.jboss.Main
>> wrapper.console.format=M
>> wrapper.console.loglevel=INFO
>> wrapper.logfile=../jboss.log
>> wrapper.logfile.format=LTM
>> wrapper.logfile.loglevel=INFO
>> wrapper.logfile.maxsize=10m
>> wrapper.logfile.maxfiles=4
>> wrapper.syslog.loglevel=NONE
>> wrapper.filter.trigger.1=java.lang.OutOfMemoryError
>> wrapper.filter.action.1=RESTART
>> wrapper.restart.delay=30
>>
>> If anyone can throw some light my way, I'd be most indebted!
>>
>> David
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wrapper-user@...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>


-- 
This email message is for the sole use of the intended recipient(s) and 
may contain confidential information.  Any unauthorized review, use, 
disclosure or distribution is prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all 
copies of the original message.

[Wrapper-user] Log4j problem.

[Doug Tanner <doug.tanner@be...>]

I have read the different threads dealing with Log4j problems, but none
of them seem to have posted the fix/conclusion to the problem.

=20

Here is my wrapper.log file:

=20

STATUS | wrapper  | 2006/01/30 08:42:25 | --> Wrapper Started as Service

DEBUG  | wrapper  | 2006/01/30 08:42:25 | Using system timer.

DEBUG  | wrapperp | 2006/01/30 08:42:25 | server listening on port
32000.

STATUS | wrapper  | 2006/01/30 08:42:25 | Launching a JVM...

DEBUG  | wrapper  | 2006/01/30 08:42:25 | command:
"C:\oracle\ora92\jre\1.4.2\bin\java.exe" =
-Dlog4j.configuration=3Dlog4j.xml
-Dconnection.properties=3Drelatl.connection.properties -Xms256m -Xmx256m
-Djava.library.path=3D"../lib;C:/bea81/jdk142_08/bin;C:/oracle/ora92/bin"=

-classpath
"../lib/bsh-1.3b2.jar;../lib/coremessaging-client.jar;../lib/coremessagi
ng.jar;../lib/junit-3_8_1.jar;../lib/wrapper.jar;../lib/wrappertest.jar;
../lib/xalan.jar;../lib/xerces.jar;../lib/bf/cbm-client.jar;../lib/bf/cb
m-support.jar;../lib/jakarta/commons-beanutils-1.7.0.jar;../lib/jakarta/
commons-codec-1.3.jar;../lib/jakarta/commons-collections-3.1.jar;../lib/
jakarta/commons-dbutils-1.0.jar;../lib/jakarta/commons-digester-1.5.jar;
../lib/jakarta/commons-io-1.0.jar;../lib/jakarta/commons-lang-2.0.jar;..
/lib/jakarta/commons-logging-1.0.4.jar;../lib/jakarta/jakarta-oro-2.0.8.
jar;../lib/jakarta/log4j-1_2_8.jar;../lib/security/BfRdbmsAuthenticator.
jar;../lib/security/SecurityActionInterface.jar;../lib/security/Security
Adapters.jar;../lib/security/SecurityCommon.jar;../lib/quartz/commons-db
cp-1.1.jar;../lib/quartz/commons-pool-1.1.jar;../lib/quartz/jdbc2_0-stde
xt.jar;../lib/quartz/quartz.jar" -Dwrapper.key=3D"YGAyFo_tJZF4dQUs"
-Dwrapper.port=3D32000 -Dwrapper.debug=3D"TRUE"
-Dwrapper.use_system_time=3D"TRUE" -Dwrapper.version=3D"3.1.2"
-Dwrapper.native_library=3D"wrapper" -Dwrapper.service=3D"TRUE"
-Dwrapper.cpu.timeout=3D"10" -Dwrapper.jvmid=3D1
org.tanukisoftware.wrapper.WrapperSimpleApp
bf.cbm.util.scheduler.SchedulerManager addSampleJob

DEBUG  | wrapper  | 2006/01/30 08:42:25 | JVM started (PID=3D1200)

INFO   | jvm 1    | 2006/01/30 08:42:25 | WrapperManager class
initialized by thread: main  Using classloader:
sun.misc.Launcher$AppClassLoader@...

INFO   | jvm 1    | 2006/01/30 08:42:25 | Wrapper Manager: JVM #1

INFO   | jvm 1    | 2006/01/30 08:42:25 | Wrapper Manager: Registering
shutdown hook

INFO   | jvm 1    | 2006/01/30 08:42:25 | Wrapper Manager: Using wrapper

INFO   | jvm 1    | 2006/01/30 08:42:25 | Loaded native library:
wrapper.dll

INFO   | jvm 1    | 2006/01/30 08:42:25 | Calling native initialization
method.

INFO   | jvm 1    | 2006/01/30 08:42:25 | Initializing WrapperManager
native library.

INFO   | jvm 1    | 2006/01/30 08:42:25 | Java Executable:
C:\oracle\ora92\jre\1.4.2\bin\java.exe

INFO   | jvm 1    | 2006/01/30 08:42:25 | Windows version: 5.1.2600

INFO   | jvm 1    | 2006/01/30 08:42:25 | Java Version   : 1.4.2_03-b02
Java HotSpot(TM) Client VM

INFO   | jvm 1    | 2006/01/30 08:42:25 | Java VM Vendor : Sun
Microsystems Inc.

INFO   | jvm 1    | 2006/01/30 08:42:25 |=20

INFO   | jvm 1    | 2006/01/30 08:42:25 | Wrapper (Version 3.1.2)
http://wrapper.tanukisoftware.org

INFO   | jvm 1    | 2006/01/30 08:42:25 |=20

INFO   | jvm 1    | 2006/01/30 08:42:25 |
WrapperManager.start(org.tanukisoftware.wrapper.WrapperSimpleApp@...
, args["addSampleJob"]) called by thread: main

INFO   | jvm 1    | 2006/01/30 08:42:25 | Open socket to wrapper...

INFO   | jvm 1    | 2006/01/30 08:42:25 | Opened Socket

INFO   | jvm 1    | 2006/01/30 08:42:25 | Send a packet KEY :
YGAyFo_tJZF4dQUs

INFO   | jvm 1    | 2006/01/30 08:42:25 |
handleSocket(Socket[addr=3D/127.0.0.1,port=3D32000,localport=3D4427])

DEBUG  | wrapperp | 2006/01/30 08:42:25 | accepted a socket from
127.0.0.1 on port 4427

DEBUG  | wrapperp | 2006/01/30 08:42:25 | read a packet KEY :
YGAyFo_tJZF4dQUs

DEBUG  | wrapper  | 2006/01/30 08:42:25 | Got key from JVM:
YGAyFo_tJZF4dQUs

DEBUG  | wrapperp | 2006/01/30 08:42:25 | send a packet LOW_LOG_LEVEL :
1

DEBUG  | wrapperp | 2006/01/30 08:42:25 | send a packet PING_TIMEOUT :
30

DEBUG  | wrapper  | 2006/01/30 08:42:25 | Start Application.

DEBUG  | wrapperp | 2006/01/30 08:42:25 | send a packet START : start

INFO   | jvm 1    | 2006/01/30 08:42:25 | Received a packet
LOW_LOG_LEVEL : 1

INFO   | jvm 1    | 2006/01/30 08:42:25 | Wrapper Manager: LowLogLevel
from Wrapper is 1

INFO   | jvm 1    | 2006/01/30 08:42:25 | Received a packet PING_TIMEOUT
: 30

INFO   | jvm 1    | 2006/01/30 08:42:25 | Wrapper Manager: PingTimeout
from Wrapper is 30000

INFO   | jvm 1    | 2006/01/30 08:42:25 | Received a packet START :
start

INFO   | jvm 1    | 2006/01/30 08:42:25 | calling listener.start()

INFO   | jvm 1    | 2006/01/30 08:42:25 | WrapperSimpleApp: start(args)

INFO   | jvm 1    | 2006/01/30 08:42:25 | WrapperSimpleApp: invoking
main method

INFO   | jvm 1    | 2006/01/30 08:42:25 | log4j:WARN No appenders could
be found for logger (bf.cbm.util.io.Loader).

INFO   | jvm 1    | 2006/01/30 08:42:25 | log4j:WARN Please initialize
the log4j system properly.

INFO   | jvm 1    | 2006/01/30 08:42:27 | WrapperSimpleApp: main method
completed

INFO   | jvm 1    | 2006/01/30 08:42:27 | WrapperSimpleApp: start(args)
end.  Main Completed=3Dtrue, exitCode=3Dnull

INFO   | jvm 1    | 2006/01/30 08:42:27 | returned from listener.start()

INFO   | jvm 1    | 2006/01/30 08:42:27 | Send a packet STARTED :=20

DEBUG  | wrapperp | 2006/01/30 08:42:27 | read a packet STARTED :=20

DEBUG  | wrapper  | 2006/01/30 08:42:27 | JVM signalled that it was
started.

DEBUG  | wrapperp | 2006/01/30 08:42:29 | send a packet PING : ping

INFO   | jvm 1    | 2006/01/30 08:42:29 | Received a packet PING : ping

INFO   | jvm 1    | 2006/01/30 08:42:29 | Send a packet PING : ok

DEBUG  | wrapperp | 2006/01/30 08:42:29 | read a packet PING : ok

DEBUG  | wrapper  | 2006/01/30 08:42:29 | Got ping response from JVM

DEBUG  | wrapper  | 2006/01/30 08:42:29 | ServiceControlHandler(1)

DEBUG  | wrapper  | 2006/01/30 08:42:29 |   SERVICE_CONTROL_STOP

DEBUG  | wrapper  | 2006/01/30 08:42:29 | wrapperStopProcess(0) called.

DEBUG  | wrapper  | 2006/01/30 08:42:29 | Sending stop signal to JVM

DEBUG  | wrapperp | 2006/01/30 08:42:29 | send a packet STOP : NULL

INFO   | jvm 1    | 2006/01/30 08:42:29 | Received a packet STOP :=20

INFO   | jvm 1    | 2006/01/30 08:42:29 | Thread, Wrapper-Connection,
handling the shutdown process.

INFO   | jvm 1    | 2006/01/30 08:42:29 | calling listener.stop()

INFO   | jvm 1    | 2006/01/30 08:42:29 | WrapperSimpleApp: stop(0)

INFO   | jvm 1    | 2006/01/30 08:42:29 | returned from listener.stop()

INFO   | jvm 1    | 2006/01/30 08:42:29 | Send a packet STOPPED : 0

DEBUG  | wrapperp | 2006/01/30 08:42:29 | read a packet STOPPED : 0

DEBUG  | wrapper  | 2006/01/30 08:42:29 | JVM signalled that it was
stopped.

INFO   | jvm 1    | 2006/01/30 08:42:30 | Closing socket.

DEBUG  | wrapperp | 2006/01/30 08:42:30 | socket read no code (closed?).

INFO   | jvm 1    | 2006/01/30 08:42:30 | calling System.exit(0)

DEBUG  | wrapper  | 2006/01/30 08:42:30 | JVM process exited with a code
of 0, leaving the wrapper exit code set to 0.

DEBUG  | wrapper  | 2006/01/30 08:42:30 | JVM exited normally.

STATUS | wrapper  | 2006/01/30 08:42:30 | <-- Wrapper Stopped

=20

And here is my wrapper.conf file:

=20

#********************************************************************

# TestWrapper Properties

#

# NOTE - Please use src/conf/wrapper.conf.in as a template for your

#        own application rather than the values used for the

#        TestWrapper sample.

#********************************************************************

# Java Application

wrapper.java.command=3Djava

=20

# Java Main class.  This class must implement the WrapperListener
interface

#  or guarantee that the WrapperManager class is initialized.  Helper

#  classes are provided to do this for you.  See the Integration section

#  of the documentation for details.

wrapper.java.mainclass=3Dorg.tanukisoftware.wrapper.WrapperSimpleApp

=20

# Java Classpath (include wrapper.jar)  Add class path elements as

#  needed starting from 1

wrapper.java.classpath.1=3D../lib/*.jar

wrapper.java.classpath.2=3D../lib/bf/*.jar

wrapper.java.classpath.3=3D../lib/jakarta/*.jar

wrapper.java.classpath.4=3D../lib/security/*.jar

wrapper.java.classpath.5=3D../lib/quartz/*.jar

=20

# Java Library Path (location of Wrapper.DLL or libwrapper.so)

wrapper.java.library.path.1=3D../lib

wrapper.java.library.path.2=3DC:/bea81/jdk142_08/bin

wrapper.java.library.path.3=3DC:/oracle/ora92/bin

=20

# Java Additional Parameters

wrapper.java.additional.1=3D-Dlog4j.configuration=3Dlog4j.xml

wrapper.java.additional.2=3D-Dconnection.properties=3Drelatl.connection.p=
rop
erties

=20

=20

# Initial Java Heap Size (in MB)

wrapper.java.initmemory=3D256

=20

# Maximum Java Heap Size (in MB)

wrapper.java.maxmemory=3D256

=20

# Application parameters.  Add parameters as needed starting from 1

wrapper.app.parameter.1=3Dbf.cbm.util.scheduler.SchedulerManager

wrapper.app.parameter.2=3DaddSampleJob

=20

=20

=20

#********************************************************************

# Wrapper Logging Properties

#********************************************************************

# Format of output for the console.  (See docs for formats)

wrapper.console.format=3DPM

=20

# Log Level for console output.  (See docs for log levels)

wrapper.console.loglevel=3Ddebug

=20

# Log file to use for wrapper output logging.

wrapper.logfile=3D../logs/wrapper.log

=20

# Format of output for the log file.  (See docs for formats)

wrapper.logfile.format=3DLPTM

=20

# Log Level for log file output.  (See docs for log levels)

wrapper.logfile.loglevel=3Ddebug

=20

# Maximum size that the log file will be allowed to grow to before

#  the log is rolled. Size is specified in bytes.  The default value

#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or

#  'm' (mb) suffix.  For example: 10m =3D 10 megabytes.

wrapper.logfile.maxsize=3D0

=20

# Maximum number of rolled log files which will be allowed before old

#  files are deleted.  The default value of 0 implies no limit.

wrapper.logfile.maxfiles=3D0

=20

# Log Level for sys/event log output.  (See docs for log levels)

wrapper.syslog.loglevel=3DNONE

=20

wrapper.debug=3Dtrue

=20

#********************************************************************

# Wrapper Windows Properties

#********************************************************************

# Title to use when running as a console

wrapper.console.title=3DQuartz Job Scheduler

=20

#********************************************************************

# Wrapper Windows NT/2000/XP Service Properties

#********************************************************************

# WARNING - Do not modify any of these properties when an application

#  using this configuration file has been installed as a service.

#  Please uninstall the service before modifying this section.  The

#  service can then be reinstalled.

=20

# Name of the service

wrapper.ntservice.name=3DSchedulerManager

=20

# Display name of the service

wrapper.ntservice.displayname=3DSchedulerManager

=20

# Description of the service

wrapper.ntservice.description=3DSchedulerManager Test

=20

# Service dependencies.  Add dependencies as needed starting from 1

wrapper.ntservice.dependency.1=3D

=20

# Mode in which the service is installed.  AUTO_START or DEMAND_START

wrapper.ntservice.starttype=3DAUTO_START

=20

# Allow the service to interact with the desktop.

wrapper.ntservice.interactive=3Dfalse

=20

Can anyone tell me if they see a problem with this setup?  I cannot seem
to get the wrapper to use the log4j.xml file so that I can monitor the
output of the java program that it is running.

=20

Thanks,

=20

Doug Tanner

=20



*************************************************************************=
***************
BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is =
intended only for the individual or entity to which it is addressed and =
may contain information that is confidential and protected by law. =
Unauthorized review, use, disclosure, or dissemination of this =
communication or its contents in any way is prohibited and may be =
unlawful. If you are not the intended recipient or a person responsible =
for delivering this message to an intended recipient, please notify the =
original sender immediately by e-mail or telephone, return the original =
message to the original sender or to bfpostmaster@..., and =
destroy all copies or derivations of the original message. Thank you.  =
(BFeComNote Rev. 08/01/2005)
*************************************************************************=
**************

Re: [Wrapper-user] RESTART not wanting to work

[Leif Mortenson <leif@ta...>]

David,
    Reviewing the code of 3.1.2 and the latest trunk, I think that I may 
have fixed this
while implementing another change.  Could you please add the following 
properties:
wrapper.debug=true
wrapper.state_output=true
wrapper.loop_output=true

    This will kick out a lot of output, but it will tell me exactly what 
is happening.
Once you have reproduced the problem, tar.gz the resulting wrapper.log 
file and
then send it to me directly off list.

    I have also created a snapshot of the latest build undergoing 
testing for the next
release.  I would appreciate any feedback about whether or not it is 
fixed using this
version.  If not, then I would also like to see the same output as for 
the 3.1.2
version above.
http://wrapper.tanukisoftware.org/tmp/3.2.0-c/wrapper-linux-x86-32-3.2.0-c.tar.gz
(This version will NOT be supported once the 3.2.0 release is out.)

Cheers,
Leif


David McCullars wrote:
> I've got the wrapper working well on a CentOS 3.6 system to wrap JBoss 4
> (with Sun's Java 1.5.0_05-b05).  It starts and stops perfectly, but I
> was really needing the restart filter to work on out of memory errors
> (something we've had a problem with historically).  I added the trigger,
> and it attempts to do a restart when I create an OOME, but the wrapper
> crashes 9 times out of 10 when it checks to see if the JVM halted:
>
> Shutdown complete
> Halting VM
> Critical error: wait for JVM process failed (No child processes)
>
> I've tried all sorts of wrapper.conf settings to see if something works,
> but it's only restarted twice, and it never did it more than once in a
> row.  Here's the latest config file for what it's worth.  I'm really
> hoping I'm just doing something stupid because JSW kicks ass!
>
> set.JAVA_HOME=/usr/local/java
> set.JBOSS_HOME=/usr/local/jboss
> wrapper.java.command=%JAVA_HOME%/bin/java
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
> wrapper.java.classpath.1=../lib/wrapper.jar
> wrapper.java.classpath.2=%JBOSS_HOME%/bin/run.jar
> wrapper.java.classpath.3=%JAVA_HOME%/lib/tools.jar
> wrapper.java.library.path.1=../lib
> wrapper.java.additional.1=-Dprogram.name=run.sh
> wrapper.java.additional.2=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl 
>
> wrapper.java.additional.3=-Djava.endorsed.dirs=%JBOSS_HOME%/lib/endorsed
> wrapper.java.additional.4=-verbosegc
> wrapper.java.initmemory=1024
> wrapper.java.maxmemory=1024
> wrapper.app.parameter.1=org.jboss.Main
> wrapper.console.format=M
> wrapper.console.loglevel=INFO
> wrapper.logfile=../jboss.log
> wrapper.logfile.format=LTM
> wrapper.logfile.loglevel=INFO
> wrapper.logfile.maxsize=10m
> wrapper.logfile.maxfiles=4
> wrapper.syslog.loglevel=NONE
> wrapper.filter.trigger.1=java.lang.OutOfMemoryError
> wrapper.filter.action.1=RESTART
> wrapper.restart.delay=30
>
> If anyone can throw some light my way, I'd be most indebted!
>
> David

Re: [Wrapper-user] Wrapper classpath on Windows 2000

[Leif Mortenson <leif@ta...>]

John,
    Sorry.  I had meant to post the source of the getMainMethod method.
http://cvs.sourceforge.net/viewcvs.py/wrapper/wrapper/src/java/org/tanukisoftware/wrapper/WrapperStartStopApp.java?rev=1.7&only_with_tag=RELEASE_3_1_2&view=auto

Cheers,
Leif

Leif Mortenson wrote:
> John,
>
> Volkar, John wrote:
>>> Just a thought here - what does your directory structure look like 
>>> and where are you running it from?
>>>     
>> Good thought, thanks, but...
>>   
> The Wrapper is good about forcing the current directory to be the 
> location of the
> Wrapper.exe.   That will not be the case when you run the batch file I 
> had you
> create so you will want to run that from within the correct directory.
>>> However, this wouldn't account for your Win2000 - WinXP difference, 
>>> but...it might be worth looking into.
>>>     
>> Yeah, it's the same exact directory layout on the boxes. 
>> I'm a bit hampered in testing/playing on this the only Win2000 box I
>> have available to me is only  accessible to me via remote access, when
>> the QA team isn't working on it.
>>
>> What's driving me nuts is that the invocation line works when all the
>> -Dwrapper stuff is stripped and I invoke my main class directly, but
>> thru the wrapper it doesn't...
>>
>> I'm wondering if my use of a static inner class for Start and Stop isn't
>> the problem somehow...
>>   
> That is the only thing that I can think of as well...   The 
> WrapperStartStopApp class
> has code in the getMainMethod method which is attempting to load your
> com.mckessonaps.fp2k.FP2KServiceWrapper$Start class manually.  That is
> failing for some reason.
>
> A couple more things for you to try:
> 1) Add the -verbose:class parameter to the batch file and see whether 
> or not the
> class is being loaded.
>
> 2) Change the main class from 
> com.mckessonaps.fp2k.FP2KServiceWrapper$Start
> to com.mckessonaps.fp2k.FP2KServiceWrapper and see what happens.  You 
> will
> still get an error that the main method can't be found, but that is 
> after the class has
> been successfully loaded.   Do this with the -verbose:class parameter 
> set as well.
>
> I can't think what could be causing this that would be OS specific, 
> given that it
> also happens with the batch file...  If it were a file permission 
> problem then it
> would also happen when the wrapper parameters were removed.
>
> Have you installed any non-default security policy files in that JVM?  
> There is
> nothing specified from the command line, but it is possible to edit 
> the security
> files of the JVM itself.
>
> I'll post again if I think of anything else.
> Leif

Re: [Wrapper-user] Wrapper classpath on Windows 2000

[Leif Mortenson <leif@ta...>]

John,

Volkar, John wrote:
>> Just a thought here - what does your directory structure look 
>> like and where are you running it from?
>>     
> Good thought, thanks, but...
>   
The Wrapper is good about forcing the current directory to be the 
location of the
Wrapper.exe.   That will not be the case when you run the batch file I 
had you
create so you will want to run that from within the correct directory.
>> However, this wouldn't account for your Win2000 - 
>> WinXP difference, but...it might be worth looking into.
>>     
> Yeah, it's the same exact directory layout on the boxes.  
>
> I'm a bit hampered in testing/playing on this the only Win2000 box I
> have available to me is only  accessible to me via remote access, when
> the QA team isn't working on it.
>
> What's driving me nuts is that the invocation line works when all the
> -Dwrapper stuff is stripped and I invoke my main class directly, but
> thru the wrapper it doesn't...
>
> I'm wondering if my use of a static inner class for Start and Stop isn't
> the problem somehow...
>   
That is the only thing that I can think of as well...   The 
WrapperStartStopApp class
has code in the getMainMethod method which is attempting to load your
com.mckessonaps.fp2k.FP2KServiceWrapper$Start class manually.  That is
failing for some reason.

A couple more things for you to try:
1) Add the -verbose:class parameter to the batch file and see whether or 
not the
class is being loaded.

2) Change the main class from com.mckessonaps.fp2k.FP2KServiceWrapper$Start
to com.mckessonaps.fp2k.FP2KServiceWrapper and see what happens.  You will
still get an error that the main method can't be found, but that is 
after the class has
been successfully loaded.   Do this with the -verbose:class parameter 
set as well.

I can't think what could be causing this that would be OS specific, 
given that it
also happens with the batch file...  If it were a file permission 
problem then it
would also happen when the wrapper parameters were removed.

Have you installed any non-default security policy files in that JVM?  
There is
nothing specified from the command line, but it is possible to edit the 
security
files of the JVM itself.

I'll post again if I think of anything else.
Leif

[Wrapper-user] RESTART not wanting to work

[David McCullars <dmccullars@ch...>]

I've got the wrapper working well on a CentOS 3.6 system to wrap JBoss 4
(with Sun's Java 1.5.0_05-b05).  It starts and stops perfectly, but I
was really needing the restart filter to work on out of memory errors
(something we've had a problem with historically).  I added the trigger,
and it attempts to do a restart when I create an OOME, but the wrapper
crashes 9 times out of 10 when it checks to see if the JVM halted:

Shutdown complete
Halting VM
Critical error: wait for JVM process failed (No child processes)

I've tried all sorts of wrapper.conf settings to see if something works,
but it's only restarted twice, and it never did it more than once in a
row.  Here's the latest config file for what it's worth.  I'm really
hoping I'm just doing something stupid because JSW kicks ass!

set.JAVA_HOME=/usr/local/java
set.JBOSS_HOME=/usr/local/jboss
wrapper.java.command=%JAVA_HOME%/bin/java
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=%JBOSS_HOME%/bin/run.jar
wrapper.java.classpath.3=%JAVA_HOME%/lib/tools.jar
wrapper.java.library.path.1=../lib
wrapper.java.additional.1=-Dprogram.name=run.sh
wrapper.java.additional.2=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl
wrapper.java.additional.3=-Djava.endorsed.dirs=%JBOSS_HOME%/lib/endorsed
wrapper.java.additional.4=-verbosegc
wrapper.java.initmemory=1024
wrapper.java.maxmemory=1024
wrapper.app.parameter.1=org.jboss.Main
wrapper.console.format=M
wrapper.console.loglevel=INFO
wrapper.logfile=../jboss.log
wrapper.logfile.format=LTM
wrapper.logfile.loglevel=INFO
wrapper.logfile.maxsize=10m
wrapper.logfile.maxfiles=4
wrapper.syslog.loglevel=NONE
wrapper.filter.trigger.1=java.lang.OutOfMemoryError
wrapper.filter.action.1=RESTART
wrapper.restart.delay=30

If anyone can throw some light my way, I'd be most indebted!

David

RE: [Wrapper-user] Wrapper classpath on Windows 2000

[Volkar, John <John.Volkar@McKesson.com>]

PiBKdXN0IGEgdGhvdWdodCBoZXJlIC0gd2hhdCBkb2VzIHlvdXIgZGlyZWN0b3J5IHN0cnVjdHVy
ZSBsb29rIA0KPiBsaWtlIGFuZCB3aGVyZSBhcmUgeW91IHJ1bm5pbmcgaXQgZnJvbT8NCkdvb2Qg
dGhvdWdodCwgdGhhbmtzLCBidXQuLi4NCg0KPiBIb3dldmVyLCB0aGlzIHdvdWxkbid0IGFjY291
bnQgZm9yIHlvdXIgV2luMjAwMCAtIA0KPiBXaW5YUCBkaWZmZXJlbmNlLCBidXQuLi5pdCBtaWdo
dCBiZSB3b3J0aCBsb29raW5nIGludG8uDQpZZWFoLCBpdCdzIHRoZSBzYW1lIGV4YWN0IGRpcmVj
dG9yeSBsYXlvdXQgb24gdGhlIGJveGVzLiAgDQoNCkknbSBhIGJpdCBoYW1wZXJlZCBpbiB0ZXN0
aW5nL3BsYXlpbmcgb24gdGhpcyB0aGUgb25seSBXaW4yMDAwIGJveCBJDQpoYXZlIGF2YWlsYWJs
ZSB0byBtZSBpcyBvbmx5ICBhY2Nlc3NpYmxlIHRvIG1lIHZpYSByZW1vdGUgYWNjZXNzLCB3aGVu
DQp0aGUgUUEgdGVhbSBpc24ndCB3b3JraW5nIG9uIGl0Lg0KDQpXaGF0J3MgZHJpdmluZyBtZSBu
dXRzIGlzIHRoYXQgdGhlIGludm9jYXRpb24gbGluZSB3b3JrcyB3aGVuIGFsbCB0aGUNCi1Ed3Jh
cHBlciBzdHVmZiBpcyBzdHJpcHBlZCBhbmQgSSBpbnZva2UgbXkgbWFpbiBjbGFzcyBkaXJlY3Rs
eSwgYnV0DQp0aHJ1IHRoZSB3cmFwcGVyIGl0IGRvZXNuJ3QuLi4NCg0KSSdtIHdvbmRlcmluZyBp
ZiBteSB1c2Ugb2YgYSBzdGF0aWMgaW5uZXIgY2xhc3MgZm9yIFN0YXJ0IGFuZCBTdG9wIGlzbid0
DQp0aGUgcHJvYmxlbSBzb21laG93Li4uDQoNClJlZ2FyZHMsDQpKb2huIFZvbGthciANCiAgDQpD
b25maWRlbnRpYWxpdHkgTm90aWNlOiBUaGlzIGUtbWFpbCBtZXNzYWdlLCBpbmNsdWRpbmcgYW55
IGF0dGFjaG1lbnRzLCBpcyBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll
bnQocykgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBpbmZvcm1h
dGlvbi4gQW55IHVuYXV0aG9yaXplZCByZXZpZXcsIHVzZSwgZGlzY2xvc3VyZSBvciBkaXN0cmli
dXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu
dCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kg
YWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4gDQogDQo=

Re: [Wrapper-user] Wrapper classpath on Windows 2000

[Buntingster <buntingster@gm...>]

Just a thought here - what does your directory structure look like and 
where are you running it from?

 From what I recall in the wrapper documentation, the java executable is 
launched from the directory that wrapper.exe exists in - meaning all of 
your classpath files have to be relative to your bin directory. This has 
been a source of confusion with me before - saw similiar results as you 
are seeing. However, this wouldn't account for your Win2000 - WinXP 
difference, but...it might be worth looking into.

-Jared

Volkar, John wrote:

>>It is not a command line length problem. 
>>    
>>
>Good; it didn't feel like it was and I'd be annoyed at windows if that
>were the case.
>
>  
>
>>What Java version are you running on each of your systems? 
>>Run on each system. Verify that is what is being run by the 
>>Wrapper on your XP system:
>>C:\WINNT\system32\java.exe -version
>>    
>>
>I'll just pull from the wrapper service logs...
>
>On the Win 2000 box (where it fails):
>----
>INFO   | jvm 1    | 2006/01/27 06:11:23 | Java Executable:
>C:\WINNT\system32\java.exe
>INFO   | jvm 1    | 2006/01/27 06:11:23 | Windows version: 5.0.2195
>INFO   | jvm 1    | 2006/01/27 06:11:23 | Java Version   : 1.5.0_06-b05
>Java HotSpot(TM) Client VM
>INFO   | jvm 1    | 2006/01/27 06:11:23 | Java VM Vendor : Sun
>Microsystems Inc.
>----
>
>On my WinXP (where it all works):
>----
>INFO   | jvm 1    | 2006/01/25 18:41:48 | Java Executable:
>C:\WINDOWS\system32\java.exe
>INFO   | jvm 1    | 2006/01/25 18:41:48 | Windows version: 5.1.2600
>INFO   | jvm 1    | 2006/01/25 18:41:48 | Java Version   : 1.5.0_06-b05
>Java HotSpot(TM) Client VM
>INFO   | jvm 1    | 2006/01/25 18:41:48 | Java VM Vendor : Sun
>Microsystems Inc.
>----
>
>  
>
>>Are they the same?
>>    
>>
>Looks like they are the exact same java version to me.
>
>  
>
>>I have never tried running with a main class in inner 
>>classes. There may be some problems with the way the 
>>WrapperStartStopApp class is locating the main methods.
>>    
>>
>I cannot for the life of me imagine why that would be a problem; the JVM
>is the same.  If I had to I suppose I could pull the inners out and try
>again; but I like keeping them tucked in, they are all of like 5 lines
>of code each.
>
>  
>
>>Can't think of why the platform would make a difference, but 
>>there may be some differences if the Java version is 
>>different. Once I have more info, I can try to reproduce it here.
>>    
>>
>
>Lief, thanks for your help, I'm kind of at a loss to explain this
>myself.  If I get a free moment I'll pull those inners clases out and
>see what happens.
>
>Regards,
>John Volkar 
>  
>Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
> 
>N¬HY޵隊X¬²š'²ŠÞu¼’¦[§‰ÜŒ¨º
>Þ¦Øk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£	塧m…éÞÀ@^Çš­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­þÇ¥rg–y$‰ÐÓ~7Ù¸mãÎjÐÛ^¸ÙjÚ¦—«ºÇ«™¨¥Šx%ŠËV­ªiz»¬z¹b²Û,¢êÜyú+éÞ¶m¦Ïÿ–+-²Ê.­ÇŸ¢¸ë–+-³ùb²Ø§~ð­ªiz»¬er==
>

RE: [Wrapper-user] Wrapper classpath on Windows 2000

[Volkar, John <John.Volkar@McKesson.com>]

PiBJdCBpcyBub3QgYSBjb21tYW5kIGxpbmUgbGVuZ3RoIHByb2JsZW0uIA0KR29vZDsgaXQgZGlk
bid0IGZlZWwgbGlrZSBpdCB3YXMgYW5kIEknZCBiZSBhbm5veWVkIGF0IHdpbmRvd3MgaWYgdGhh
dA0Kd2VyZSB0aGUgY2FzZS4NCg0KPiBXaGF0IEphdmEgdmVyc2lvbiBhcmUgeW91IHJ1bm5pbmcg
b24gZWFjaCBvZiB5b3VyIHN5c3RlbXM/IA0KPiBSdW4gb24gZWFjaCBzeXN0ZW0uIFZlcmlmeSB0
aGF0IGlzIHdoYXQgaXMgYmVpbmcgcnVuIGJ5IHRoZSANCj4gV3JhcHBlciBvbiB5b3VyIFhQIHN5
c3RlbToNCj4gQzpcV0lOTlRcc3lzdGVtMzJcamF2YS5leGUgLXZlcnNpb24NCkknbGwganVzdCBw
dWxsIGZyb20gdGhlIHdyYXBwZXIgc2VydmljZSBsb2dzLi4uDQoNCk9uIHRoZSBXaW4gMjAwMCBi
b3ggKHdoZXJlIGl0IGZhaWxzKToNCi0tLS0NCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8y
NyAwNjoxMToyMyB8IEphdmEgRXhlY3V0YWJsZToNCkM6XFdJTk5UXHN5c3RlbTMyXGphdmEuZXhl
DQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBXaW5kb3dzIHZlcnNp
b246IDUuMC4yMTk1DQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBK
YXZhIFZlcnNpb24gICA6IDEuNS4wXzA2LWIwNQ0KSmF2YSBIb3RTcG90KFRNKSBDbGllbnQgVk0N
CklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAwNjoxMToyMyB8IEphdmEgVk0gVmVuZG9y
IDogU3VuDQpNaWNyb3N5c3RlbXMgSW5jLg0KLS0tLQ0KDQpPbiBteSBXaW5YUCAod2hlcmUgaXQg
YWxsIHdvcmtzKToNCi0tLS0NCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNSAxODo0MTo0
OCB8IEphdmEgRXhlY3V0YWJsZToNCkM6XFdJTkRPV1Ncc3lzdGVtMzJcamF2YS5leGUNCklORk8g
ICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNSAxODo0MTo0OCB8IFdpbmRvd3MgdmVyc2lvbjogNS4x
LjI2MDANCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNSAxODo0MTo0OCB8IEphdmEgVmVy
c2lvbiAgIDogMS41LjBfMDYtYjA1DQpKYXZhIEhvdFNwb3QoVE0pIENsaWVudCBWTQ0KSU5GTyAg
IHwganZtIDEgICAgfCAyMDA2LzAxLzI1IDE4OjQxOjQ4IHwgSmF2YSBWTSBWZW5kb3IgOiBTdW4N
Ck1pY3Jvc3lzdGVtcyBJbmMuDQotLS0tDQoNCj4gQXJlIHRoZXkgdGhlIHNhbWU/DQpMb29rcyBs
aWtlIHRoZXkgYXJlIHRoZSBleGFjdCBzYW1lIGphdmEgdmVyc2lvbiB0byBtZS4NCg0KPiBJIGhh
dmUgbmV2ZXIgdHJpZWQgcnVubmluZyB3aXRoIGEgbWFpbiBjbGFzcyBpbiBpbm5lciANCj4gY2xh
c3Nlcy4gVGhlcmUgbWF5IGJlIHNvbWUgcHJvYmxlbXMgd2l0aCB0aGUgd2F5IHRoZSANCj4gV3Jh
cHBlclN0YXJ0U3RvcEFwcCBjbGFzcyBpcyBsb2NhdGluZyB0aGUgbWFpbiBtZXRob2RzLg0KSSBj
YW5ub3QgZm9yIHRoZSBsaWZlIG9mIG1lIGltYWdpbmUgd2h5IHRoYXQgd291bGQgYmUgYSBwcm9i
bGVtOyB0aGUgSlZNDQppcyB0aGUgc2FtZS4gIElmIEkgaGFkIHRvIEkgc3VwcG9zZSBJIGNvdWxk
IHB1bGwgdGhlIGlubmVycyBvdXQgYW5kIHRyeQ0KYWdhaW47IGJ1dCBJIGxpa2Uga2VlcGluZyB0
aGVtIHR1Y2tlZCBpbiwgdGhleSBhcmUgYWxsIG9mIGxpa2UgNSBsaW5lcw0Kb2YgY29kZSBlYWNo
Lg0KDQo+IENhbid0IHRoaW5rIG9mIHdoeSB0aGUgcGxhdGZvcm0gd291bGQgbWFrZSBhIGRpZmZl
cmVuY2UsIGJ1dCANCj4gdGhlcmUgbWF5IGJlIHNvbWUgZGlmZmVyZW5jZXMgaWYgdGhlIEphdmEg
dmVyc2lvbiBpcyANCj4gZGlmZmVyZW50LiBPbmNlIEkgaGF2ZSBtb3JlIGluZm8sIEkgY2FuIHRy
eSB0byByZXByb2R1Y2UgaXQgaGVyZS4NCg0KTGllZiwgdGhhbmtzIGZvciB5b3VyIGhlbHAsIEkn
bSBraW5kIG9mIGF0IGEgbG9zcyB0byBleHBsYWluIHRoaXMNCm15c2VsZi4gIElmIEkgZ2V0IGEg
ZnJlZSBtb21lbnQgSSdsbCBwdWxsIHRob3NlIGlubmVycyBjbGFzZXMgb3V0IGFuZA0Kc2VlIHdo
YXQgaGFwcGVucy4NCg0KUmVnYXJkcywNCkpvaG4gVm9sa2FyIA0KICANCkNvbmZpZGVudGlhbGl0
eSBOb3RpY2U6IFRoaXMgZS1tYWlsIG1lc3NhZ2UsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMs
IGlzIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBhbmQgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBBbnkgdW5h
dXRob3JpemVkIHJldmlldywgdXNlLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9o
aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u
dGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9m
IHRoZSBvcmlnaW5hbCBtZXNzYWdlLiANCiANCg==

Re: [Wrapper-user] Wrapper classpath on Windows 2000

[Leif Mortenson <leif@ta...>]

John,
It is not a command line length problem. The message you are getting is 
correctly showing
you the full name of the file that could not be loaded. If the command 
line were being
truncated somehow, you wouldn't see that.

What Java version are you running on each of your systems? Are they the 
same?
Run on each system. Verify that is what is being run by the Wrapper on 
your XP system:
C:\WINNT\system32\java.exe -version

I have never tried running with a main class in inner classes. There may 
be some
problems with the way the WrapperStartStopApp class is locating the main 
methods.
Can't think of why the platform would make a difference, but there may 
be some
differences if the Java version is different. Once I have more info, I 
can try to
reproduce it here.

Cheers,
Leif

Volkar, John wrote:
>>     Open your debug wrapper.log in an editor and copy the 
>> full command used to launch the Wrapper into a new batch file.   
>>     
> Done.
>
>   
>> Questions.
>> 1) Does the above batch file fail in the same way as the Wrapper?
>>     
> Yes, class not found.  Here's the full line from the batch file;
> remember everything works just fine on WinXP; so this *has* to be Win
> 2000 related.
>
> ----
> "C:\WINNT\system32\java.exe" -Dlog4j.configuration=FP2K.properties
> -Xms64m -Xmx128m -Djava.library.path="./" -classpath
> "FlexP2KInterface-1.4.2-src.jar;./lib/commons-codec-1.3.jar;./lib/common
> s-httpclient-2.0.2.jar;./lib/commons-logging-1.0.2.jar;./lib/log4j-1.2.1
> 3.jar;./lib/xmlrpc-2.0.jar;./lib/jtds-1.2.jar;./lib/wrapper.jar"
> -Dwrapper.port=32000 -Dwrapper.debug="TRUE"
> -Dwrapper.use_system_time="TRUE" -Dwrapper.version="3.1.2"
> -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
> -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperStartStopApp
> com.mckessonaps.fp2k.FP2KServiceWrapper$Start 0
> com.mckessonaps.fp2k.FP2KServiceWrapper$Stop true 0
> ----
>
>
>   
>> 2) What is being used for your java command?  Is it locating 
>> java on the PATH or have you specified an absolute JVM to use?
>>     
> It's locating it on the path, I'm not specifying a jvm.  As you can see
> above it's using one from WINNT\system32 which I think the standard JRE
> install dumps there.
>
>
>   
>> 3) What is the class that is failing to load?  What jar is it 
>> found in?  and Does that jar file appear in the command in the batch
>>     
> file?
> It's my main start class passed to the WrapperStartStopApp, and it's
> found in the very first jar specified in the classpath...  (I use a pair
> of static inner classes named Start and Stop as you can see in the
> invokation above...
>
> As an additional datapoint the following runs just fine and starts my
> app; the only thig different is that I trimmed out all of the -Dwrapper
> stuff and directly invoke my main Start class...
>
> ----
> "C:\WINNT\system32\java.exe" -Dlog4j.configuration=FP2K.properties
> -Xms64m -Xmx128m -Djava.library.path="./" -classpath
> "FlexP2KInterface-1.4.2-src.jar;./lib/commons-codec-1.3.jar;./lib/common
> s-httpclient-2.0.2.jar;./lib/commons-logging-1.0.2.jar;./lib/log4j-1.2.1
> 3.jar;./lib/xmlrpc-2.0.jar;./lib/jtds-1.2.jar;./lib/wrapper.jar"
> com.mckessonaps.fp2k.FP2KServiceWrapper$Start 
> ----
>
> Maybe it *is* something to do with the maximum length of the command
> line... ?  Help appreciated, thanks!
>
> Regards,
> John Volkar
>
>
> PS: Just for completeness the following is the log file generated by the
> wrapper from which I copied the invokation, there's not much to see;
> just that it's a class not found...
> ----
> STATUS | wrapper  | 2006/01/27 06:11:23 | --> Wrapper Started as Console
> DEBUG  | wrapper  | 2006/01/27 06:11:23 | Using system timer.
> DEBUG  | wrapperp | 2006/01/27 06:11:23 | server listening on port
> 32000.
> STATUS | wrapper  | 2006/01/27 06:11:23 | Launching a JVM...
> DEBUG  | wrapper  | 2006/01/27 06:11:23 | command:
> "C:\WINNT\system32\java.exe" -Dlog4j.configuration=FP2K.properties
> -Xms64m -Xmx128m -Djava.library.path="./" -classpath
> "FlexP2KInterface-1.4.2-src.jar;./lib/commons-codec-1.3.jar;./lib/common
> s-httpclient-2.0.2.jar;./lib/commons-logging-1.0.2.jar;./lib/log4j-1.2.1
> 3.jar;./lib/xmlrpc-2.0.jar;./lib/jtds-1.2.jar;./lib/wrapper.jar"
> -Dwrapper.key="e18uqhBFNXSzDRKh" -Dwrapper.port=32000
> -Dwrapper.debug="TRUE" -Dwrapper.use_system_time="TRUE"
> -Dwrapper.version="3.1.2" -Dwrapper.native_library="wrapper"
> -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1
> org.tanukisoftware.wrapper.WrapperStartStopApp
> com.mckessonaps.fp2k.FP2KServiceWrapper$Start 0
> com.mckessonaps.fp2k.FP2KServiceWrapper$Stop true 0
> DEBUG  | wrapper  | 2006/01/27 06:11:23 | JVM started (PID=2276)
> INFO   | jvm 1    | 2006/01/27 06:11:23 | WrapperStartStopApp: Unable to
> locate the class com.mckessonaps.fp2k.FP2KServiceWrapper$Start:
> java.lang.ClassNotFoundException:
> com.mckessonaps.fp2k.FP2KServiceWrapper$Start
> INFO   | jvm 1    | 2006/01/27 06:11:23 | 
> INFO   | jvm 1    | 2006/01/27 06:11:23 | WrapperStartStopApp Usage:
> INFO   | jvm 1    | 2006/01/27 06:11:23 |   java
> org.tanukisoftware.wrapper.WrapperStartStopApp {start_class}
> {start_arg_count} [start_arguments] {stop_class} {stop_wait}
> {stop_arg_count} [stop_arguments]
> INFO   | jvm 1    | 2006/01/27 06:11:23 | 
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Where:
> INFO   | jvm 1    | 2006/01/27 06:11:23 |   start_class:     The fully
> qualified class name to run to start the 
> INFO   | jvm 1    | 2006/01/27 06:11:23 |
> application.
> INFO   | jvm 1    | 2006/01/27 06:11:23 |   start_arg_count: The number
> of arguments to be passed to the start class's 
> INFO   | jvm 1    | 2006/01/27 06:11:23 |                    main
> method.
> INFO   | jvm 1    | 2006/01/27 06:11:23 |   stop_class:      The fully
> qualified class name to run to stop the 
> INFO   | jvm 1    | 2006/01/27 06:11:23 |
> application.
> INFO   | jvm 1    | 2006/01/27 06:11:23 |   stop_wait:       When
> stopping, should the Wrapper wait for all threads to 
> INFO   | jvm 1    | 2006/01/27 06:11:23 |                    complete
> before exiting (true/false).
> INFO   | jvm 1    | 2006/01/27 06:11:23 |   stop_arg_count:  The number
> of arguments to be passed to the stop class's 
> INFO   | jvm 1    | 2006/01/27 06:11:23 |                    main
> method.
> INFO   | jvm 1    | 2006/01/27 06:11:23 |   app_parameters:  The
> parameters that would normally be passed to the
> INFO   | jvm 1    | 2006/01/27 06:11:23 |
> application.
> INFO   | jvm 1    | 2006/01/27 06:11:23 | WrapperManager class
> initialized by thread: main  Using classloader:
> sun.misc.Launcher$ExtClassLoader@...
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Wrapper Manager: JVM #1
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Wrapper Manager: Registering
> shutdown hook
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Wrapper Manager: Using wrapper
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Loaded native library:
> wrapper.dll
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Calling native initialization
> method.
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Initializing WrapperManager
> native library.
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Java Executable:
> C:\WINNT\system32\java.exe
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Windows version: 5.0.2195
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Java Version   : 1.5.0_06-b05
> Java HotSpot(TM) Client VM
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Java VM Vendor : Sun
> Microsystems Inc.
> INFO   | jvm 1    | 2006/01/27 06:11:23 | 
> INFO   | jvm 1    | 2006/01/27 06:11:23 | WrapperManager.stop(1) called
> by thread: main
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Open socket to wrapper...
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Opened Socket
> INFO   | jvm 1    | 2006/01/27 06:11:23 | Send a packet KEY :
> e18uqhBFNXSzDRKh
> INFO   | jvm 1    | 2006/01/27 06:11:23 |
> handleSocket(Socket[addr=/127.0.0.1,port=32000,localport=1332])
> DEBUG  | wrapperp | 2006/01/27 06:11:23 | accepted a socket from
> 127.0.0.1 on port 1332
> DEBUG  | wrapperp | 2006/01/27 06:11:23 | read a packet KEY :
> e18uqhBFNXSzDRKh
> DEBUG  | wrapper  | 2006/01/27 06:11:23 | Got key from JVM:
> e18uqhBFNXSzDRKh
> DEBUG  | wrapperp | 2006/01/27 06:11:23 | send a packet LOW_LOG_LEVEL :
> 1
> DEBUG  | wrapperp | 2006/01/27 06:11:23 | send a packet PING_TIMEOUT :
> 30
> DEBUG  | wrapper  | 2006/01/27 06:11:23 | Start Application.
> DEBUG  | wrapperp | 2006/01/27 06:11:23 | send a packet START : start
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Received a packet
> LOW_LOG_LEVEL : 1
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Wrapper Manager: LowLogLevel
> from Wrapper is 1
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Received a packet PING_TIMEOUT
> : 30
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Wrapper Manager: PingTimeout
> from Wrapper is 30000
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Received a packet START :
> start
> INFO   | jvm 1    | 2006/01/27 06:11:24 | calling listener.start()
> INFO   | jvm 1    | 2006/01/27 06:11:24 | returned from listener.start()
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Send a packet STARTED : 
> INFO   | jvm 1    | 2006/01/27 06:11:24 | All non-daemon threads have
> stopped.  Exiting.
> INFO   | jvm 1    | 2006/01/27 06:11:24 | WrapperManager.stop(0) called
> by thread: Wrapper-Connection
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Thread, Wrapper-Connection,
> handling the shutdown process.
> INFO   | jvm 1    | 2006/01/27 06:11:24 | calling listener.stop()
> INFO   | jvm 1    | 2006/01/27 06:11:24 | returned from listener.stop()
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Send a packet STOPPED : 0
> DEBUG  | wrapperp | 2006/01/27 06:11:24 | read a packet STARTED : 
> DEBUG  | wrapper  | 2006/01/27 06:11:24 | JVM signalled that it was
> started.
> DEBUG  | wrapperp | 2006/01/27 06:11:24 | read a packet STOPPED : 0
> DEBUG  | wrapper  | 2006/01/27 06:11:24 | JVM signalled that it was
> stopped.
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Closing socket.
> DEBUG  | wrapperp | 2006/01/27 06:11:24 | socket read no code (closed?).
> INFO   | jvm 1    | 2006/01/27 06:11:24 | calling System.exit(0)
> INFO   | jvm 1    | 2006/01/27 06:11:24 | Send a packet STOP : 1
> DEBUG  | wrapper  | 2006/01/27 06:11:24 | JVM process exited with a code
> of 0, leaving the wrapper exit code set to 0.
> DEBUG  | wrapper  | 2006/01/27 06:11:24 | JVM exited normally.
> STATUS | wrapper  | 2006/01/27 06:11:25 | <-- Wrapper Stopped
> ---- 
>   
> Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
>  
> N¬HY޵隊X¬²š'²ŠÞu¼’¦[§‰ÜŒ¨º
> Þ¦Øk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£	塧m…éÞÀ@^Çš­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­þÇ¥rg–y$‰ÐÓ~7Ù¸mãÎjÐÛ^¸ÙjÚ¦—«ºÇ«™¨¥Šx%ŠËV­ªiz»¬z¹b²Û,¢êÜyú+éÞ¶m¦Ïÿ–+-²Ê.­ÇŸ¢¸ë–+-³ùb²Ø§~ð­ªiz»¬er==

Re: [Wrapper-user] Passing command line parms with WrapperStartStopApp

[Jim McLean <Jim.McLean@fa...>]

<html><body>
<p>Thanks, I'll try that out=2E<br>
<br>
Jim McLean<br>
<br>
<img src=3D"cid:00__=3D0ABBFB90DFDAD5498f9e8a93df938@...=2Ecom" widt=
h=3D"16" height=3D"16" alt=3D"Inactive hide details for Leif Mortenson =
&lt;leif@...=2Ecom&gt;">Leif Mortenson &lt;leif@...=
re=2Ecom&gt;<br>
<br>
<br>

<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=

<tr valign=3D"top"><td style=3D"background-image:url(cid:10__=3D0ABBFB9=
0DFDAD5498f9e8a93df938@...=2Ecom); background-repeat: no-repeat; " w=
idth=3D"40%">
<ul>
<ul>
<ul>
<ul><b><font size=3D"2">Leif Mortenson &lt;leif@...=2Ecom&gt=
;</font></b><font size=3D"2"> </font><br>
<font size=3D"2">Sent by: wrapper-user-admin@...=2Esourceforge=2Enet<=
/font>
<p><font size=3D"2">26/01/2006 08:37 PM</font>
<table border=3D"1">
<tr valign=3D"top"><td width=3D"168" bgcolor=3D"#FFFFFF"><div align=3D"=
center"><font size=3D"2">Please respond to<br>
wrapper-user@...=2Esourceforge=2Enet</font></div></td></tr>
</table>
</ul>
</ul>
</ul>
</ul>
</td><td width=3D"60%">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=

<tr valign=3D"top"><td width=3D"1%"><img src=3D"cid:20__=3D0ABBFB90DFDA=
D5498f9e8a93df938@...=2Ecom" border=3D"0" height=3D"1" width=3D"58" =
alt=3D""><br>
<div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"=
100%"><img src=3D"cid:20__=3D0ABBFB90DFDAD5498f9e8a93df938@...=2Ecom=
" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">wrapper-user@...=2Esourceforge=2Enet</font></td></tr=
>

<tr valign=3D"top"><td width=3D"1%"><img src=3D"cid:20__=3D0ABBFB90DFDA=
D5498f9e8a93df938@...=2Ecom" border=3D"0" height=3D"1" width=3D"58" =
alt=3D""><br>
<div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"=
100%"><img src=3D"cid:20__=3D0ABBFB90DFDAD5498f9e8a93df938@...=2Ecom=
" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
</td></tr>

<tr valign=3D"top"><td width=3D"1%"><img src=3D"cid:20__=3D0ABBFB90DFDA=
D5498f9e8a93df938@...=2Ecom" border=3D"0" height=3D"1" width=3D"58" =
alt=3D""><br>
<div align=3D"right"><font size=3D"2">Subject</font></div></td><td widt=
h=3D"100%"><img src=3D"cid:20__=3D0ABBFB90DFDAD5498f9e8a93df938@...=2E=
com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">Re: [Wrapper-user] Passing command line parms with Wra=
pperStartStopApp</font></td></tr>
</table>

<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
<tr valign=3D"top"><td width=3D"58"><img src=3D"cid:20__=3D0ABBFB90DFDA=
D5498f9e8a93df938@...=2Ecom" border=3D"0" height=3D"1" width=3D"1" a=
lt=3D""></td><td width=3D"336"><img src=3D"cid:20__=3D0ABBFB90DFDAD5498=
f9e8a93df938@...=2Ecom" border=3D"0" height=3D"1" width=3D"1" alt=3D=
""></td></tr>
</table>
</td></tr>
</table>
<br>
<tt>Jim,<br>
 &nbsp; &nbsp;Are you running on Windows or a UNIX platform? &nbsp;In e=
ither case, you <br>
need to<br>
modify the script used to launch the Wrapper so the additional <br>
parameters passed to<br>
the script will be passed on to the Wrapper when it is launched=2E<br>
<br>
 &nbsp; &nbsp;First modify your wrapper=2Econf as follows:<br>
wrapper=2Eapp=2Eparameter=2E1=3Dcom=2Efarrow=2Eimaging=2EScannedImageCo=
pier<br>
wrapper=2Eapp=2Eparameter=2E2=3D1<br>
wrapper=2Eapp=2Eparameter=2E3=3Dstart<br>
wrapper=2Eapp=2Eparameter=2E4=3Dcom=2Efarrow=2Eservice=2EShutdownServic=
e<br>
wrapper=2Eapp=2Eparameter=2E5=3Dtrue<br>
wrapper=2Eapp=2Eparameter=2E6=3D2<br>
wrapper=2Eapp=2Eparameter=2E7=3Dstop<br>
wrapper=2Eapp=2Eparameter=2E8=3DPARAM1_PLACEHOLDER<br>
<br>
 &nbsp; &nbsp;Then modify your App=2Ebat=2Ein script as follows: (Windo=
ws)<br>
&quot;%_WRAPPER_EXE%&quot; -c %_WRAPPER_CONF% wrapper=2Eapp=2Eparameter=
=2E8=3D%1<br>
<br>
 &nbsp; &nbsp;This will take the first parameter to the batch file and =
use it as <br>
the 8th parameter<br>
when launching the JVM=2E &nbsp; It is not possible to specify such a p=
arameter <br>
when stopping<br>
the service=2E &nbsp;You have to know what it will be when the service =
is <br>
started in the first<br>
place=2E &nbsp; This will work when installing the service as well=2E &=
quot;-c&quot; would <br>
be &quot;-i&quot;<br>
Note the 8th parameter in the conf file is not required, but it makes i=
t <br>
more obvious<br>
what is happening if a 9th parameter is also added=2E<br>
<br>
Cheers,<br>
Leif<br>
<br>
Jim McLean wrote:<br>
&gt;<br>
&gt; Hi List,<br>
&gt;<br>
&gt; I'm trying to pass command line params to the program that is goin=
g to <br>
&gt; perform the stop=2E How can this be done?<br>
&gt;<br>
&gt;<br>
&gt; Here's what my config file looks like:<br>
&gt;<br>
&gt; wrapper=2Ejava=2Ecommand=3D%JAVA_HOME%/bin/java<br>
&gt;<br>
&gt; wrapper=2Ejava=2Eclasspath=2E1=3D=2E=2E/lib/wrapper=2Ejar<br>
&gt; wrapper=2Ejava=2Eclasspath=2E2=3D=2E=2E/lib/ScannedImageCopier=2Ej=
ar<br>
&gt; wrapper=2Ejava=2Eclasspath=2E3=3D=2E=2E/lib/jt400=2Ejar<br>
&gt; wrapper=2Ejava=2Eclasspath=2E4=3D=2E=2E/lib/log4j-1=2E2=2E9=2Ejar<=
br>
&gt; wrapper=2Ejava=2Eclasspath=2E5=3D=2E=2E/lib/mail=2Ejar<br>
&gt; wrapper=2Ejava=2Eclasspath=2E6=3D=2E=2E/lib/activation=2Ejar<br>
&gt;<br>
&gt; wrapper=2Ejava=2Elibrary=2Epath=2E1=3D=2E=2E/lib<br>
&gt;<br>
&gt; wrapper=2Elogfile=3D=2E=2E/logs/wrapper=2Elog<br>
&gt; wrapper=2Elogfile=2Emaxfiles=3D5<br>
&gt; wrapper=2Elogfile=2Emaxsize=3D1m<br>
&gt;<br>
&gt; wrapper=2Ejava=2Emainclass=3Dorg=2Etanukisoftware=2Ewrapper=2EWrap=
perStartStopApp<br>
&gt;<br>
&gt; wrapper=2Eapp=2Eparameter=2E1=3Dcom=2Efarrow=2Eimaging=2EScannedIm=
ageCopier<br>
&gt; wrapper=2Eapp=2Eparameter=2E2=3D1<br>
&gt; wrapper=2Eapp=2Eparameter=2E3=3Dstart<br>
&gt; wrapper=2Eapp=2Eparameter=2E4=3Dcom=2Efarrow=2Eservice=2EShutdownS=
ervice<br>
&gt; wrapper=2Eapp=2Eparameter=2E5=3Dtrue<br>
&gt; wrapper=2Eapp=2Eparameter=2E6=3D1<br>
&gt; wrapper=2Eapp=2Eparameter=2E7=3Dstop<br>
&gt;<br>
&gt; Much Thanks,<br>
&gt; Jim<br>
&gt;<br>
<br>
<br>
<br>
-------------------------------------------------------<br>
This SF=2Enet email is sponsored by: Splunk Inc=2E Do you grep through =
log files<br>
for problems? &nbsp;Stop! &nbsp;Download the new AJAX search engine tha=
t makes<br>
searching your log files as easy as surfing the &nbsp;web=2E &nbsp;DOWN=
LOAD SPLUNK!<br>
</tt><tt><a href=3D"http://sel=2Eas-us=2Efalkag=2Enet/sel?cmd=3Dlnk&kid=
=3D103432&bid=3D230486&dat=3D121642">http://sel=2Eas-us=2Efalkag=2Enet/=
sel?cmd=3Dlnk&amp;kid=3D103432&amp;bid=3D230486&amp;dat=3D121642</a></t=
t><tt><br>
_______________________________________________<br>
Wrapper-user mailing list<br>
Wrapper-user@...=2Esourceforge=2Enet<br>
</tt><tt><a href=3D"https://lists=2Esourceforge=2Enet/lists/listinfo/wr=
apper-user">https://lists=2Esourceforge=2Enet/lists/listinfo/wrapper-us=
er</a></tt><tt><br>
</tt><br>
</body></html>=

RE: [Wrapper-user] Wrapper classpath on Windows 2000

[Volkar, John <John.Volkar@McKesson.com>]

PiAgICAgT3BlbiB5b3VyIGRlYnVnIHdyYXBwZXIubG9nIGluIGFuIGVkaXRvciBhbmQgY29weSB0
aGUgDQo+IGZ1bGwgY29tbWFuZCB1c2VkIHRvIGxhdW5jaCB0aGUgV3JhcHBlciBpbnRvIGEgbmV3
IGJhdGNoIGZpbGUuICAgDQpEb25lLg0KDQo+IFF1ZXN0aW9ucy4NCj4gMSkgRG9lcyB0aGUgYWJv
dmUgYmF0Y2ggZmlsZSBmYWlsIGluIHRoZSBzYW1lIHdheSBhcyB0aGUgV3JhcHBlcj8NClllcywg
Y2xhc3Mgbm90IGZvdW5kLiAgSGVyZSdzIHRoZSBmdWxsIGxpbmUgZnJvbSB0aGUgYmF0Y2ggZmls
ZTsNCnJlbWVtYmVyIGV2ZXJ5dGhpbmcgd29ya3MganVzdCBmaW5lIG9uIFdpblhQOyBzbyB0aGlz
ICpoYXMqIHRvIGJlIFdpbg0KMjAwMCByZWxhdGVkLg0KDQotLS0tDQoiQzpcV0lOTlRcc3lzdGVt
MzJcamF2YS5leGUiIC1EbG9nNGouY29uZmlndXJhdGlvbj1GUDJLLnByb3BlcnRpZXMNCi1YbXM2
NG0gLVhteDEyOG0gLURqYXZhLmxpYnJhcnkucGF0aD0iLi8iIC1jbGFzc3BhdGgNCiJGbGV4UDJL
SW50ZXJmYWNlLTEuNC4yLXNyYy5qYXI7Li9saWIvY29tbW9ucy1jb2RlYy0xLjMuamFyOy4vbGli
L2NvbW1vbg0Kcy1odHRwY2xpZW50LTIuMC4yLmphcjsuL2xpYi9jb21tb25zLWxvZ2dpbmctMS4w
LjIuamFyOy4vbGliL2xvZzRqLTEuMi4xDQozLmphcjsuL2xpYi94bWxycGMtMi4wLmphcjsuL2xp
Yi9qdGRzLTEuMi5qYXI7Li9saWIvd3JhcHBlci5qYXIiDQotRHdyYXBwZXIucG9ydD0zMjAwMCAt
RHdyYXBwZXIuZGVidWc9IlRSVUUiDQotRHdyYXBwZXIudXNlX3N5c3RlbV90aW1lPSJUUlVFIiAt
RHdyYXBwZXIudmVyc2lvbj0iMy4xLjIiDQotRHdyYXBwZXIubmF0aXZlX2xpYnJhcnk9IndyYXBw
ZXIiIC1Ed3JhcHBlci5jcHUudGltZW91dD0iMTAiDQotRHdyYXBwZXIuanZtaWQ9MSBvcmcudGFu
dWtpc29mdHdhcmUud3JhcHBlci5XcmFwcGVyU3RhcnRTdG9wQXBwDQpjb20ubWNrZXNzb25hcHMu
ZnAyay5GUDJLU2VydmljZVdyYXBwZXIkU3RhcnQgMA0KY29tLm1ja2Vzc29uYXBzLmZwMmsuRlAy
S1NlcnZpY2VXcmFwcGVyJFN0b3AgdHJ1ZSAwDQotLS0tDQoNCg0KPiAyKSBXaGF0IGlzIGJlaW5n
IHVzZWQgZm9yIHlvdXIgamF2YSBjb21tYW5kPyAgSXMgaXQgbG9jYXRpbmcgDQo+IGphdmEgb24g
dGhlIFBBVEggb3IgaGF2ZSB5b3Ugc3BlY2lmaWVkIGFuIGFic29sdXRlIEpWTSB0byB1c2U/DQpJ
dCdzIGxvY2F0aW5nIGl0IG9uIHRoZSBwYXRoLCBJJ20gbm90IHNwZWNpZnlpbmcgYSBqdm0uICBB
cyB5b3UgY2FuIHNlZQ0KYWJvdmUgaXQncyB1c2luZyBvbmUgZnJvbSBXSU5OVFxzeXN0ZW0zMiB3
aGljaCBJIHRoaW5rIHRoZSBzdGFuZGFyZCBKUkUNCmluc3RhbGwgZHVtcHMgdGhlcmUuDQoNCg0K
PiAzKSBXaGF0IGlzIHRoZSBjbGFzcyB0aGF0IGlzIGZhaWxpbmcgdG8gbG9hZD8gIFdoYXQgamFy
IGlzIGl0IA0KPiBmb3VuZCBpbj8gIGFuZCBEb2VzIHRoYXQgamFyIGZpbGUgYXBwZWFyIGluIHRo
ZSBjb21tYW5kIGluIHRoZSBiYXRjaA0KZmlsZT8NCkl0J3MgbXkgbWFpbiBzdGFydCBjbGFzcyBw
YXNzZWQgdG8gdGhlIFdyYXBwZXJTdGFydFN0b3BBcHAsIGFuZCBpdCdzDQpmb3VuZCBpbiB0aGUg
dmVyeSBmaXJzdCBqYXIgc3BlY2lmaWVkIGluIHRoZSBjbGFzc3BhdGguLi4gIChJIHVzZSBhIHBh
aXINCm9mIHN0YXRpYyBpbm5lciBjbGFzc2VzIG5hbWVkIFN0YXJ0IGFuZCBTdG9wIGFzIHlvdSBj
YW4gc2VlIGluIHRoZQ0KaW52b2thdGlvbiBhYm92ZS4uLg0KDQpBcyBhbiBhZGRpdGlvbmFsIGRh
dGFwb2ludCB0aGUgZm9sbG93aW5nIHJ1bnMganVzdCBmaW5lIGFuZCBzdGFydHMgbXkNCmFwcDsg
dGhlIG9ubHkgdGhpZyBkaWZmZXJlbnQgaXMgdGhhdCBJIHRyaW1tZWQgb3V0IGFsbCBvZiB0aGUg
LUR3cmFwcGVyDQpzdHVmZiBhbmQgZGlyZWN0bHkgaW52b2tlIG15IG1haW4gU3RhcnQgY2xhc3Mu
Li4NCg0KLS0tLQ0KIkM6XFdJTk5UXHN5c3RlbTMyXGphdmEuZXhlIiAtRGxvZzRqLmNvbmZpZ3Vy
YXRpb249RlAySy5wcm9wZXJ0aWVzDQotWG1zNjRtIC1YbXgxMjhtIC1EamF2YS5saWJyYXJ5LnBh
dGg9Ii4vIiAtY2xhc3NwYXRoDQoiRmxleFAyS0ludGVyZmFjZS0xLjQuMi1zcmMuamFyOy4vbGli
L2NvbW1vbnMtY29kZWMtMS4zLmphcjsuL2xpYi9jb21tb24NCnMtaHR0cGNsaWVudC0yLjAuMi5q
YXI7Li9saWIvY29tbW9ucy1sb2dnaW5nLTEuMC4yLmphcjsuL2xpYi9sb2c0ai0xLjIuMQ0KMy5q
YXI7Li9saWIveG1scnBjLTIuMC5qYXI7Li9saWIvanRkcy0xLjIuamFyOy4vbGliL3dyYXBwZXIu
amFyIg0KY29tLm1ja2Vzc29uYXBzLmZwMmsuRlAyS1NlcnZpY2VXcmFwcGVyJFN0YXJ0IA0KLS0t
LQ0KDQpNYXliZSBpdCAqaXMqIHNvbWV0aGluZyB0byBkbyB3aXRoIHRoZSBtYXhpbXVtIGxlbmd0
aCBvZiB0aGUgY29tbWFuZA0KbGluZS4uLiA/ICBIZWxwIGFwcHJlY2lhdGVkLCB0aGFua3MhDQoN
ClJlZ2FyZHMsDQpKb2huIFZvbGthcg0KDQoNClBTOiBKdXN0IGZvciBjb21wbGV0ZW5lc3MgdGhl
IGZvbGxvd2luZyBpcyB0aGUgbG9nIGZpbGUgZ2VuZXJhdGVkIGJ5IHRoZQ0Kd3JhcHBlciBmcm9t
IHdoaWNoIEkgY29waWVkIHRoZSBpbnZva2F0aW9uLCB0aGVyZSdzIG5vdCBtdWNoIHRvIHNlZTsN
Cmp1c3QgdGhhdCBpdCdzIGEgY2xhc3Mgbm90IGZvdW5kLi4uDQotLS0tDQpTVEFUVVMgfCB3cmFw
cGVyICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCAtLT4gV3JhcHBlciBTdGFydGVkIGFzIENvbnNv
bGUNCkRFQlVHICB8IHdyYXBwZXIgIHwgMjAwNi8wMS8yNyAwNjoxMToyMyB8IFVzaW5nIHN5c3Rl
bSB0aW1lci4NCkRFQlVHICB8IHdyYXBwZXJwIHwgMjAwNi8wMS8yNyAwNjoxMToyMyB8IHNlcnZl
ciBsaXN0ZW5pbmcgb24gcG9ydA0KMzIwMDAuDQpTVEFUVVMgfCB3cmFwcGVyICB8IDIwMDYvMDEv
MjcgMDY6MTE6MjMgfCBMYXVuY2hpbmcgYSBKVk0uLi4NCkRFQlVHICB8IHdyYXBwZXIgIHwgMjAw
Ni8wMS8yNyAwNjoxMToyMyB8IGNvbW1hbmQ6DQoiQzpcV0lOTlRcc3lzdGVtMzJcamF2YS5leGUi
IC1EbG9nNGouY29uZmlndXJhdGlvbj1GUDJLLnByb3BlcnRpZXMNCi1YbXM2NG0gLVhteDEyOG0g
LURqYXZhLmxpYnJhcnkucGF0aD0iLi8iIC1jbGFzc3BhdGgNCiJGbGV4UDJLSW50ZXJmYWNlLTEu
NC4yLXNyYy5qYXI7Li9saWIvY29tbW9ucy1jb2RlYy0xLjMuamFyOy4vbGliL2NvbW1vbg0Kcy1o
dHRwY2xpZW50LTIuMC4yLmphcjsuL2xpYi9jb21tb25zLWxvZ2dpbmctMS4wLjIuamFyOy4vbGli
L2xvZzRqLTEuMi4xDQozLmphcjsuL2xpYi94bWxycGMtMi4wLmphcjsuL2xpYi9qdGRzLTEuMi5q
YXI7Li9saWIvd3JhcHBlci5qYXIiDQotRHdyYXBwZXIua2V5PSJlMTh1cWhCRk5YU3pEUktoIiAt
RHdyYXBwZXIucG9ydD0zMjAwMA0KLUR3cmFwcGVyLmRlYnVnPSJUUlVFIiAtRHdyYXBwZXIudXNl
X3N5c3RlbV90aW1lPSJUUlVFIg0KLUR3cmFwcGVyLnZlcnNpb249IjMuMS4yIiAtRHdyYXBwZXIu
bmF0aXZlX2xpYnJhcnk9IndyYXBwZXIiDQotRHdyYXBwZXIuY3B1LnRpbWVvdXQ9IjEwIiAtRHdy
YXBwZXIuanZtaWQ9MQ0Kb3JnLnRhbnVraXNvZnR3YXJlLndyYXBwZXIuV3JhcHBlclN0YXJ0U3Rv
cEFwcA0KY29tLm1ja2Vzc29uYXBzLmZwMmsuRlAyS1NlcnZpY2VXcmFwcGVyJFN0YXJ0IDANCmNv
bS5tY2tlc3NvbmFwcy5mcDJrLkZQMktTZXJ2aWNlV3JhcHBlciRTdG9wIHRydWUgMA0KREVCVUcg
IHwgd3JhcHBlciAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgSlZNIHN0YXJ0ZWQgKFBJRD0yMjc2
KQ0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgV3JhcHBlclN0YXJ0
U3RvcEFwcDogVW5hYmxlIHRvDQpsb2NhdGUgdGhlIGNsYXNzIGNvbS5tY2tlc3NvbmFwcy5mcDJr
LkZQMktTZXJ2aWNlV3JhcHBlciRTdGFydDoNCmphdmEubGFuZy5DbGFzc05vdEZvdW5kRXhjZXB0
aW9uOg0KY29tLm1ja2Vzc29uYXBzLmZwMmsuRlAyS1NlcnZpY2VXcmFwcGVyJFN0YXJ0DQpJTkZP
ICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCANCklORk8gICB8IGp2bSAxICAg
IHwgMjAwNi8wMS8yNyAwNjoxMToyMyB8IFdyYXBwZXJTdGFydFN0b3BBcHAgVXNhZ2U6DQpJTkZP
ICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCAgIGphdmENCm9yZy50YW51a2lz
b2Z0d2FyZS53cmFwcGVyLldyYXBwZXJTdGFydFN0b3BBcHAge3N0YXJ0X2NsYXNzfQ0Ke3N0YXJ0
X2FyZ19jb3VudH0gW3N0YXJ0X2FyZ3VtZW50c10ge3N0b3BfY2xhc3N9IHtzdG9wX3dhaXR9DQp7
c3RvcF9hcmdfY291bnR9IFtzdG9wX2FyZ3VtZW50c10NCklORk8gICB8IGp2bSAxICAgIHwgMjAw
Ni8wMS8yNyAwNjoxMToyMyB8IA0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjEx
OjIzIHwgV2hlcmU6DQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCAg
IHN0YXJ0X2NsYXNzOiAgICAgVGhlIGZ1bGx5DQpxdWFsaWZpZWQgY2xhc3MgbmFtZSB0byBydW4g
dG8gc3RhcnQgdGhlIA0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwN
CmFwcGxpY2F0aW9uLg0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwg
ICBzdGFydF9hcmdfY291bnQ6IFRoZSBudW1iZXINCm9mIGFyZ3VtZW50cyB0byBiZSBwYXNzZWQg
dG8gdGhlIHN0YXJ0IGNsYXNzJ3MgDQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6
MTE6MjMgfCAgICAgICAgICAgICAgICAgICAgbWFpbg0KbWV0aG9kLg0KSU5GTyAgIHwganZtIDEg
ICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgICBzdG9wX2NsYXNzOiAgICAgIFRoZSBmdWxseQ0K
cXVhbGlmaWVkIGNsYXNzIG5hbWUgdG8gcnVuIHRvIHN0b3AgdGhlIA0KSU5GTyAgIHwganZtIDEg
ICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwNCmFwcGxpY2F0aW9uLg0KSU5GTyAgIHwganZtIDEg
ICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgICBzdG9wX3dhaXQ6ICAgICAgIFdoZW4NCnN0b3Bw
aW5nLCBzaG91bGQgdGhlIFdyYXBwZXIgd2FpdCBmb3IgYWxsIHRocmVhZHMgdG8gDQpJTkZPICAg
fCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCAgICAgICAgICAgICAgICAgICAgY29t
cGxldGUNCmJlZm9yZSBleGl0aW5nICh0cnVlL2ZhbHNlKS4NCklORk8gICB8IGp2bSAxICAgIHwg
MjAwNi8wMS8yNyAwNjoxMToyMyB8ICAgc3RvcF9hcmdfY291bnQ6ICBUaGUgbnVtYmVyDQpvZiBh
cmd1bWVudHMgdG8gYmUgcGFzc2VkIHRvIHRoZSBzdG9wIGNsYXNzJ3MgDQpJTkZPICAgfCBqdm0g
MSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCAgICAgICAgICAgICAgICAgICAgbWFpbg0KbWV0
aG9kLg0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgICBhcHBfcGFy
YW1ldGVyczogIFRoZQ0KcGFyYW1ldGVycyB0aGF0IHdvdWxkIG5vcm1hbGx5IGJlIHBhc3NlZCB0
byB0aGUNCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAwNjoxMToyMyB8DQphcHBsaWNh
dGlvbi4NCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAwNjoxMToyMyB8IFdyYXBwZXJN
YW5hZ2VyIGNsYXNzDQppbml0aWFsaXplZCBieSB0aHJlYWQ6IG1haW4gIFVzaW5nIGNsYXNzbG9h
ZGVyOg0Kc3VuLm1pc2MuTGF1bmNoZXIkRXh0Q2xhc3NMb2FkZXJAYTljODVjDQpJTkZPICAgfCBq
dm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBXcmFwcGVyIE1hbmFnZXI6IEpWTSAjMQ0K
SU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgV3JhcHBlciBNYW5hZ2Vy
OiBSZWdpc3RlcmluZw0Kc2h1dGRvd24gaG9vaw0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAx
LzI3IDA2OjExOjIzIHwgV3JhcHBlciBNYW5hZ2VyOiBVc2luZyB3cmFwcGVyDQpJTkZPICAgfCBq
dm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBMb2FkZWQgbmF0aXZlIGxpYnJhcnk6DQp3
cmFwcGVyLmRsbA0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgQ2Fs
bGluZyBuYXRpdmUgaW5pdGlhbGl6YXRpb24NCm1ldGhvZC4NCklORk8gICB8IGp2bSAxICAgIHwg
MjAwNi8wMS8yNyAwNjoxMToyMyB8IEluaXRpYWxpemluZyBXcmFwcGVyTWFuYWdlcg0KbmF0aXZl
IGxpYnJhcnkuDQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBKYXZh
IEV4ZWN1dGFibGU6DQpDOlxXSU5OVFxzeXN0ZW0zMlxqYXZhLmV4ZQ0KSU5GTyAgIHwganZtIDEg
ICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgV2luZG93cyB2ZXJzaW9uOiA1LjAuMjE5NQ0KSU5G
TyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgSmF2YSBWZXJzaW9uICAgOiAx
LjUuMF8wNi1iMDUNCkphdmEgSG90U3BvdChUTSkgQ2xpZW50IFZNDQpJTkZPICAgfCBqdm0gMSAg
ICB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBKYXZhIFZNIFZlbmRvciA6IFN1bg0KTWljcm9zeXN0
ZW1zIEluYy4NCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAwNjoxMToyMyB8IA0KSU5G
TyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgV3JhcHBlck1hbmFnZXIuc3Rv
cCgxKSBjYWxsZWQNCmJ5IHRocmVhZDogbWFpbg0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAx
LzI3IDA2OjExOjIzIHwgT3BlbiBzb2NrZXQgdG8gd3JhcHBlci4uLg0KSU5GTyAgIHwganZtIDEg
ICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgT3BlbmVkIFNvY2tldA0KSU5GTyAgIHwganZtIDEg
ICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgU2VuZCBhIHBhY2tldCBLRVkgOg0KZTE4dXFoQkZO
WFN6RFJLaA0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwNCmhhbmRs
ZVNvY2tldChTb2NrZXRbYWRkcj0vMTI3LjAuMC4xLHBvcnQ9MzIwMDAsbG9jYWxwb3J0PTEzMzJd
KQ0KREVCVUcgIHwgd3JhcHBlcnAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgYWNjZXB0ZWQgYSBz
b2NrZXQgZnJvbQ0KMTI3LjAuMC4xIG9uIHBvcnQgMTMzMg0KREVCVUcgIHwgd3JhcHBlcnAgfCAy
MDA2LzAxLzI3IDA2OjExOjIzIHwgcmVhZCBhIHBhY2tldCBLRVkgOg0KZTE4dXFoQkZOWFN6RFJL
aA0KREVCVUcgIHwgd3JhcHBlciAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgR290IGtleSBmcm9t
IEpWTToNCmUxOHVxaEJGTlhTekRSS2gNCkRFQlVHICB8IHdyYXBwZXJwIHwgMjAwNi8wMS8yNyAw
NjoxMToyMyB8IHNlbmQgYSBwYWNrZXQgTE9XX0xPR19MRVZFTCA6DQoxDQpERUJVRyAgfCB3cmFw
cGVycCB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBzZW5kIGEgcGFja2V0IFBJTkdfVElNRU9VVCA6
DQozMA0KREVCVUcgIHwgd3JhcHBlciAgfCAyMDA2LzAxLzI3IDA2OjExOjIzIHwgU3RhcnQgQXBw
bGljYXRpb24uDQpERUJVRyAgfCB3cmFwcGVycCB8IDIwMDYvMDEvMjcgMDY6MTE6MjMgfCBzZW5k
IGEgcGFja2V0IFNUQVJUIDogc3RhcnQNCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAw
NjoxMToyNCB8IFJlY2VpdmVkIGEgcGFja2V0DQpMT1dfTE9HX0xFVkVMIDogMQ0KSU5GTyAgIHwg
anZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjI0IHwgV3JhcHBlciBNYW5hZ2VyOiBMb3dMb2dM
ZXZlbA0KZnJvbSBXcmFwcGVyIGlzIDENCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAw
NjoxMToyNCB8IFJlY2VpdmVkIGEgcGFja2V0IFBJTkdfVElNRU9VVA0KOiAzMA0KSU5GTyAgIHwg
anZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjI0IHwgV3JhcHBlciBNYW5hZ2VyOiBQaW5nVGlt
ZW91dA0KZnJvbSBXcmFwcGVyIGlzIDMwMDAwDQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEv
MjcgMDY6MTE6MjQgfCBSZWNlaXZlZCBhIHBhY2tldCBTVEFSVCA6DQpzdGFydA0KSU5GTyAgIHwg
anZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjI0IHwgY2FsbGluZyBsaXN0ZW5lci5zdGFydCgp
DQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjQgfCByZXR1cm5lZCBmcm9t
IGxpc3RlbmVyLnN0YXJ0KCkNCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAwNjoxMToy
NCB8IFNlbmQgYSBwYWNrZXQgU1RBUlRFRCA6IA0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAx
LzI3IDA2OjExOjI0IHwgQWxsIG5vbi1kYWVtb24gdGhyZWFkcyBoYXZlDQpzdG9wcGVkLiAgRXhp
dGluZy4NCklORk8gICB8IGp2bSAxICAgIHwgMjAwNi8wMS8yNyAwNjoxMToyNCB8IFdyYXBwZXJN
YW5hZ2VyLnN0b3AoMCkgY2FsbGVkDQpieSB0aHJlYWQ6IFdyYXBwZXItQ29ubmVjdGlvbg0KSU5G
TyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjI0IHwgVGhyZWFkLCBXcmFwcGVyLUNv
bm5lY3Rpb24sDQpoYW5kbGluZyB0aGUgc2h1dGRvd24gcHJvY2Vzcy4NCklORk8gICB8IGp2bSAx
ICAgIHwgMjAwNi8wMS8yNyAwNjoxMToyNCB8IGNhbGxpbmcgbGlzdGVuZXIuc3RvcCgpDQpJTkZP
ICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjQgfCByZXR1cm5lZCBmcm9tIGxpc3Rl
bmVyLnN0b3AoKQ0KSU5GTyAgIHwganZtIDEgICAgfCAyMDA2LzAxLzI3IDA2OjExOjI0IHwgU2Vu
ZCBhIHBhY2tldCBTVE9QUEVEIDogMA0KREVCVUcgIHwgd3JhcHBlcnAgfCAyMDA2LzAxLzI3IDA2
OjExOjI0IHwgcmVhZCBhIHBhY2tldCBTVEFSVEVEIDogDQpERUJVRyAgfCB3cmFwcGVyICB8IDIw
MDYvMDEvMjcgMDY6MTE6MjQgfCBKVk0gc2lnbmFsbGVkIHRoYXQgaXQgd2FzDQpzdGFydGVkLg0K
REVCVUcgIHwgd3JhcHBlcnAgfCAyMDA2LzAxLzI3IDA2OjExOjI0IHwgcmVhZCBhIHBhY2tldCBT
VE9QUEVEIDogMA0KREVCVUcgIHwgd3JhcHBlciAgfCAyMDA2LzAxLzI3IDA2OjExOjI0IHwgSlZN
IHNpZ25hbGxlZCB0aGF0IGl0IHdhcw0Kc3RvcHBlZC4NCklORk8gICB8IGp2bSAxICAgIHwgMjAw
Ni8wMS8yNyAwNjoxMToyNCB8IENsb3Npbmcgc29ja2V0Lg0KREVCVUcgIHwgd3JhcHBlcnAgfCAy
MDA2LzAxLzI3IDA2OjExOjI0IHwgc29ja2V0IHJlYWQgbm8gY29kZSAoY2xvc2VkPykuDQpJTkZP
ICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjQgfCBjYWxsaW5nIFN5c3RlbS5leGl0
KDApDQpJTkZPICAgfCBqdm0gMSAgICB8IDIwMDYvMDEvMjcgMDY6MTE6MjQgfCBTZW5kIGEgcGFj
a2V0IFNUT1AgOiAxDQpERUJVRyAgfCB3cmFwcGVyICB8IDIwMDYvMDEvMjcgMDY6MTE6MjQgfCBK
Vk0gcHJvY2VzcyBleGl0ZWQgd2l0aCBhIGNvZGUNCm9mIDAsIGxlYXZpbmcgdGhlIHdyYXBwZXIg
ZXhpdCBjb2RlIHNldCB0byAwLg0KREVCVUcgIHwgd3JhcHBlciAgfCAyMDA2LzAxLzI3IDA2OjEx
OjI0IHwgSlZNIGV4aXRlZCBub3JtYWxseS4NClNUQVRVUyB8IHdyYXBwZXIgIHwgMjAwNi8wMS8y
NyAwNjoxMToyNSB8IDwtLSBXcmFwcGVyIFN0b3BwZWQNCi0tLS0gDQogIA0KQ29uZmlkZW50aWFs
aXR5IE5vdGljZTogVGhpcyBlLW1haWwgbWVzc2FnZSwgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50
cywgaXMgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGFuZCBt
YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIEFueSB1
bmF1dGhvcml6ZWQgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIGlzIHBy
b2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj
b250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMg
b2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuIA0KIA0K

Re: [Wrapper-user] Passing command line parms with WrapperStartStopApp

[Leif Mortenson <leif@ta...>]

Jim,
    Are you running on Windows or a UNIX platform?  In either case, you 
need to
modify the script used to launch the Wrapper so the additional 
parameters passed to
the script will be passed on to the Wrapper when it is launched.

    First modify your wrapper.conf as follows:
wrapper.app.parameter.1=com.farrow.imaging.ScannedImageCopier
wrapper.app.parameter.2=1
wrapper.app.parameter.3=start
wrapper.app.parameter.4=com.farrow.service.ShutdownService
wrapper.app.parameter.5=true
wrapper.app.parameter.6=2
wrapper.app.parameter.7=stop
wrapper.app.parameter.8=PARAM1_PLACEHOLDER

    Then modify your App.bat.in script as follows: (Windows)
"%_WRAPPER_EXE%" -c %_WRAPPER_CONF% wrapper.app.parameter.8=%1

    This will take the first parameter to the batch file and use it as 
the 8th parameter
when launching the JVM.   It is not possible to specify such a parameter 
when stopping
the service.  You have to know what it will be when the service is 
started in the first
place.   This will work when installing the service as well. "-c" would 
be "-i"
Note the 8th parameter in the conf file is not required, but it makes it 
more obvious
what is happening if a 9th parameter is also added.

Cheers,
Leif

Jim McLean wrote:
>
> Hi List,
>
> I'm trying to pass command line params to the program that is going to 
> perform the stop. How can this be done?
>
>
> Here's what my config file looks like:
>
> wrapper.java.command=%JAVA_HOME%/bin/java
>
> wrapper.java.classpath.1=../lib/wrapper.jar
> wrapper.java.classpath.2=../lib/ScannedImageCopier.jar
> wrapper.java.classpath.3=../lib/jt400.jar
> wrapper.java.classpath.4=../lib/log4j-1.2.9.jar
> wrapper.java.classpath.5=../lib/mail.jar
> wrapper.java.classpath.6=../lib/activation.jar
>
> wrapper.java.library.path.1=../lib
>
> wrapper.logfile=../logs/wrapper.log
> wrapper.logfile.maxfiles=5
> wrapper.logfile.maxsize=1m
>
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperStartStopApp
>
> wrapper.app.parameter.1=com.farrow.imaging.ScannedImageCopier
> wrapper.app.parameter.2=1
> wrapper.app.parameter.3=start
> wrapper.app.parameter.4=com.farrow.service.ShutdownService
> wrapper.app.parameter.5=true
> wrapper.app.parameter.6=1
> wrapper.app.parameter.7=stop
>
> Much Thanks,
> Jim
>

Re: [Wrapper-user] Wrapper classpath on Windows 2000

[Leif Mortenson <leif@ta...>]

John,
    Open your debug wrapper.log in an editor and copy the full command 
used to launch
the Wrapper into a new batch file.   Remove the -Dwrapper.key property, 
but leave the
rest of it unmodified.   You should now be able to run the exact same 
command that the
Wrapper is using to launch the JVM.   Something must be different in 
there somewhere
but this will make it easy to track the problem down while taking the 
Wrapper out of
the equation.

Questions.
1) Does the above batch file fail in the same way as the Wrapper?

2) What is being used for your java command?  Is it locating java on the 
PATH or have
you specified an absolute JVM to use?

3) What is the class that is failing to load?  What jar is it found in?  
and Does that jar
file appear in the command in the batch file?

Cheers
Leif

Volkar, John wrote:
> I've been successfully using the java service wrapper for a while now;
> but have just ran into a very odd situation.
>
> I have a set of files (jars, dlls, etc), directories and a .properties
> file that works just fine on a Win XP box, but when the entire setup is
> put on a Windows 2000 machine, the service fails to start indicating a
> class not found error.
>
> I think to myself; well the classpath must not be right, must have got
> something moved around wrong... After investigation no, everything looks
> fine...  
>
> So I try running 'java -cp yada;yada;yada' from the command line and
> specify the classpath as normal and the app runs just fine...
>
> So I do a 'wrapper -c My.props wrapper.debug=true' and look at the full
> command line the wrapper is using and it looks...
> ...Just fine.  So now I'm really confused...
>
> I've tried searching this mailinglist to no real avail; is there any
> known issue with Win2K and wrapper?  Where can I even being to go from
> here?  Thoughts or suggestions welcomed.
>
> Why would something run from the commandline, but fail under the wrapper
> (in console mode) with a class not found when they both have exactly the
> same classpath?
>
> Regards,
> John Volkar 

RE: [Wrapper-user] Wrapper classpath on Windows 2000

[Volkar, John <John.Volkar@McKesson.com>]

PiBtYXliZSB5b3UgcmFuIGludG8gYSBwcm9ibGVtIHdpdGggdGhlIG1heGltdW0gY29tbWFuZCBs
aW5lIGxlbmd0aD8NCklzIGl0IGRpZmZlcmVudCBiZXR3ZWVuIFdpblhQIGFuZCBXaW4yMDAwID8/
PyAgSSBjYW5ub3QgaW1hZ2luZSB0aGlzDQpiZWluZyB0aGUgcHJvYmxlbTsgdGhlIHJlc3VsdGlu
ZyBjb21tYW5kIGxpbmUgaXNuJ3QgYWxsICp0aGF0KiBsb25nLg0KDQpJIHJlbWVtYmVyIHNvbWV0
aGluZyBhYm91dCB0aGUgbWF4aW11bSBsZW5ndGggb2YgZW52aXJvbm1lbnQgdmFyaWFibGVzLA0K
YnV0IHRoZXJlIGFyZSBubyBlbnZpcm9uLXZhcmlhYmxlcyBpbnZvbHZlZCBpbiB0aGlzIGNhc2U7
IGFuZCB0aGF0IGxpbWl0DQp3YXMgMjA0OCBhbmQgSSdtIHdheSBzaG9ydGVyIHRoYW4gdGhhdC4N
Cg0KVGhhbmtzIGZvciB0aGUgdGhvdWdodCwgSSBkb24ndCB0aGluayB0aGlzIGlzIHBhcnQgb2Yg
bXkgcHJvYmxlbTsgYnV0DQptYXliZSBJJ20gbWlzdW5kZXJzdGFuZGluZyB3aGF0IHlvdSBtZWFu
dD8NCg0KUmVnYXJkcywNCkpvaG4gVm9sa2FyIA0KICANCkNvbmZpZGVudGlhbGl0eSBOb3RpY2U6
IFRoaXMgZS1tYWlsIG1lc3NhZ2UsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGlzIGZvciB0
aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBhbmQgbWF5IGNvbnRhaW4g
Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBBbnkgdW5hdXRob3JpemVk
IHJldmlldywgdXNlLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9oaWJpdGVkLiBJ
ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg
c2VuZGVyIGJ5IHJlcGx5IGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmln
aW5hbCBtZXNzYWdlLiANCiANCg==

Re: [Wrapper-user] Wrapper classpath on Windows 2000

[Martin Keller <martin.keller@un...>]

Hi Volkar,

maybe you ran into a problem with the maximum command line length?

Regards,
Martin

Volkar, John wrote:

>I've been successfully using the java service wrapper for a while now;
>but have just ran into a very odd situation.
>
>I have a set of files (jars, dlls, etc), directories and a .properties
>file that works just fine on a Win XP box, but when the entire setup is
>put on a Windows 2000 machine, the service fails to start indicating a
>class not found error.
>
>I think to myself; well the classpath must not be right, must have got
>something moved around wrong... After investigation no, everything looks
>fine...  
>
>So I try running 'java -cp yada;yada;yada' from the command line and
>specify the classpath as normal and the app runs just fine...
>
>So I do a 'wrapper -c My.props wrapper.debug=true' and look at the full
>command line the wrapper is using and it looks...
>...Just fine.  So now I'm really confused...
>
>I've tried searching this mailinglist to no real avail; is there any
>known issue with Win2K and wrapper?  Where can I even being to go from
>here?  Thoughts or suggestions welcomed.
>
>Why would something run from the commandline, but fail under the wrapper
>(in console mode) with a class not found when they both have exactly the
>same classpath?
>
>Regards,
>John Volkar 
>  
>Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
> 
>N¬HY޵隊X¬²š'²ŠÞu¼’¦[§‰ÜŒ¨º
>Þ¦Øk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£	塧m…éÞÀ@^Çš­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­þÇ¥rg–y$‰ÐÓ~7Ù¸mãÎjÐÛ^¸ÙjÚ¦—«ºÇ«™¨¥Šx%ŠËV­ªiz»¬z¹b²Û,¢êÜyú+éÞ¶m¦Ïÿ–+-²Ê.­ÇŸ¢¸ë–+-³ùb²Ø§~ð­ªiz»¬er==
>

[Wrapper-user] Wrapper classpath on Windows 2000

[Volkar, John <John.Volkar@McKesson.com>]

SSd2ZSBiZWVuIHN1Y2Nlc3NmdWxseSB1c2luZyB0aGUgamF2YSBzZXJ2aWNlIHdyYXBwZXIgZm9y
IGEgd2hpbGUgbm93Ow0KYnV0IGhhdmUganVzdCByYW4gaW50byBhIHZlcnkgb2RkIHNpdHVhdGlv
bi4NCg0KSSBoYXZlIGEgc2V0IG9mIGZpbGVzIChqYXJzLCBkbGxzLCBldGMpLCBkaXJlY3Rvcmll
cyBhbmQgYSAucHJvcGVydGllcw0KZmlsZSB0aGF0IHdvcmtzIGp1c3QgZmluZSBvbiBhIFdpbiBY
UCBib3gsIGJ1dCB3aGVuIHRoZSBlbnRpcmUgc2V0dXAgaXMNCnB1dCBvbiBhIFdpbmRvd3MgMjAw
MCBtYWNoaW5lLCB0aGUgc2VydmljZSBmYWlscyB0byBzdGFydCBpbmRpY2F0aW5nIGENCmNsYXNz
IG5vdCBmb3VuZCBlcnJvci4NCg0KSSB0aGluayB0byBteXNlbGY7IHdlbGwgdGhlIGNsYXNzcGF0
aCBtdXN0IG5vdCBiZSByaWdodCwgbXVzdCBoYXZlIGdvdA0Kc29tZXRoaW5nIG1vdmVkIGFyb3Vu
ZCB3cm9uZy4uLiBBZnRlciBpbnZlc3RpZ2F0aW9uIG5vLCBldmVyeXRoaW5nIGxvb2tzDQpmaW5l
Li4uICANCg0KU28gSSB0cnkgcnVubmluZyAnamF2YSAtY3AgeWFkYTt5YWRhO3lhZGEnIGZyb20g
dGhlIGNvbW1hbmQgbGluZSBhbmQNCnNwZWNpZnkgdGhlIGNsYXNzcGF0aCBhcyBub3JtYWwgYW5k
IHRoZSBhcHAgcnVucyBqdXN0IGZpbmUuLi4NCg0KU28gSSBkbyBhICd3cmFwcGVyIC1jIE15LnBy
b3BzIHdyYXBwZXIuZGVidWc9dHJ1ZScgYW5kIGxvb2sgYXQgdGhlIGZ1bGwNCmNvbW1hbmQgbGlu
ZSB0aGUgd3JhcHBlciBpcyB1c2luZyBhbmQgaXQgbG9va3MuLi4NCi4uLkp1c3QgZmluZS4gIFNv
IG5vdyBJJ20gcmVhbGx5IGNvbmZ1c2VkLi4uDQoNCkkndmUgdHJpZWQgc2VhcmNoaW5nIHRoaXMg
bWFpbGluZ2xpc3QgdG8gbm8gcmVhbCBhdmFpbDsgaXMgdGhlcmUgYW55DQprbm93biBpc3N1ZSB3
aXRoIFdpbjJLIGFuZCB3cmFwcGVyPyAgV2hlcmUgY2FuIEkgZXZlbiBiZWluZyB0byBnbyBmcm9t
DQpoZXJlPyAgVGhvdWdodHMgb3Igc3VnZ2VzdGlvbnMgd2VsY29tZWQuDQoNCldoeSB3b3VsZCBz
b21ldGhpbmcgcnVuIGZyb20gdGhlIGNvbW1hbmRsaW5lLCBidXQgZmFpbCB1bmRlciB0aGUgd3Jh
cHBlcg0KKGluIGNvbnNvbGUgbW9kZSkgd2l0aCBhIGNsYXNzIG5vdCBmb3VuZCB3aGVuIHRoZXkg
Ym90aCBoYXZlIGV4YWN0bHkgdGhlDQpzYW1lIGNsYXNzcGF0aD8NCg0KUmVnYXJkcywNCkpvaG4g
Vm9sa2FyIA0KICANCkNvbmZpZGVudGlhbGl0eSBOb3RpY2U6IFRoaXMgZS1tYWlsIG1lc3NhZ2Us
IGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGlzIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu
dGVuZGVkIHJlY2lwaWVudChzKSBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2
aWxlZ2VkIGluZm9ybWF0aW9uLiBBbnkgdW5hdXRob3JpemVkIHJldmlldywgdXNlLCBkaXNjbG9z
dXJlIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFp
bCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLiANCiANCg==

Re: [Wrapper-user] Console messages

[Leif Mortenson <leif@ta...>]

Anastasios,
    Try this:
wrapper.logfile.loglevel=STATUS

    You will still see the output in the console, but it will not be 
shown in the log file.
The problem with doing this is that you may lose other information that 
you really do
want to see.  For example crash dumps etc.

    A better solution may be to do something like this:
wrapper.logfile.maxsize=1m
wrapper.logfile.maxfiles=1

    By doing this, the wrapper.log file will always be renamed to 
wrapper.log.1
when it exceeds 1Mb in size.  The max files specifies the maximum number of
rolled log files that will be kept around.  By doing this, you will be 
able to see
all recent log output, but will also be able to guarantee that the 
wrapper's log
files will never use more than 2Mb of disk space.

Cheers,
Leif

Anastasios Angelidis wrote:
> Is there a way to stop the wrapper from outputting console messages to 
> the log? I'm using a 3rd party app which outputs alot to the console. 
> So everything gets logged to the wrapper log which I dont want it to! 
> Thanks

[Wrapper-user] Console messages

[Anastasios Angelidis <voodoo@vi...>]

Is there a way to stop the wrapper from outputting console messages to 
the log? I'm using a 3rd party app which outputs alot to the console. So 
everything gets logged to the wrapper log which I dont want it to! Thanks

Re: [Wrapper-user] filter doesn't work?

[Qian Wang <jane6210@ya...>]

Leif,
   thank you very much. that solves my problem. 

--- Leif Mortenson <leif@...> wrote:

> Qian,
>     How are you catching the error.  The Wrapper
> works by processing the JVM
> console output.  There is no way to trigger off of
> an exception unless 
> there is some
> output to the console.  Make sure the text
> "java.lang.OutOfMemoryError" is
> showing up in the console and wrapper.log
> 
> Cheers,
> Leif
> 
> Qian Wang wrote:
> > Hi,
> >   I tried to use the config:
> >
> wrapper.filter.trigger.1=java.lang.OutOfMemoryError
> > wrapper.filter.action.1=RESTART so that when some
> > error occurs, my application can restart by
> itself. 
> >
> >  however, it doesn't seem to work. in my code i
> wrote
> > something like throw OutOfMemoryError; but looks
> like
> > my application is still running.
> >
> > Is there something that i am missing here? any
> hint is
> > greatly appreicated.
> >
> > Thanks
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> > for problems?  Stop!  Download the new AJAX search
> engine that makes
> > searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > Wrapper-user mailing list
> > Wrapper-user@...
> >
>
https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
> >   
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> for problems?  Stop!  Download the new AJAX search
> engine that makes
> searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wrapper-user@...
>
https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com