wrapper-user — User issues for Wrapper. (Support questions, etc.)

Re: [Wrapper-user] Cannot bring up a browser

[Leif M. <le...@ta...>]

Senthil,
    Are you setting the wrapper.ntservice.interactive property?  This is 
needed or the service
and all of its child processes will not have access to the desktop.  
ie.  They can't show the
user anything.

Cheers,
Leif

Senthil S wrote:
> Hi,
> My application launches a  browser as soon as it gets started.The 
> following is the code I use
>
> RunTime.exec(rundll32 url.dll, FileHandlerProtocol 
> http://localhost:1090);
>
> This one brings up a browser when I start the application in the 
> console mode but doesn't invoke the browser when started as a service 
> nor does it complain of any errors. I have the following for the path
> wrapper.java.path.1=%SYSTEM%\rundll32.dll
> wrapper.java.path.2=%SYSTEM%\url.dll
> wrapper.java.library.path.3=%SYSTEM%\rundll32.dll
> wrapper.java.library.path.4=%SYSTEM%\url.dll
>
> The %PATH% has C:\winnt\SYSTEM32 .
>
> What do I miss? Please reply me ASAP
>
> Waiting for your reply,
> Senthil
>
>
>
> -------------------------------------------------------
> 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
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Cannot bring up a browser

[Senthil S <sen...@gm...>]

Hi,
My application launches a  browser as soon as it gets started.The 
following is the code I use

RunTime.exec(rundll32 url.dll, FileHandlerProtocol http://localhost:1090);

This one brings up a browser when I start the application in the console 
mode but doesn't invoke the browser when started as a service nor does 
it complain of any errors. I have the following for the path
wrapper.java.path.1=%SYSTEM%\rundll32.dll
wrapper.java.path.2=%SYSTEM%\url.dll
wrapper.java.library.path.3=%SYSTEM%\rundll32.dll
wrapper.java.library.path.4=%SYSTEM%\url.dll

The %PATH% has C:\winnt\SYSTEM32 .

What do I miss? Please reply me ASAP

Waiting for your reply,
Senthil

[Wrapper-user] Wrapper stdout redirection in realtime

[Daniel M. <dan...@be...>]

I have a C#/.NET 2.0 GUI application I use as a front end to a Java
application I have developed. Traditionally, this Java app was invoked
via a DOS batch script which constructed classpaths and executed the
Java command directly. Within the GUI application, I was able to invoke
the batch script and redirect stdout and stderr to capture the Java
app's output in realtime and display it to the user. In order to gain
more control over the indirectly-invoked Java app, I have encapsulated
it in the Service Wrapper, to good effect (For instance, I can now
capture the pid of the Java/wrapper instance and kill it from the C#
application). I realize this isn't necessarily the intent of the
wrapper, but launch4j can't do all the classpath stuff I need, and I
don't have access to an exe4j license. So bear with me...

My problem is this: since I modified the batch script to invoke the
wrapper rather than the Java command itself to launch the application,
my C# application no longer gets realtime output from stdout/stderr when
the wrapper is running. The C# code itself hasn't changed; in fact,
output from the batch script itself gets redirected properly and in
realtime as before. It's just the wrapper output which is funky: it
doesn't actually get passed back to stdout until it's completely run its
course.=20

Any ideas what could be causing this? Obviously it's redirecting
somewhat properly, because I do eventually get the stdout stream... but
not until the end of the wrapper execution. I searched and couldn't find
any configuration properties related to output redirection.

Heeeelllp! :)

Daniel Mace
Software Engineer, Payroll Integration
benefitfocus.com
843-849-7476 x393


*************************************************************************=
***************
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 bfp...@be..., and =
destroy all copies or derivations of the original message. Thank you.  =
(BFeComNote Rev. 08/01/2005)
*************************************************************************=
**************

Re: [Wrapper-user] Jetty on Linux

[Filip R. <fil...@gm...>]

Thank you Leif, I'll try it out.

Filip

On 2/7/06, Leif Mortenson <le...@ta...> wrote:
> Filip,
>     Applications like Jetty are what the WrapperSimplApp (Method 1)
> helper class
> were designed for.  They are normally shut down by sending a TERM signal =
or
> CTRL-C.  The Wrapper shuts them down by calling System.exit and using
> Jetty's shutdown hooks to shut down the server cleanly.
>
> Cheers,
> Leif
>
> Filip Rachunek wrote:
> > Hello,
> >
> > I use Jetty 5.1.10 on Gentoo Linux and I would like to use the Wrapper
> > to start|stop|restart the Jetty server, possibly with the Method 2 -
> > http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-nix.=
html
> >
> > The problem is that the example for Tomcat uses the same class -
> > org.apache.catalina.startup.Bootstrap - for both starting and stopping
> > Tomcat but the similar class in Jetty - org.mortbay.jetty.Server - is
> > used for starting only (instead of stopping, the jetty.sh script calls
> > kill to terminate the Jetty process). Or am I missing something? Is it
> > possible to integrate Wrapper with Jetty in the mentioned way?
> >
> > Thanks for any help.
> > Filip
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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=
=3D121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Linux daemon question

[Anat H. <an...@en...>]

Hi Leif,

Attached is the log file. I hope it'll help.

Thanks,
Anat

Re: [Wrapper-user] Fedora 4 Daemon

[Leif M. <le...@ta...>]

Malan,
    Sorry for the delay.  I'm trying to get things tied up to release 
it.  3.2.0 should do a
much better job of dealing with 32 and 64 bit JVMs.
    If you want to try checking out from CVS and building, that should 
work.  You
should just have to run build64.sh or build32.sh in the source root dir 
and it will build.

Cheers,
Leif

Malan Joubert wrote:
> Hi
>
> I'm running a 64bit VM. When do you think the 64bit version will be
> released? It took me a while to realize that it's the 64bit VM that
> was giving the problem!
>
> Regards,
> Malan Joubert
>   

Re: [Wrapper-user] Fedora 4 Daemon

[Leif M. <le...@ta...>]

Tony,
    Let me make sure I understand.
You are able to run fine when running the shell script with the 
"console" command.
But you say it is not working when run as a daemon.   Is this the case 
when you run
from your user account using the "start" command, or when rebooting and 
starting
using a link in the /etc/init.d directory?
    What user is it running as when run as a daemon?
    Are you sure that you are using the same JVM?   You can verify this 
by adding
the wrapper.debug=true property and then running both as a console app and
daemon.  If java is being found on the path then they might not be the 
same if the
user environment is different.

Cheers,
Leif

Tony Seebregts wrote:
> Hi Leif,
>
> Thanks for the quick reply - I'm running a standard 32 bit JVM, have set
> the permissions to "rwxrwxrwx" for the library (just in case), and (just
> checked) its definitely the Linux version.
>
> Its something to do with the machine startup environment (running the
> script from the command works perfectly) but I just can't figure out what.
>
> regards
>
> Tony
>
>
>   
>> Tony,
>>    Are you running a 64-bit JVM?  The current linux version only
>> supports 32-bit JVMs.
>> That is a common cause of this problem.  I'll be releasing a 64-bit
>> linux version with the
>> 3.2.0 release.
>>    Other than that, this can be caused by a permission problem on the
>> file, or unlikely,
>> but attempting to use a solaris version of the libwrapper.so for example.
>>
>>    Cheers,
>>    Leif
>>     

Re: [Wrapper-user] Jetty on Linux

[Leif M. <le...@ta...>]

Filip,
    Applications like Jetty are what the WrapperSimplApp (Method 1) 
helper class
were designed for.  They are normally shut down by sending a TERM signal or
CTRL-C.  The Wrapper shuts them down by calling System.exit and using
Jetty's shutdown hooks to shut down the server cleanly.

Cheers,
Leif

Filip Rachunek wrote:
> Hello,
>
> I use Jetty 5.1.10 on Gentoo Linux and I would like to use the Wrapper
> to start|stop|restart the Jetty server, possibly with the Method 2 -
> http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-nix.html
>
> The problem is that the example for Tomcat uses the same class -
> org.apache.catalina.startup.Bootstrap - for both starting and stopping
> Tomcat but the similar class in Jetty - org.mortbay.jetty.Server - is
> used for starting only (instead of stopping, the jetty.sh script calls
> kill to terminate the Jetty process). Or am I missing something? Is it
> possible to integrate Wrapper with Jetty in the mentioned way?
>
> Thanks for any help.
> Filip
>   

[Wrapper-user] Linux daemon question

[Anat H. <an...@en...>]

--- I hope I'm not double-posting - I wasn't registered before...

Hi,

I'm trying to install my app as a Linux daemon. I used the 2nd integration method, and I'm
running the wrapper through <app> start. My app runs fine, and continues to run after
closing the console. However, it shuts down when I logout. Maybe I misunderstood, and it's
not supposed to keep running?
I've looked at the logs, and when I logout it seems the wrapper doesn't intercept the
signal, and so my app shuts down. When stopping my app using <app> stop, I get this line
in the log:
TERM trapped. Shutting down.
This msg is missing when I logout, but my app shuts down in both cases.

Thanks,
Anat

Re: [Wrapper-user] Linux daemon question

[Leif M. <le...@ta...>]

Anat,
    That shouldn't be happening, but I can't tell the cause from what 
you posted.
Could you add the wrapper.debug=true property, delete your wrapper.log file
and then reproduce this.  Post back with the resulting log file.

Cheers,
Leif

Anat Halpern wrote:
> Hi,
>
> I'm trying to install my app as a Linux daemon. I used the 2nd integration method, and I'm
> running the wrapper through <app> start. My app runs fine, and continues to run after
> closing the console. However, it shuts down when I logout. Maybe I misunderstood, and it's
> not supposed to keep running?
> I've looked at the logs, and when I logout it seems the wrapper doesn't intercept the
> signal, and so my app shuts down. When stopping my app using <app> stop, I get this line
> in the log:
> TERM trapped. Shutting down.
> This msg is missing when I logout, but my app shuts down in both cases.
>
> Thanks,
> Anat
>   

[Wrapper-user] Linux daemon question

[Anat H. <an...@en...>]

Hi,

I'm trying to install my app as a Linux daemon. I used the 2nd integration method, and I'm
running the wrapper through <app> start. My app runs fine, and continues to run after
closing the console. However, it shuts down when I logout. Maybe I misunderstood, and it's
not supposed to keep running?
I've looked at the logs, and when I logout it seems the wrapper doesn't intercept the
signal, and so my app shuts down. When stopping my app using <app> stop, I get this line
in the log:
TERM trapped. Shutting down.
This msg is missing when I logout, but my app shuts down in both cases.

Thanks,
Anat

--
Open WebMail Project (http://openwebmail.org)

[Wrapper-user] Jetty on Linux

[Filip R. <fil...@gm...>]

Hello,

I use Jetty 5.1.10 on Gentoo Linux and I would like to use the Wrapper
to start|stop|restart the Jetty server, possibly with the Method 2 -
http://wrapper.tanukisoftware.org/doc/english/integrate-start-stop-nix.html

The problem is that the example for Tomcat uses the same class -
org.apache.catalina.startup.Bootstrap - for both starting and stopping
Tomcat but the similar class in Jetty - org.mortbay.jetty.Server - is
used for starting only (instead of stopping, the jetty.sh script calls
kill to terminate the Jetty process). Or am I missing something? Is it
possible to integrate Wrapper with Jetty in the mentioned way?

Thanks for any help.
Filip

Re: [Wrapper-user] Fedora 4 Daemon

[Malan J. <ma...@gm...>]

Hi

I'm running a 64bit VM. When do you think the 64bit version will be
released? It took me a while to realize that it's the 64bit VM that
was giving the problem!

Regards,
Malan Joubert

On 2/6/06, Leif Mortenson <le...@ta...> wrote:
> Tony,
>     Are you running a 64-bit JVM?  The current linux version only
> supports 32-bit JVMs.
> That is a common cause of this problem.  I'll be releasing a 64-bit
> linux version with the
> 3.2.0 release.
>     Other than that, this can be caused by a permission problem on the
> file, or unlikely,
> but attempting to use a solaris version of the libwrapper.so for example.
>
>     Cheers,
>     Leif
>
> Tony Seebregts wrote:
> > Hi,
> >
> > I've been trying to get the wrapper to run as a daemon under Fedora 4
> > and am getting the following error in the log file:
> >
> > WARNING - Unable to load the Wrapper's native library 'libwrapper.so'.
> > INFO   | jvm 1    | 2006/02/06 13:45:42 |           The file is located
> > on the path at the following location but
> > INFO   | jvm 1    | 2006/02/06 13:45:42 |           could not be loaded=
:
> > INFO   | jvm 1    | 2006/02/06 13:45:42 |
> > /usr/local/cibecs/server/./lib/libwrapper.so
> > INFO   | jvm 1    | 2006/02/06 13:45:42 |           Please verify that
> > the file is readable by the current user
> > INFO   | jvm 1    | 2006/02/06 13:45:42 |           and that the file
> > has not been corrupted in any way.
> > INFO   | jvm 1    | 2006/02/06 13:45:42 |           System signals will
> > not be handled correctly.
> >
> > Starting the application from the command line in a user session using
> > the script works fine and other shared libraries seem to be loaded ok
> > (running ldconfig -n on the shared library directory creates a link to
> > the other shared libraries but not to libwrapper.so if that is of any h=
elp).
> >
> > I'd really appreciate any suggestions ... I've tried everything I can
> > think of.
> >
> > regards
> >
> > Tony Seebregts
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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=
=3D121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Fedora 4 Daemon

[Tony S. <to...@ci...>]

Hi Leif,

Thanks for the quick reply - I'm running a standard 32 bit JVM, have set
the permissions to "rwxrwxrwx" for the library (just in case), and (just
checked) its definitely the Linux version.

Its something to do with the machine startup environment (running the
script from the command works perfectly) but I just can't figure out what.

regards

Tony


> Tony,
>    Are you running a 64-bit JVM?  The current linux version only
> supports 32-bit JVMs.
> That is a common cause of this problem.  I'll be releasing a 64-bit
> linux version with the
> 3.2.0 release.
>    Other than that, this can be caused by a permission problem on the
> file, or unlikely,
> but attempting to use a solaris version of the libwrapper.so for example.
>
>    Cheers,
>    Leif
>

Re: [Wrapper-user] Fedora 4 Daemon

[Leif M. <le...@ta...>]

Tony,
    Are you running a 64-bit JVM?  The current linux version only 
supports 32-bit JVMs.
That is a common cause of this problem.  I'll be releasing a 64-bit 
linux version with the
3.2.0 release.
    Other than that, this can be caused by a permission problem on the 
file, or unlikely,
but attempting to use a solaris version of the libwrapper.so for example.

    Cheers,
    Leif

Tony Seebregts wrote:
> Hi,
>
> I've been trying to get the wrapper to run as a daemon under Fedora 4
> and am getting the following error in the log file:
>
> WARNING - Unable to load the Wrapper's native library 'libwrapper.so'.
> INFO   | jvm 1    | 2006/02/06 13:45:42 |           The file is located
> on the path at the following location but
> INFO   | jvm 1    | 2006/02/06 13:45:42 |           could not be loaded:
> INFO   | jvm 1    | 2006/02/06 13:45:42 |            
> /usr/local/cibecs/server/./lib/libwrapper.so
> INFO   | jvm 1    | 2006/02/06 13:45:42 |           Please verify that
> the file is readable by the current user
> INFO   | jvm 1    | 2006/02/06 13:45:42 |           and that the file
> has not been corrupted in any way.
> INFO   | jvm 1    | 2006/02/06 13:45:42 |           System signals will
> not be handled correctly.
>
> Starting the application from the command line in a user session using
> the script works fine and other shared libraries seem to be loaded ok
> (running ldconfig -n on the shared library directory creates a link to
> the other shared libraries but not to libwrapper.so if that is of any help).
>
> I'd really appreciate any suggestions ... I've tried everything I can
> think of.
>
> regards
>
> Tony Seebregts
>   

[Wrapper-user] Fedora 4 Daemon

[Tony S. <to...@ci...>]

Hi,

I've been trying to get the wrapper to run as a daemon under Fedora 4
and am getting the following error in the log file:

WARNING - Unable to load the Wrapper's native library 'libwrapper.so'.
INFO   | jvm 1    | 2006/02/06 13:45:42 |           The file is located
on the path at the following location but
INFO   | jvm 1    | 2006/02/06 13:45:42 |           could not be loaded:
INFO   | jvm 1    | 2006/02/06 13:45:42 |            
/usr/local/cibecs/server/./lib/libwrapper.so
INFO   | jvm 1    | 2006/02/06 13:45:42 |           Please verify that
the file is readable by the current user
INFO   | jvm 1    | 2006/02/06 13:45:42 |           and that the file
has not been corrupted in any way.
INFO   | jvm 1    | 2006/02/06 13:45:42 |           System signals will
not be handled correctly.

Starting the application from the command line in a user session using
the script works fine and other shared libraries seem to be loaded ok
(running ldconfig -n on the shared library directory creates a link to
the other shared libraries but not to libwrapper.so if that is of any help).

I'd really appreciate any suggestions ... I've tried everything I can
think of.

regards

Tony Seebregts

Re: [Wrapper-user] Performing actions on (re)start, shutdown of JVM

[Leif M. <le...@ta...>]

Martin,
    That is on my todo list, but it is not going to make it into the 
3.2.0 release.  That has
already been delayed long enough.

    If the JVM crashes for any reason, it will by default be restarted.  
For that reason,
you should always get a final clean shutdown when you ask the wrapper to 
stop.
It is not perfect, but doing what you are asking for in a shutdown 
thread should be
fairly reliable.  (Not 100% though).  Most shutdown methods will result 
in these
shutdown hooks being called.  The exceptions are calling
WrapperManager.stopImmediate(), Runtime.halt(), or by kill -9ing the JVM 
process.
All but the stopImmediate case will result in the JVM beign restarted 
however.

    I am planning to make it possible to run arbitrary processes at 
various points in the
Wrapper life cycle.  Its not possible in 3.1.2 or 3.2.0 however.

Cheers,
Leif

Martin Gazak wrote:
> Hallo,
> when using Wrapper 3.1.2 with my Java application, my Java application 
> requires to perform some specific actions during start/RESTART of JVM 
> and shutdown of JVM.
> These actions include, but are not limited to:
> - deleting device lock files on certain platforms (e.g. serial line 
> locks on Linux)
> - shutdown of heartbeat service
>
> The shutdown actions must be performed no matter what type of shutdown 
> occured ( WrapperManager.restart(), stop, stopImmediate() calls;
> System.exit() call; crash of JVM (both in Java and Native code), 
> killing JVM process from command line).
>
> Is it possible to configure wrapper to perform these actions (e.g. in 
> the form of calling some scripts) ?
>
> The naive try = launching my script "runjava" (which performs the 
> start actions, runs JVM and then performs shutdown actions) from 
> wrapper.java.command does not work properly - wrapper was watching the 
> /bin/sh instead of java process, sometimes java processes kept 
> accumulating when I was playing (since wrapper took care for shell 
> processes, not for the increasing number of JVM).
>
> Thanks in advance.
>
>
> Martin
>

[Wrapper-user] Performing actions on (re)start, shutdown of JVM

[Martin G. <ma...@mi...>]

Hallo,
when using Wrapper 3.1.2 with my Java application, my Java application 
requires to perform some specific actions during start/RESTART of JVM 
and shutdown of JVM.
These actions include, but are not limited to:
- deleting device lock files on certain platforms (e.g. serial line 
locks on Linux)
- shutdown of heartbeat service

The shutdown actions must be performed no matter what type of shutdown 
occured ( WrapperManager.restart(), stop, stopImmediate() calls;
System.exit() call; crash of JVM (both in Java and Native code), killing 
JVM process from command line).

Is it possible to configure wrapper to perform these actions (e.g. in 
the form of calling some scripts) ?

The naive try = launching my script "runjava" (which performs the start 
actions, runs JVM and then performs shutdown actions) from 
wrapper.java.command does not work properly - wrapper was watching the 
/bin/sh instead of java process, sometimes java processes kept 
accumulating when I was playing (since wrapper took care for shell 
processes, not for the increasing number of JVM).

Thanks in advance.


Martin

-- 
Martin Gazak
e-mail: ma...@mi...

Re: [Wrapper-user] Console messages

[Anastasios A. <vo...@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
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

RE: [Wrapper-user] Log4j problem.

[Doug T. <dou...@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: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: Monday, January 30, 2006 9:35 PM
To: wra...@li...
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
Wra...@li...
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 bfp...@be..., and =
destroy all copies or derivations of the original message. Thank you.  =
(BFeComNote Rev. 08/01/2005)
*************************************************************************=
**************

Re: [Wrapper-user] Log4j problem.

[Leif M. <le...@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 M. <le...@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 M. <dmc...@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
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>
>

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

[Richard E. <rem...@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
> Wra...@li...
> 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 T. <dou...@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@e80a59

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@1e51060
, 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 bfp...@be..., and =
destroy all copies or derivations of the original message. Thank you.  =
(BFeComNote Rev. 08/01/2005)
*************************************************************************=
**************