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

Re: [Wrapper-user] Spring Application in Executable JAR - Classpath Woes

[Christian M. <chr...@ta...>]

Ralf,

could you please try setting
../lib/ampa-feed-morningstar-11.07.000-SNAPSHOT-jar-with-dependencies.jar
to the classpath:

wrapper.java.classpath.2=../lib/ampa-feed-morningstar-11.07.000-SNAPSHOT-jar-with-dependencies.jar

Your application is probably loading the resource from the System
classloader and not the classloader of your class. Please note that
the WrapperJarApp is setting the classloader for your class but can't
change the System classloader after the JVM has been launched.
Therefore setting the classpath in your conf file accordingly should
fix the issue.


Best Regards,
Christian

On Fri, Jul 15, 2011 at 1:56 AM,
<ral...@de...> wrote:
> Hello all,
>
>
>
> I am using version 3.5.9 for Windows (32 bit) on Windows Server 2008
> (64bit).
>
>
>
> I am trying to run a Camel/Spring application as a Windows service with the
> help of the Java Service Wrapper. I have packaged the application as an
> executable jar that lists all runtime dependencies in the classpath entry in
> its MANIFEST file.
>
> I have created what I think is the standard directory layout:
>
>
>
> <base>/conf (wrapper.conf)
>
> <base>/lib (wrapper.dll, wrapper.jar, the executable jar, the runtime deps
> of the exec. Jar)
>
> <base>/bin (appStart.bat)
>
>
>
> If I navigate to <base>/lib and issue ‘java –jar myApp.jar’ then the
> application starts up fine.
>
>
>
> If I navigate to <base>/bin and execute the appStart.bat then the Spring
> context cannot be initialized:
>
>
>
> WrapperJarApp Error:
> org.springframework.beans.factory.BeanDefinitionStoreException: Could not
> resolve bean definition resource pattern [META-INF/spring/*.xml]; nested
> exception is java.io.FileNotFoundException: class path resource
> [META-INF/spring/] cannot be resolved to URL because it does not exist.
>
>
>
> Something is not quite right with the classpath. Can anyone help me out on
> how to fix this? The META-INF/spring directory in question is present inside
> the executable jar.
>
>
>
> Also, every JAR file seems to be twice on the classpath. SLF4J complains
> about multiple bindings on the classpath:
>
>
>
> <base>/bin/../lib/the.jar and
>
> <base>/lib/the.jar
>
>
>
> My wrapper.conf and the wrapper.log are attached.
>
>
>
>
>
> Thanks!
>
> Ralf
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] AUTO: Neeraja Kollu is out of office (returning 07/16/2011)

[Neeraja K. <nee...@in...>]

I am out of the office until 07/16/2011.

I work Saturday through Wednesday.  Please expect delayed response to your
mail.

I can be reached on +91-9866662965 for any urgent issue.


Note: This is an automated response to your message  "[Wrapper-user] Spring
Application in Executable JAR - Classpath Woes" sent on 14/7/11 22:26:28.

This is the only notification you will receive while this person is away.

[Wrapper-user] Isaiah K Peram is out of the office.

[Isaiah K P. <isa...@in...>]

I will be out of the office starting  07/12/2011 and will not return until
07/18/2011.

I will respond to your message when I return. Please feel free to call me
on my Mobile @ 9676867575 .

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

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

Dave,
Great.  Please let me know how 3.5.9 works for you.

Cheers,
Leif

On Mon, Jun 27, 2011 at 9:24 AM, David Hoffer <dho...@gm...> wrote:
> I don't think that's it as I always started/installed/stopped from the
> bin folder...but I did rename that folder using a remote FTP tool and
> then recreated the old folder using the same FTP tool...apparently
> Linux doesn't like that...
>
> I'm good with upgrading to 3.5.9...no point in not doing so.
>
> -Dave
>
> On Sun, Jun 26, 2011 at 5:01 PM, Leif Mortenson
> <lei...@ta...> wrote:
>> Dave,
>> The following is from the 3.5.7 release notes.   Is this maybe what
>> you are seeing?
>> ---
>> Fix a problem in the shell script that was preventing the script from
>> finding the running Wrapper process when it was started when the
>> working directory was in the same directory as the Wrapper binary, but
>> queried later from another location. It would also fail if it was
>> started from another location, but then queried from the location of
>> the Wrapper. This was introduced in 3.5.6 when the script stopped
>> changing the working directory in the script.
>> ---
>>
>> It would happen if you started the Wrapper from within the
>> $APP_HOME/bin directory as "./myapp start", but then stopped it from
>> the $APP_HOME directory as "bin/myapp stop".
>>
>> The following was also fixed in 3.5.7:
>> ---
>> Fix a problem in the shell script where it would fail to recognize a
>> running Wrapper if the Wrapper command line or path contained a square
>> bracket.
>> ---
>>
>> The full list of changes can always be found here:
>> http://wrapper.tanukisoftware.com/doc/english/release-notes.html
>>
>> There have been other issues fixed and improvements made as well, if
>> you upgrade then I recommend upgrading to 3.5.9.
>>
>> Cheers,
>> Leif
>>
>> On Mon, Jun 27, 2011 at 4:12 AM, David Hoffer <dho...@gm...> wrote:
>>> I'm using version 3.5.6, perhaps that's the problem I need to upgrade?
>>>
>>> -Dave
>>>
>>> On Sun, Jun 26, 2011 at 7:49 AM, Leif Mortenson
>>> <lei...@ta...> wrote:
>>>> Dave,
>>>> I just went back and retested this with 3.5.9 and it appears to be
>>>> working correctly.
>>>>
>>>> What version of the Wrapper  are you using?  Please open the shell
>>>> script in an editor and make sure that the version of the script is
>>>> the same as that of the Wrapper.
>>>>
>>>> The ignore_signals mode of the script works by using an anchor file
>>>> created in the same directory as the wrapper binary.  It will be named
>>>> wrapper.anchor by default.   The Wrapper will shut itself down when
>>>> this file is deleted.   Please confirm that this file exists while the
>>>> Wrapper is running then try to delete it manually.
>>>> http://wrapper.tanukisoftware.com/doc/english/prop-anchorfile.html
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> On Sun, Jun 26, 2011 at 9:49 PM, David Hoffer <dho...@gm...> wrote:
>>>>> Lief,
>>>>>
>>>>> Yes, the first thing I did is stop the service, then I modified the
>>>>> config to ignore signals then I started the service, when I tried to
>>>>> stop it...the script tried over and over to stop it but could not
>>>>> not...so I Ctlr-C to stop the script and I killed the service with
>>>>> kill -9 PID (because without the -9 kill didn't stop it either).
>>>>>
>>>>> Once I put the script back the way it was I can start/stop using the script.
>>>>>
>>>>> Thanks,
>>>>> -Dave
>>>>>
>>>>> On Sun, Jun 26, 2011 at 6:43 AM, Leif Mortenson
>>>>> <lei...@ta...> wrote:
>>>>>> Dave,
>>>>>> Yes that would do it.  Linux is designed for use my multiple users.
>>>>>> If one user renames a directory while another user is doing something
>>>>>> in it, then UNIX tries to avoid causing problems.  You need to cd up
>>>>>> to the parent directory and then back down to see the change.
>>>>>>
>>>>>> Glad you figured it out.
>>>>>>
>>>>>> For the TERM issue.   Did you stop the Wrapper before modifying the
>>>>>> script?   You need to start the Wrapper after the ignore signals flag
>>>>>> is set so it will be all set up to be able to stop the Wrapper
>>>>>> correctly.   Please let me know if you are still having problems when
>>>>>> you do this and I would be happy to help out further.
>>>>>>
>>>>>> Cheers,
>>>>>> Leif
>>>>>>
>>>>>> On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>> I think I figured this out.  Because I had a putty window open to the
>>>>>>> original folder, when it was renamed to _folder the putty window was
>>>>>>> referring to the old renamed folder when running the sh script
>>>>>>> although other commands like ls, cd worked with the new folder.  Once
>>>>>>> I changed putty to the old renamed folder I could stop that service
>>>>>>> and then start the new one once back to the new folder.
>>>>>>>
>>>>>>> Now back to the original issue regarding how to handle rouge TERM
>>>>>>> commands, when I make the config change to ignore signals I now no
>>>>>>> longer can use the wrapper's stop command I have to use kill -9 PID.
>>>>>>> I really would like to use the wrapper to start/stop and not use kill.
>>>>>>>
>>>>>>> -Dave
>>>>>>>
>>>>>>> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>>> Lief,
>>>>>>>>
>>>>>>>> The first thing I did is cd to the directory of the prior folder and
>>>>>>>> stop the service (it was previously installed and started).  Then
>>>>>>>> after it was stopped I renamed the entire folder with the _ prefix.  I
>>>>>>>> then  replaced the entire folder with the same name as before.  I then
>>>>>>>> started the service in the new folder (same name as before).
>>>>>>>>
>>>>>>>> The log file is: wrapper.logfile=./wrapper.log
>>>>>>>>
>>>>>>>> Yes I do have two conf files one in the program folder and one in
>>>>>>>> _program folder but since I'm in program shouldn't it ignore the
>>>>>>>> _program folder?  It's acting like the program is running from
>>>>>>>> _program but I started it from program.
>>>>>>>>
>>>>>>>> The mysterious ways of Linux.
>>>>>>>>
>>>>>>>> -Dave
>>>>>>>>
>>>>>>>> -Dave
>>>>>>>>
>>>>>>>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>> Dave,
>>>>>>>>> On linux if you rename a file or folder which contains an open file
>>>>>>>>> then the existing file handle will stay attached to the file.  But if
>>>>>>>>> you restart the process (Wrapper) then it should load from the new
>>>>>>>>> location.
>>>>>>>>>
>>>>>>>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>>>>>>>> Please check your wrapper.conf file to see where it is pointing.
>>>>>>>>>
>>>>>>>>> How are you starting the Wrapper?  Is it possible that you have two
>>>>>>>>> wrapper.conf files?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Leif
>>>>>>>>>
>>>>>>>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>> Leif,
>>>>>>>>>>
>>>>>>>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>>>>>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>>>>>>>> new program to the prior folder name, but now I see the log output is
>>>>>>>>>> going to the old renamed folder.  This would work just fine on
>>>>>>>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>>>>>>>> to the renamed old folder.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> -Dave
>>>>>>>>>>
>>>>>>>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>>>> David,
>>>>>>>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>>>>>>>> simply creating symbolic links to the script in most cases.
>>>>>>>>>>>
>>>>>>>>>>> Please let me know how it works for you.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Leif
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>>>> Leif,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>>>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>>>>>>>> Or just stop and restart?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> -Dave
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> David,
>>>>>>>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>>>>>>>> Please see the above page for more details.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let me know how this works for you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Leif
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > public void controlEvent(int event) {
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >         try {
>>>>>>>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>>>>>>>> >             } else {
>>>>>>>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>>>>>>>> > handle the event ourselves.
>>>>>>>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>>>>>>>> >                     log.warn("We are handling the received event
>>>>>>>>>>>>> > ourselves and we are stopping the service");
>>>>>>>>>>>>> >                     WrapperManager.stop(0);
>>>>>>>>>>>>> >                 }
>>>>>>>>>>>>> >             }
>>>>>>>>>>>>> >         }
>>>>>>>>>>>>> >     }
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>>>>>>>> > they are doing)
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > public void controlEvent( int event )
>>>>>>>>>>>>> >  {
>>>>>>>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>>>>>>>> >        {
>>>>>>>>>>>>> >            // Ignore
>>>>>>>>>>>>> >        }  else   {
>>>>>>>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>>>>>>>> >        }
>>>>>>>>>>>>> >  }
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Thanks,
>>>>>>>>>>>>> > -Dave

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

[David H. <dho...@gm...>]

I don't think that's it as I always started/installed/stopped from the
bin folder...but I did rename that folder using a remote FTP tool and
then recreated the old folder using the same FTP tool...apparently
Linux doesn't like that...

I'm good with upgrading to 3.5.9...no point in not doing so.

-Dave

On Sun, Jun 26, 2011 at 5:01 PM, Leif Mortenson
<lei...@ta...> wrote:
> Dave,
> The following is from the 3.5.7 release notes.   Is this maybe what
> you are seeing?
> ---
> Fix a problem in the shell script that was preventing the script from
> finding the running Wrapper process when it was started when the
> working directory was in the same directory as the Wrapper binary, but
> queried later from another location. It would also fail if it was
> started from another location, but then queried from the location of
> the Wrapper. This was introduced in 3.5.6 when the script stopped
> changing the working directory in the script.
> ---
>
> It would happen if you started the Wrapper from within the
> $APP_HOME/bin directory as "./myapp start", but then stopped it from
> the $APP_HOME directory as "bin/myapp stop".
>
> The following was also fixed in 3.5.7:
> ---
> Fix a problem in the shell script where it would fail to recognize a
> running Wrapper if the Wrapper command line or path contained a square
> bracket.
> ---
>
> The full list of changes can always be found here:
> http://wrapper.tanukisoftware.com/doc/english/release-notes.html
>
> There have been other issues fixed and improvements made as well, if
> you upgrade then I recommend upgrading to 3.5.9.
>
> Cheers,
> Leif
>
> On Mon, Jun 27, 2011 at 4:12 AM, David Hoffer <dho...@gm...> wrote:
>> I'm using version 3.5.6, perhaps that's the problem I need to upgrade?
>>
>> -Dave
>>
>> On Sun, Jun 26, 2011 at 7:49 AM, Leif Mortenson
>> <lei...@ta...> wrote:
>>> Dave,
>>> I just went back and retested this with 3.5.9 and it appears to be
>>> working correctly.
>>>
>>> What version of the Wrapper  are you using?  Please open the shell
>>> script in an editor and make sure that the version of the script is
>>> the same as that of the Wrapper.
>>>
>>> The ignore_signals mode of the script works by using an anchor file
>>> created in the same directory as the wrapper binary.  It will be named
>>> wrapper.anchor by default.   The Wrapper will shut itself down when
>>> this file is deleted.   Please confirm that this file exists while the
>>> Wrapper is running then try to delete it manually.
>>> http://wrapper.tanukisoftware.com/doc/english/prop-anchorfile.html
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Sun, Jun 26, 2011 at 9:49 PM, David Hoffer <dho...@gm...> wrote:
>>>> Lief,
>>>>
>>>> Yes, the first thing I did is stop the service, then I modified the
>>>> config to ignore signals then I started the service, when I tried to
>>>> stop it...the script tried over and over to stop it but could not
>>>> not...so I Ctlr-C to stop the script and I killed the service with
>>>> kill -9 PID (because without the -9 kill didn't stop it either).
>>>>
>>>> Once I put the script back the way it was I can start/stop using the script.
>>>>
>>>> Thanks,
>>>> -Dave
>>>>
>>>> On Sun, Jun 26, 2011 at 6:43 AM, Leif Mortenson
>>>> <lei...@ta...> wrote:
>>>>> Dave,
>>>>> Yes that would do it.  Linux is designed for use my multiple users.
>>>>> If one user renames a directory while another user is doing something
>>>>> in it, then UNIX tries to avoid causing problems.  You need to cd up
>>>>> to the parent directory and then back down to see the change.
>>>>>
>>>>> Glad you figured it out.
>>>>>
>>>>> For the TERM issue.   Did you stop the Wrapper before modifying the
>>>>> script?   You need to start the Wrapper after the ignore signals flag
>>>>> is set so it will be all set up to be able to stop the Wrapper
>>>>> correctly.   Please let me know if you are still having problems when
>>>>> you do this and I would be happy to help out further.
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>>>
>>>>> On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
>>>>>> I think I figured this out.  Because I had a putty window open to the
>>>>>> original folder, when it was renamed to _folder the putty window was
>>>>>> referring to the old renamed folder when running the sh script
>>>>>> although other commands like ls, cd worked with the new folder.  Once
>>>>>> I changed putty to the old renamed folder I could stop that service
>>>>>> and then start the new one once back to the new folder.
>>>>>>
>>>>>> Now back to the original issue regarding how to handle rouge TERM
>>>>>> commands, when I make the config change to ignore signals I now no
>>>>>> longer can use the wrapper's stop command I have to use kill -9 PID.
>>>>>> I really would like to use the wrapper to start/stop and not use kill.
>>>>>>
>>>>>> -Dave
>>>>>>
>>>>>> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>> Lief,
>>>>>>>
>>>>>>> The first thing I did is cd to the directory of the prior folder and
>>>>>>> stop the service (it was previously installed and started).  Then
>>>>>>> after it was stopped I renamed the entire folder with the _ prefix.  I
>>>>>>> then  replaced the entire folder with the same name as before.  I then
>>>>>>> started the service in the new folder (same name as before).
>>>>>>>
>>>>>>> The log file is: wrapper.logfile=./wrapper.log
>>>>>>>
>>>>>>> Yes I do have two conf files one in the program folder and one in
>>>>>>> _program folder but since I'm in program shouldn't it ignore the
>>>>>>> _program folder?  It's acting like the program is running from
>>>>>>> _program but I started it from program.
>>>>>>>
>>>>>>> The mysterious ways of Linux.
>>>>>>>
>>>>>>> -Dave
>>>>>>>
>>>>>>> -Dave
>>>>>>>
>>>>>>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>>>>>>> <lei...@ta...> wrote:
>>>>>>>> Dave,
>>>>>>>> On linux if you rename a file or folder which contains an open file
>>>>>>>> then the existing file handle will stay attached to the file.  But if
>>>>>>>> you restart the process (Wrapper) then it should load from the new
>>>>>>>> location.
>>>>>>>>
>>>>>>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>>>>>>> Please check your wrapper.conf file to see where it is pointing.
>>>>>>>>
>>>>>>>> How are you starting the Wrapper?  Is it possible that you have two
>>>>>>>> wrapper.conf files?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Leif
>>>>>>>>
>>>>>>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>> Leif,
>>>>>>>>>
>>>>>>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>>>>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>>>>>>> new program to the prior folder name, but now I see the log output is
>>>>>>>>> going to the old renamed folder.  This would work just fine on
>>>>>>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>>>>>>> to the renamed old folder.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> -Dave
>>>>>>>>>
>>>>>>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>>> David,
>>>>>>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>>>>>>> simply creating symbolic links to the script in most cases.
>>>>>>>>>>
>>>>>>>>>> Please let me know how it works for you.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Leif
>>>>>>>>>>
>>>>>>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>>> Leif,
>>>>>>>>>>>
>>>>>>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>>>>>>> Or just stop and restart?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> -Dave
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> David,
>>>>>>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>>>>>>
>>>>>>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>>>>>>
>>>>>>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>>>>>>> Please see the above page for more details.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me know how this works for you.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Leif
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>>>>>>> >
>>>>>>>>>>>> > public void controlEvent(int event) {
>>>>>>>>>>>> >
>>>>>>>>>>>> >         try {
>>>>>>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>>>>>>> >             } else {
>>>>>>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>>>>>>> > handle the event ourselves.
>>>>>>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>>>>>>> >                     log.warn("We are handling the received event
>>>>>>>>>>>> > ourselves and we are stopping the service");
>>>>>>>>>>>> >                     WrapperManager.stop(0);
>>>>>>>>>>>> >                 }
>>>>>>>>>>>> >             }
>>>>>>>>>>>> >         }
>>>>>>>>>>>> >     }
>>>>>>>>>>>> >
>>>>>>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>>>>>>> > they are doing)
>>>>>>>>>>>> >
>>>>>>>>>>>> > public void controlEvent( int event )
>>>>>>>>>>>> >  {
>>>>>>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>>>>>>> >        {
>>>>>>>>>>>> >            // Ignore
>>>>>>>>>>>> >        }  else   {
>>>>>>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>>>>>>> >        }
>>>>>>>>>>>> >  }
>>>>>>>>>>>> >
>>>>>>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>>>>>>> >
>>>>>>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>>>>>>> >
>>>>>>>>>>>> > Thanks,
>>>>>>>>>>>> > -Dave
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

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

Dave,
The following is from the 3.5.7 release notes.   Is this maybe what
you are seeing?
---
Fix a problem in the shell script that was preventing the script from
finding the running Wrapper process when it was started when the
working directory was in the same directory as the Wrapper binary, but
queried later from another location. It would also fail if it was
started from another location, but then queried from the location of
the Wrapper. This was introduced in 3.5.6 when the script stopped
changing the working directory in the script.
---

It would happen if you started the Wrapper from within the
$APP_HOME/bin directory as "./myapp start", but then stopped it from
the $APP_HOME directory as "bin/myapp stop".

The following was also fixed in 3.5.7:
---
Fix a problem in the shell script where it would fail to recognize a
running Wrapper if the Wrapper command line or path contained a square
bracket.
---

The full list of changes can always be found here:
http://wrapper.tanukisoftware.com/doc/english/release-notes.html

There have been other issues fixed and improvements made as well, if
you upgrade then I recommend upgrading to 3.5.9.

Cheers,
Leif

On Mon, Jun 27, 2011 at 4:12 AM, David Hoffer <dho...@gm...> wrote:
> I'm using version 3.5.6, perhaps that's the problem I need to upgrade?
>
> -Dave
>
> On Sun, Jun 26, 2011 at 7:49 AM, Leif Mortenson
> <lei...@ta...> wrote:
>> Dave,
>> I just went back and retested this with 3.5.9 and it appears to be
>> working correctly.
>>
>> What version of the Wrapper  are you using?  Please open the shell
>> script in an editor and make sure that the version of the script is
>> the same as that of the Wrapper.
>>
>> The ignore_signals mode of the script works by using an anchor file
>> created in the same directory as the wrapper binary.  It will be named
>> wrapper.anchor by default.   The Wrapper will shut itself down when
>> this file is deleted.   Please confirm that this file exists while the
>> Wrapper is running then try to delete it manually.
>> http://wrapper.tanukisoftware.com/doc/english/prop-anchorfile.html
>>
>> Cheers,
>> Leif
>>
>> On Sun, Jun 26, 2011 at 9:49 PM, David Hoffer <dho...@gm...> wrote:
>>> Lief,
>>>
>>> Yes, the first thing I did is stop the service, then I modified the
>>> config to ignore signals then I started the service, when I tried to
>>> stop it...the script tried over and over to stop it but could not
>>> not...so I Ctlr-C to stop the script and I killed the service with
>>> kill -9 PID (because without the -9 kill didn't stop it either).
>>>
>>> Once I put the script back the way it was I can start/stop using the script.
>>>
>>> Thanks,
>>> -Dave
>>>
>>> On Sun, Jun 26, 2011 at 6:43 AM, Leif Mortenson
>>> <lei...@ta...> wrote:
>>>> Dave,
>>>> Yes that would do it.  Linux is designed for use my multiple users.
>>>> If one user renames a directory while another user is doing something
>>>> in it, then UNIX tries to avoid causing problems.  You need to cd up
>>>> to the parent directory and then back down to see the change.
>>>>
>>>> Glad you figured it out.
>>>>
>>>> For the TERM issue.   Did you stop the Wrapper before modifying the
>>>> script?   You need to start the Wrapper after the ignore signals flag
>>>> is set so it will be all set up to be able to stop the Wrapper
>>>> correctly.   Please let me know if you are still having problems when
>>>> you do this and I would be happy to help out further.
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
>>>>> I think I figured this out.  Because I had a putty window open to the
>>>>> original folder, when it was renamed to _folder the putty window was
>>>>> referring to the old renamed folder when running the sh script
>>>>> although other commands like ls, cd worked with the new folder.  Once
>>>>> I changed putty to the old renamed folder I could stop that service
>>>>> and then start the new one once back to the new folder.
>>>>>
>>>>> Now back to the original issue regarding how to handle rouge TERM
>>>>> commands, when I make the config change to ignore signals I now no
>>>>> longer can use the wrapper's stop command I have to use kill -9 PID.
>>>>> I really would like to use the wrapper to start/stop and not use kill.
>>>>>
>>>>> -Dave
>>>>>
>>>>> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>>>>>> Lief,
>>>>>>
>>>>>> The first thing I did is cd to the directory of the prior folder and
>>>>>> stop the service (it was previously installed and started).  Then
>>>>>> after it was stopped I renamed the entire folder with the _ prefix.  I
>>>>>> then  replaced the entire folder with the same name as before.  I then
>>>>>> started the service in the new folder (same name as before).
>>>>>>
>>>>>> The log file is: wrapper.logfile=./wrapper.log
>>>>>>
>>>>>> Yes I do have two conf files one in the program folder and one in
>>>>>> _program folder but since I'm in program shouldn't it ignore the
>>>>>> _program folder?  It's acting like the program is running from
>>>>>> _program but I started it from program.
>>>>>>
>>>>>> The mysterious ways of Linux.
>>>>>>
>>>>>> -Dave
>>>>>>
>>>>>> -Dave
>>>>>>
>>>>>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>>>>>> <lei...@ta...> wrote:
>>>>>>> Dave,
>>>>>>> On linux if you rename a file or folder which contains an open file
>>>>>>> then the existing file handle will stay attached to the file.  But if
>>>>>>> you restart the process (Wrapper) then it should load from the new
>>>>>>> location.
>>>>>>>
>>>>>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>>>>>> Please check your wrapper.conf file to see where it is pointing.
>>>>>>>
>>>>>>> How are you starting the Wrapper?  Is it possible that you have two
>>>>>>> wrapper.conf files?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Leif
>>>>>>>
>>>>>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>> Leif,
>>>>>>>>
>>>>>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>>>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>>>>>> new program to the prior folder name, but now I see the log output is
>>>>>>>> going to the old renamed folder.  This would work just fine on
>>>>>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>>>>>> to the renamed old folder.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Dave
>>>>>>>>
>>>>>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>> David,
>>>>>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>>>>>> simply creating symbolic links to the script in most cases.
>>>>>>>>>
>>>>>>>>> Please let me know how it works for you.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Leif
>>>>>>>>>
>>>>>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>> Leif,
>>>>>>>>>>
>>>>>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>>>>>> Or just stop and restart?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> -Dave
>>>>>>>>>>
>>>>>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>>>>
>>>>>>>>>>> David,
>>>>>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>>>>>
>>>>>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>>>>>
>>>>>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>>>>>> Please see the above page for more details.
>>>>>>>>>>>
>>>>>>>>>>> Let me know how this works for you.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Leif
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>>>>>> >
>>>>>>>>>>> > public void controlEvent(int event) {
>>>>>>>>>>> >
>>>>>>>>>>> >         try {
>>>>>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>>>>>> >             } else {
>>>>>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>>>>>> > handle the event ourselves.
>>>>>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>>>>>> >                     log.warn("We are handling the received event
>>>>>>>>>>> > ourselves and we are stopping the service");
>>>>>>>>>>> >                     WrapperManager.stop(0);
>>>>>>>>>>> >                 }
>>>>>>>>>>> >             }
>>>>>>>>>>> >         }
>>>>>>>>>>> >     }
>>>>>>>>>>> >
>>>>>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>>>>>> > they are doing)
>>>>>>>>>>> >
>>>>>>>>>>> > public void controlEvent( int event )
>>>>>>>>>>> >  {
>>>>>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>>>>>> >        {
>>>>>>>>>>> >            // Ignore
>>>>>>>>>>> >        }  else   {
>>>>>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>>>>>> >        }
>>>>>>>>>>> >  }
>>>>>>>>>>> >
>>>>>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>>>>>> >
>>>>>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>>>>>> >
>>>>>>>>>>> > Thanks,
>>>>>>>>>>> > -Dave

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

[David H. <dho...@gm...>]

I'm using version 3.5.6, perhaps that's the problem I need to upgrade?

-Dave

On Sun, Jun 26, 2011 at 7:49 AM, Leif Mortenson
<lei...@ta...> wrote:
> Dave,
> I just went back and retested this with 3.5.9 and it appears to be
> working correctly.
>
> What version of the Wrapper  are you using?  Please open the shell
> script in an editor and make sure that the version of the script is
> the same as that of the Wrapper.
>
> The ignore_signals mode of the script works by using an anchor file
> created in the same directory as the wrapper binary.  It will be named
> wrapper.anchor by default.   The Wrapper will shut itself down when
> this file is deleted.   Please confirm that this file exists while the
> Wrapper is running then try to delete it manually.
> http://wrapper.tanukisoftware.com/doc/english/prop-anchorfile.html
>
> Cheers,
> Leif
>
> On Sun, Jun 26, 2011 at 9:49 PM, David Hoffer <dho...@gm...> wrote:
>> Lief,
>>
>> Yes, the first thing I did is stop the service, then I modified the
>> config to ignore signals then I started the service, when I tried to
>> stop it...the script tried over and over to stop it but could not
>> not...so I Ctlr-C to stop the script and I killed the service with
>> kill -9 PID (because without the -9 kill didn't stop it either).
>>
>> Once I put the script back the way it was I can start/stop using the script.
>>
>> Thanks,
>> -Dave
>>
>> On Sun, Jun 26, 2011 at 6:43 AM, Leif Mortenson
>> <lei...@ta...> wrote:
>>> Dave,
>>> Yes that would do it.  Linux is designed for use my multiple users.
>>> If one user renames a directory while another user is doing something
>>> in it, then UNIX tries to avoid causing problems.  You need to cd up
>>> to the parent directory and then back down to see the change.
>>>
>>> Glad you figured it out.
>>>
>>> For the TERM issue.   Did you stop the Wrapper before modifying the
>>> script?   You need to start the Wrapper after the ignore signals flag
>>> is set so it will be all set up to be able to stop the Wrapper
>>> correctly.   Please let me know if you are still having problems when
>>> you do this and I would be happy to help out further.
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
>>>> I think I figured this out.  Because I had a putty window open to the
>>>> original folder, when it was renamed to _folder the putty window was
>>>> referring to the old renamed folder when running the sh script
>>>> although other commands like ls, cd worked with the new folder.  Once
>>>> I changed putty to the old renamed folder I could stop that service
>>>> and then start the new one once back to the new folder.
>>>>
>>>> Now back to the original issue regarding how to handle rouge TERM
>>>> commands, when I make the config change to ignore signals I now no
>>>> longer can use the wrapper's stop command I have to use kill -9 PID.
>>>> I really would like to use the wrapper to start/stop and not use kill.
>>>>
>>>> -Dave
>>>>
>>>> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>>>>> Lief,
>>>>>
>>>>> The first thing I did is cd to the directory of the prior folder and
>>>>> stop the service (it was previously installed and started).  Then
>>>>> after it was stopped I renamed the entire folder with the _ prefix.  I
>>>>> then  replaced the entire folder with the same name as before.  I then
>>>>> started the service in the new folder (same name as before).
>>>>>
>>>>> The log file is: wrapper.logfile=./wrapper.log
>>>>>
>>>>> Yes I do have two conf files one in the program folder and one in
>>>>> _program folder but since I'm in program shouldn't it ignore the
>>>>> _program folder?  It's acting like the program is running from
>>>>> _program but I started it from program.
>>>>>
>>>>> The mysterious ways of Linux.
>>>>>
>>>>> -Dave
>>>>>
>>>>> -Dave
>>>>>
>>>>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>>>>> <lei...@ta...> wrote:
>>>>>> Dave,
>>>>>> On linux if you rename a file or folder which contains an open file
>>>>>> then the existing file handle will stay attached to the file.  But if
>>>>>> you restart the process (Wrapper) then it should load from the new
>>>>>> location.
>>>>>>
>>>>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>>>>> Please check your wrapper.conf file to see where it is pointing.
>>>>>>
>>>>>> How are you starting the Wrapper?  Is it possible that you have two
>>>>>> wrapper.conf files?
>>>>>>
>>>>>> Cheers,
>>>>>> Leif
>>>>>>
>>>>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>> Leif,
>>>>>>>
>>>>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>>>>> new program to the prior folder name, but now I see the log output is
>>>>>>> going to the old renamed folder.  This would work just fine on
>>>>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>>>>> to the renamed old folder.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Dave
>>>>>>>
>>>>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>>>>> <lei...@ta...> wrote:
>>>>>>>> David,
>>>>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>>>>> simply creating symbolic links to the script in most cases.
>>>>>>>>
>>>>>>>> Please let me know how it works for you.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Leif
>>>>>>>>
>>>>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>> Leif,
>>>>>>>>>
>>>>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>>>>> Or just stop and restart?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> -Dave
>>>>>>>>>
>>>>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>>>
>>>>>>>>>> David,
>>>>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>>>>
>>>>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>>>>
>>>>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>>>>> Please see the above page for more details.
>>>>>>>>>>
>>>>>>>>>> Let me know how this works for you.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Leif
>>>>>>>>>>
>>>>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>>>>> >
>>>>>>>>>> > public void controlEvent(int event) {
>>>>>>>>>> >
>>>>>>>>>> >         try {
>>>>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>>>>> >             } else {
>>>>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>>>>> > handle the event ourselves.
>>>>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>>>>> >                     log.warn("We are handling the received event
>>>>>>>>>> > ourselves and we are stopping the service");
>>>>>>>>>> >                     WrapperManager.stop(0);
>>>>>>>>>> >                 }
>>>>>>>>>> >             }
>>>>>>>>>> >         }
>>>>>>>>>> >     }
>>>>>>>>>> >
>>>>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>>>>> > they are doing)
>>>>>>>>>> >
>>>>>>>>>> > public void controlEvent( int event )
>>>>>>>>>> >  {
>>>>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>>>>> >        {
>>>>>>>>>> >            // Ignore
>>>>>>>>>> >        }  else   {
>>>>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>>>>> >        }
>>>>>>>>>> >  }
>>>>>>>>>> >
>>>>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>>>>> >
>>>>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>>>>> >
>>>>>>>>>> > Thanks,
>>>>>>>>>> > -Dave
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

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

Dave,
I just went back and retested this with 3.5.9 and it appears to be
working correctly.

What version of the Wrapper  are you using?  Please open the shell
script in an editor and make sure that the version of the script is
the same as that of the Wrapper.

The ignore_signals mode of the script works by using an anchor file
created in the same directory as the wrapper binary.  It will be named
wrapper.anchor by default.   The Wrapper will shut itself down when
this file is deleted.   Please confirm that this file exists while the
Wrapper is running then try to delete it manually.
http://wrapper.tanukisoftware.com/doc/english/prop-anchorfile.html

Cheers,
Leif

On Sun, Jun 26, 2011 at 9:49 PM, David Hoffer <dho...@gm...> wrote:
> Lief,
>
> Yes, the first thing I did is stop the service, then I modified the
> config to ignore signals then I started the service, when I tried to
> stop it...the script tried over and over to stop it but could not
> not...so I Ctlr-C to stop the script and I killed the service with
> kill -9 PID (because without the -9 kill didn't stop it either).
>
> Once I put the script back the way it was I can start/stop using the script.
>
> Thanks,
> -Dave
>
> On Sun, Jun 26, 2011 at 6:43 AM, Leif Mortenson
> <lei...@ta...> wrote:
>> Dave,
>> Yes that would do it.  Linux is designed for use my multiple users.
>> If one user renames a directory while another user is doing something
>> in it, then UNIX tries to avoid causing problems.  You need to cd up
>> to the parent directory and then back down to see the change.
>>
>> Glad you figured it out.
>>
>> For the TERM issue.   Did you stop the Wrapper before modifying the
>> script?   You need to start the Wrapper after the ignore signals flag
>> is set so it will be all set up to be able to stop the Wrapper
>> correctly.   Please let me know if you are still having problems when
>> you do this and I would be happy to help out further.
>>
>> Cheers,
>> Leif
>>
>> On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
>>> I think I figured this out.  Because I had a putty window open to the
>>> original folder, when it was renamed to _folder the putty window was
>>> referring to the old renamed folder when running the sh script
>>> although other commands like ls, cd worked with the new folder.  Once
>>> I changed putty to the old renamed folder I could stop that service
>>> and then start the new one once back to the new folder.
>>>
>>> Now back to the original issue regarding how to handle rouge TERM
>>> commands, when I make the config change to ignore signals I now no
>>> longer can use the wrapper's stop command I have to use kill -9 PID.
>>> I really would like to use the wrapper to start/stop and not use kill.
>>>
>>> -Dave
>>>
>>> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>>>> Lief,
>>>>
>>>> The first thing I did is cd to the directory of the prior folder and
>>>> stop the service (it was previously installed and started).  Then
>>>> after it was stopped I renamed the entire folder with the _ prefix.  I
>>>> then  replaced the entire folder with the same name as before.  I then
>>>> started the service in the new folder (same name as before).
>>>>
>>>> The log file is: wrapper.logfile=./wrapper.log
>>>>
>>>> Yes I do have two conf files one in the program folder and one in
>>>> _program folder but since I'm in program shouldn't it ignore the
>>>> _program folder?  It's acting like the program is running from
>>>> _program but I started it from program.
>>>>
>>>> The mysterious ways of Linux.
>>>>
>>>> -Dave
>>>>
>>>> -Dave
>>>>
>>>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>>>> <lei...@ta...> wrote:
>>>>> Dave,
>>>>> On linux if you rename a file or folder which contains an open file
>>>>> then the existing file handle will stay attached to the file.  But if
>>>>> you restart the process (Wrapper) then it should load from the new
>>>>> location.
>>>>>
>>>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>>>> Please check your wrapper.conf file to see where it is pointing.
>>>>>
>>>>> How are you starting the Wrapper?  Is it possible that you have two
>>>>> wrapper.conf files?
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>>>
>>>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>>>> Leif,
>>>>>>
>>>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>>>> new program to the prior folder name, but now I see the log output is
>>>>>> going to the old renamed folder.  This would work just fine on
>>>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>>>> to the renamed old folder.
>>>>>>
>>>>>> Thanks,
>>>>>> -Dave
>>>>>>
>>>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>>>> <lei...@ta...> wrote:
>>>>>>> David,
>>>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>>>> simply creating symbolic links to the script in most cases.
>>>>>>>
>>>>>>> Please let me know how it works for you.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Leif
>>>>>>>
>>>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>>> Leif,
>>>>>>>>
>>>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>>>> Or just stop and restart?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Dave
>>>>>>>>
>>>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>>>> <lei...@ta...> wrote:
>>>>>>>>>
>>>>>>>>> David,
>>>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>>>
>>>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>>>
>>>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>>>> Please see the above page for more details.
>>>>>>>>>
>>>>>>>>> Let me know how this works for you.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Leif
>>>>>>>>>
>>>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>>>> >
>>>>>>>>> > public void controlEvent(int event) {
>>>>>>>>> >
>>>>>>>>> >         try {
>>>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>>>> >             } else {
>>>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>>>> > handle the event ourselves.
>>>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>>>> >                     log.warn("We are handling the received event
>>>>>>>>> > ourselves and we are stopping the service");
>>>>>>>>> >                     WrapperManager.stop(0);
>>>>>>>>> >                 }
>>>>>>>>> >             }
>>>>>>>>> >         }
>>>>>>>>> >     }
>>>>>>>>> >
>>>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>>>> > they are doing)
>>>>>>>>> >
>>>>>>>>> > public void controlEvent( int event )
>>>>>>>>> >  {
>>>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>>>> >        {
>>>>>>>>> >            // Ignore
>>>>>>>>> >        }  else   {
>>>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>>>> >        }
>>>>>>>>> >  }
>>>>>>>>> >
>>>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>>>> >
>>>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > -Dave

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

[David H. <dho...@gm...>]

Lief,

Yes, the first thing I did is stop the service, then I modified the
config to ignore signals then I started the service, when I tried to
stop it...the script tried over and over to stop it but could not
not...so I Ctlr-C to stop the script and I killed the service with
kill -9 PID (because without the -9 kill didn't stop it either).

Once I put the script back the way it was I can start/stop using the script.

Thanks,
-Dave

On Sun, Jun 26, 2011 at 6:43 AM, Leif Mortenson
<lei...@ta...> wrote:
> Dave,
> Yes that would do it.  Linux is designed for use my multiple users.
> If one user renames a directory while another user is doing something
> in it, then UNIX tries to avoid causing problems.  You need to cd up
> to the parent directory and then back down to see the change.
>
> Glad you figured it out.
>
> For the TERM issue.   Did you stop the Wrapper before modifying the
> script?   You need to start the Wrapper after the ignore signals flag
> is set so it will be all set up to be able to stop the Wrapper
> correctly.   Please let me know if you are still having problems when
> you do this and I would be happy to help out further.
>
> Cheers,
> Leif
>
> On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
>> I think I figured this out.  Because I had a putty window open to the
>> original folder, when it was renamed to _folder the putty window was
>> referring to the old renamed folder when running the sh script
>> although other commands like ls, cd worked with the new folder.  Once
>> I changed putty to the old renamed folder I could stop that service
>> and then start the new one once back to the new folder.
>>
>> Now back to the original issue regarding how to handle rouge TERM
>> commands, when I make the config change to ignore signals I now no
>> longer can use the wrapper's stop command I have to use kill -9 PID.
>> I really would like to use the wrapper to start/stop and not use kill.
>>
>> -Dave
>>
>> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>>> Lief,
>>>
>>> The first thing I did is cd to the directory of the prior folder and
>>> stop the service (it was previously installed and started).  Then
>>> after it was stopped I renamed the entire folder with the _ prefix.  I
>>> then  replaced the entire folder with the same name as before.  I then
>>> started the service in the new folder (same name as before).
>>>
>>> The log file is: wrapper.logfile=./wrapper.log
>>>
>>> Yes I do have two conf files one in the program folder and one in
>>> _program folder but since I'm in program shouldn't it ignore the
>>> _program folder?  It's acting like the program is running from
>>> _program but I started it from program.
>>>
>>> The mysterious ways of Linux.
>>>
>>> -Dave
>>>
>>> -Dave
>>>
>>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>>> <lei...@ta...> wrote:
>>>> Dave,
>>>> On linux if you rename a file or folder which contains an open file
>>>> then the existing file handle will stay attached to the file.  But if
>>>> you restart the process (Wrapper) then it should load from the new
>>>> location.
>>>>
>>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>>> Please check your wrapper.conf file to see where it is pointing.
>>>>
>>>> How are you starting the Wrapper?  Is it possible that you have two
>>>> wrapper.conf files?
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>>> Leif,
>>>>>
>>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>>> new program to the prior folder name, but now I see the log output is
>>>>> going to the old renamed folder.  This would work just fine on
>>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>>> to the renamed old folder.
>>>>>
>>>>> Thanks,
>>>>> -Dave
>>>>>
>>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>>> <lei...@ta...> wrote:
>>>>>> David,
>>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>>> simply creating symbolic links to the script in most cases.
>>>>>>
>>>>>> Please let me know how it works for you.
>>>>>>
>>>>>> Cheers,
>>>>>> Leif
>>>>>>
>>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>>> Leif,
>>>>>>>
>>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>>> Or just stop and restart?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Dave
>>>>>>>
>>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>>> <lei...@ta...> wrote:
>>>>>>>>
>>>>>>>> David,
>>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>>
>>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>>
>>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>>> Please see the above page for more details.
>>>>>>>>
>>>>>>>> Let me know how this works for you.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Leif
>>>>>>>>
>>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>>> >
>>>>>>>> > public void controlEvent(int event) {
>>>>>>>> >
>>>>>>>> >         try {
>>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>>> >             } else {
>>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>>> > handle the event ourselves.
>>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>>> >                     log.warn("We are handling the received event
>>>>>>>> > ourselves and we are stopping the service");
>>>>>>>> >                     WrapperManager.stop(0);
>>>>>>>> >                 }
>>>>>>>> >             }
>>>>>>>> >         }
>>>>>>>> >     }
>>>>>>>> >
>>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>>> > they are doing)
>>>>>>>> >
>>>>>>>> > public void controlEvent( int event )
>>>>>>>> >  {
>>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>>> >        {
>>>>>>>> >            // Ignore
>>>>>>>> >        }  else   {
>>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>>> >        }
>>>>>>>> >  }
>>>>>>>> >
>>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>>> >
>>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > -Dave
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

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

Dave,
Yes that would do it.  Linux is designed for use my multiple users.
If one user renames a directory while another user is doing something
in it, then UNIX tries to avoid causing problems.  You need to cd up
to the parent directory and then back down to see the change.

Glad you figured it out.

For the TERM issue.   Did you stop the Wrapper before modifying the
script?   You need to start the Wrapper after the ignore signals flag
is set so it will be all set up to be able to stop the Wrapper
correctly.   Please let me know if you are still having problems when
you do this and I would be happy to help out further.

Cheers,
Leif

On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
> I think I figured this out.  Because I had a putty window open to the
> original folder, when it was renamed to _folder the putty window was
> referring to the old renamed folder when running the sh script
> although other commands like ls, cd worked with the new folder.  Once
> I changed putty to the old renamed folder I could stop that service
> and then start the new one once back to the new folder.
>
> Now back to the original issue regarding how to handle rouge TERM
> commands, when I make the config change to ignore signals I now no
> longer can use the wrapper's stop command I have to use kill -9 PID.
> I really would like to use the wrapper to start/stop and not use kill.
>
> -Dave
>
> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>> Lief,
>>
>> The first thing I did is cd to the directory of the prior folder and
>> stop the service (it was previously installed and started).  Then
>> after it was stopped I renamed the entire folder with the _ prefix.  I
>> then  replaced the entire folder with the same name as before.  I then
>> started the service in the new folder (same name as before).
>>
>> The log file is: wrapper.logfile=./wrapper.log
>>
>> Yes I do have two conf files one in the program folder and one in
>> _program folder but since I'm in program shouldn't it ignore the
>> _program folder?  It's acting like the program is running from
>> _program but I started it from program.
>>
>> The mysterious ways of Linux.
>>
>> -Dave
>>
>> -Dave
>>
>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>> <lei...@ta...> wrote:
>>> Dave,
>>> On linux if you rename a file or folder which contains an open file
>>> then the existing file handle will stay attached to the file.  But if
>>> you restart the process (Wrapper) then it should load from the new
>>> location.
>>>
>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>> Please check your wrapper.conf file to see where it is pointing.
>>>
>>> How are you starting the Wrapper?  Is it possible that you have two
>>> wrapper.conf files?
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>> Leif,
>>>>
>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>> new program to the prior folder name, but now I see the log output is
>>>> going to the old renamed folder.  This would work just fine on
>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>> to the renamed old folder.
>>>>
>>>> Thanks,
>>>> -Dave
>>>>
>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>> <lei...@ta...> wrote:
>>>>> David,
>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>> simply creating symbolic links to the script in most cases.
>>>>>
>>>>> Please let me know how it works for you.
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>>>
>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>> Leif,
>>>>>>
>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>> Or just stop and restart?
>>>>>>
>>>>>> Thanks,
>>>>>> -Dave
>>>>>>
>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>> <lei...@ta...> wrote:
>>>>>>>
>>>>>>> David,
>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>
>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>
>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>> Please see the above page for more details.
>>>>>>>
>>>>>>> Let me know how this works for you.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Leif
>>>>>>>
>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>> >
>>>>>>> > public void controlEvent(int event) {
>>>>>>> >
>>>>>>> >         try {
>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>> >             } else {
>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>> > handle the event ourselves.
>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>> >                     log.warn("We are handling the received event
>>>>>>> > ourselves and we are stopping the service");
>>>>>>> >                     WrapperManager.stop(0);
>>>>>>> >                 }
>>>>>>> >             }
>>>>>>> >         }
>>>>>>> >     }
>>>>>>> >
>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>> > they are doing)
>>>>>>> >
>>>>>>> > public void controlEvent( int event )
>>>>>>> >  {
>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>> >        {
>>>>>>> >            // Ignore
>>>>>>> >        }  else   {
>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>> >        }
>>>>>>> >  }
>>>>>>> >
>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>> >
>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > -Dave

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

[David H. <dho...@gm...>]

I think I figured this out.  Because I had a putty window open to the
original folder, when it was renamed to _folder the putty window was
referring to the old renamed folder when running the sh script
although other commands like ls, cd worked with the new folder.  Once
I changed putty to the old renamed folder I could stop that service
and then start the new one once back to the new folder.

Now back to the original issue regarding how to handle rouge TERM
commands, when I make the config change to ignore signals I now no
longer can use the wrapper's stop command I have to use kill -9 PID.
I really would like to use the wrapper to start/stop and not use kill.

-Dave

On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
> Lief,
>
> The first thing I did is cd to the directory of the prior folder and
> stop the service (it was previously installed and started).  Then
> after it was stopped I renamed the entire folder with the _ prefix.  I
> then  replaced the entire folder with the same name as before.  I then
> started the service in the new folder (same name as before).
>
> The log file is: wrapper.logfile=./wrapper.log
>
> Yes I do have two conf files one in the program folder and one in
> _program folder but since I'm in program shouldn't it ignore the
> _program folder?  It's acting like the program is running from
> _program but I started it from program.
>
> The mysterious ways of Linux.
>
> -Dave
>
> -Dave
>
> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
> <lei...@ta...> wrote:
>> Dave,
>> On linux if you rename a file or folder which contains an open file
>> then the existing file handle will stay attached to the file.  But if
>> you restart the process (Wrapper) then it should load from the new
>> location.
>>
>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>> Please check your wrapper.conf file to see where it is pointing.
>>
>> How are you starting the Wrapper?  Is it possible that you have two
>> wrapper.conf files?
>>
>> Cheers,
>> Leif
>>
>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>> Leif,
>>>
>>> Where is this symbolic link stored?  Because this was a major upgrade
>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>> new program to the prior folder name, but now I see the log output is
>>> going to the old renamed folder.  This would work just fine on
>>> Windows.  Not sure what I have to do to fix any links that may point
>>> to the renamed old folder.
>>>
>>> Thanks,
>>> -Dave
>>>
>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>> <lei...@ta...> wrote:
>>>> David,
>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>> simply creating symbolic links to the script in most cases.
>>>>
>>>> Please let me know how it works for you.
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>> Leif,
>>>>>
>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>> Or just stop and restart?
>>>>>
>>>>> Thanks,
>>>>> -Dave
>>>>>
>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>> <lei...@ta...> wrote:
>>>>>>
>>>>>> David,
>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>> shutdown process regardless of what this method does.   For this
>>>>>> reason, this method is more useful as a reporting method.
>>>>>>
>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>> want to use the wrapper.ignore_signals property
>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>
>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>> Please see the above page for more details.
>>>>>>
>>>>>> Let me know how this works for you.
>>>>>>
>>>>>> Cheers,
>>>>>> Leif
>>>>>>
>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>> >
>>>>>> > public void controlEvent(int event) {
>>>>>> >
>>>>>> >         try {
>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>> >                 // The Wrapper will take care of this event
>>>>>> >             } else {
>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>> > handle the event ourselves.
>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>> >                     log.warn("We are handling the received event
>>>>>> > ourselves and we are stopping the service");
>>>>>> >                     WrapperManager.stop(0);
>>>>>> >                 }
>>>>>> >             }
>>>>>> >         }
>>>>>> >     }
>>>>>> >
>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>> > they are doing)
>>>>>> >
>>>>>> > public void controlEvent( int event )
>>>>>> >  {
>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>> >        {
>>>>>> >            // Ignore
>>>>>> >        }  else   {
>>>>>> >           WrapperManager.stop( 0 );
>>>>>> >        }
>>>>>> >  }
>>>>>> >
>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>> >
>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>> >
>>>>>> > Thanks,
>>>>>> > -Dave
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense..
>> http://p.sf.net/sfu/splunk-d2d-c1
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

[David H. <dho...@gm...>]

Lief,

The first thing I did is cd to the directory of the prior folder and
stop the service (it was previously installed and started).  Then
after it was stopped I renamed the entire folder with the _ prefix.  I
then  replaced the entire folder with the same name as before.  I then
started the service in the new folder (same name as before).

The log file is: wrapper.logfile=./wrapper.log

Yes I do have two conf files one in the program folder and one in
_program folder but since I'm in program shouldn't it ignore the
_program folder?  It's acting like the program is running from
_program but I started it from program.

The mysterious ways of Linux.

-Dave

-Dave

On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
<lei...@ta...> wrote:
> Dave,
> On linux if you rename a file or folder which contains an open file
> then the existing file handle will stay attached to the file.  But if
> you restart the process (Wrapper) then it should load from the new
> location.
>
> I am not 100% clear what steps you took.   The wrapper.logfile property.
> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
> Please check your wrapper.conf file to see where it is pointing.
>
> How are you starting the Wrapper?  Is it possible that you have two
> wrapper.conf files?
>
> Cheers,
> Leif
>
> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>> Leif,
>>
>> Where is this symbolic link stored?  Because this was a major upgrade
>> I renamed the existing folder (prefixed it with _) and uploaded the
>> new program to the prior folder name, but now I see the log output is
>> going to the old renamed folder.  This would work just fine on
>> Windows.  Not sure what I have to do to fix any links that may point
>> to the renamed old folder.
>>
>> Thanks,
>> -Dave
>>
>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>> <lei...@ta...> wrote:
>>> David,
>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>> simply creating symbolic links to the script in most cases.
>>>
>>> Please let me know how it works for you.
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>> Leif,
>>>>
>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>> Or just stop and restart?
>>>>
>>>> Thanks,
>>>> -Dave
>>>>
>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>> <lei...@ta...> wrote:
>>>>>
>>>>> David,
>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>> the signal within the JVM process.  This is a very old API and the
>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>> shutdown process regardless of what this method does.   For this
>>>>> reason, this method is more useful as a reporting method.
>>>>>
>>>>> To prevent your application from responding to TERM signals, you will
>>>>> want to use the wrapper.ignore_signals property
>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>
>>>>> On UNIX, the recommended way of doing this is to set the
>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>> made as it changes the way the script controls the Wrapper.
>>>>> Please see the above page for more details.
>>>>>
>>>>> Let me know how this works for you.
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>>>
>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>> >
>>>>> > public void controlEvent(int event) {
>>>>> >
>>>>> >         try {
>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>> >                 // The Wrapper will take care of this event
>>>>> >             } else {
>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>> > handle the event ourselves.
>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>> >                     log.warn("We are handling the received event
>>>>> > ourselves and we are stopping the service");
>>>>> >                     WrapperManager.stop(0);
>>>>> >                 }
>>>>> >             }
>>>>> >         }
>>>>> >     }
>>>>> >
>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>> > they are doing)
>>>>> >
>>>>> > public void controlEvent( int event )
>>>>> >  {
>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>> > WrapperManager.isLaunchedAsService() )
>>>>> >        {
>>>>> >            // Ignore
>>>>> >        }  else   {
>>>>> >           WrapperManager.stop( 0 );
>>>>> >        }
>>>>> >  }
>>>>> >
>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>> >
>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>> > signal?  should I restart after shutdown?  How?
>>>>> >
>>>>> > Thanks,
>>>>> > -Dave
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense..
> http://p.sf.net/sfu/splunk-d2d-c1
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

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

Dave,
On linux if you rename a file or folder which contains an open file
then the existing file handle will stay attached to the file.  But if
you restart the process (Wrapper) then it should load from the new
location.

I am not 100% clear what steps you took.   The wrapper.logfile property.
http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
Please check your wrapper.conf file to see where it is pointing.

How are you starting the Wrapper?  Is it possible that you have two
wrapper.conf files?

Cheers,
Leif

On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
> Leif,
>
> Where is this symbolic link stored?  Because this was a major upgrade
> I renamed the existing folder (prefixed it with _) and uploaded the
> new program to the prior folder name, but now I see the log output is
> going to the old renamed folder.  This would work just fine on
> Windows.  Not sure what I have to do to fix any links that may point
> to the renamed old folder.
>
> Thanks,
> -Dave
>
> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
> <lei...@ta...> wrote:
>> David,
>> Just stopping should be fine.   "Installing" on a UNIX system is
>> simply creating symbolic links to the script in most cases.
>>
>> Please let me know how it works for you.
>>
>> Cheers,
>> Leif
>>
>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>> Leif,
>>>
>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>> Or just stop and restart?
>>>
>>> Thanks,
>>> -Dave
>>>
>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>> <lei...@ta...> wrote:
>>>>
>>>> David,
>>>> The controlEvent method gives you a chance to either handle or ignore
>>>> the signal within the JVM process.  This is a very old API and the
>>>> problem with it is that the Wrapper process may also receive a TERM
>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>> shutdown process regardless of what this method does.   For this
>>>> reason, this method is more useful as a reporting method.
>>>>
>>>> To prevent your application from responding to TERM signals, you will
>>>> want to use the wrapper.ignore_signals property
>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>
>>>> On UNIX, the recommended way of doing this is to set the
>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>> made as it changes the way the script controls the Wrapper.
>>>> Please see the above page for more details.
>>>>
>>>> Let me know how this works for you.
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>> > I have the wrapper installed on Linux as a service and need as close
>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>> >
>>>> > public void controlEvent(int event) {
>>>> >
>>>> >         try {
>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>> >                 // The Wrapper will take care of this event
>>>> >             } else {
>>>> >                 // We are not being controlled by the Wrapper, so
>>>> > handle the event ourselves.
>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>> >                     log.warn("We are handling the received event
>>>> > ourselves and we are stopping the service");
>>>> >                     WrapperManager.stop(0);
>>>> >                 }
>>>> >             }
>>>> >         }
>>>> >     }
>>>> >
>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>> > they are doing)
>>>> >
>>>> > public void controlEvent( int event )
>>>> >  {
>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>> > WrapperManager.isLaunchedAsService() )
>>>> >        {
>>>> >            // Ignore
>>>> >        }  else   {
>>>> >           WrapperManager.stop( 0 );
>>>> >        }
>>>> >  }
>>>> >
>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>> >
>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>> > signal?  should I restart after shutdown?  How?
>>>> >
>>>> > Thanks,
>>>> > -Dave

Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

[David H. <dho...@gm...>]

Leif,

Where is this symbolic link stored?  Because this was a major upgrade
I renamed the existing folder (prefixed it with _) and uploaded the
new program to the prior folder name, but now I see the log output is
going to the old renamed folder.  This would work just fine on
Windows.  Not sure what I have to do to fix any links that may point
to the renamed old folder.

Thanks,
-Dave

On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
<lei...@ta...> wrote:
> David,
> Just stopping should be fine.   "Installing" on a UNIX system is
> simply creating symbolic links to the script in most cases.
>
> Please let me know how it works for you.
>
> Cheers,
> Leif
>
> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>> Leif,
>>
>> I'm about ready to deploy this change.  I understand it needs to be stopped
>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>> Or just stop and restart?
>>
>> Thanks,
>> -Dave
>>
>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>> <lei...@ta...> wrote:
>>>
>>> David,
>>> The controlEvent method gives you a chance to either handle or ignore
>>> the signal within the JVM process.  This is a very old API and the
>>> problem with it is that the Wrapper process may also receive a TERM
>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>> shutdown process regardless of what this method does.   For this
>>> reason, this method is more useful as a reporting method.
>>>
>>> To prevent your application from responding to TERM signals, you will
>>> want to use the wrapper.ignore_signals property
>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>
>>> On UNIX, the recommended way of doing this is to set the
>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>> made as it changes the way the script controls the Wrapper.
>>> Please see the above page for more details.
>>>
>>> Let me know how this works for you.
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>> > I have the wrapper installed on Linux as a service and need as close
>>> > to 100% up time as is possible.  The wrapper recently received a
>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>> > controlEvent() is like this...as copied from some JSW sample code...
>>> >
>>> > public void controlEvent(int event) {
>>> >
>>> >         try {
>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>> >                 // The Wrapper will take care of this event
>>> >             } else {
>>> >                 // We are not being controlled by the Wrapper, so
>>> > handle the event ourselves.
>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>> >                     log.warn("We are handling the received event
>>> > ourselves and we are stopping the service");
>>> >                     WrapperManager.stop(0);
>>> >                 }
>>> >             }
>>> >         }
>>> >     }
>>> >
>>> > Now I see that recent javadocs say to use...(unless one knows what
>>> > they are doing)
>>> >
>>> > public void controlEvent( int event )
>>> >  {
>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>> > WrapperManager.isLaunchedAsService() )
>>> >        {
>>> >            // Ignore
>>> >        }  else   {
>>> >           WrapperManager.stop( 0 );
>>> >        }
>>> >  }
>>> >
>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>> > provides 100% up time, rather it just shuts things down cleanly.
>>> >
>>> > What is the right way to handle this?  I.e. should I ignore the
>>> > signal?  should I restart after shutdown?  How?
>>> >
>>> > Thanks,
>>> > -Dave
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] AUTO: Neeraja Kollu is out of office (returning 06/23/2011)

[Neeraja K. <nee...@in...>]

I am out of the office until 06/23/2011.


Please contact the following people for any asistance required during my
absence.

MMC - Sadanand Poorajan
Mercedes-Benz - Srinivasa K Korada
Honda - Sita Lakshmi




Note: This is an automated response to your message  "Re: [Wrapper-user]
Error message from wrapper launching log" sent on 18/6/11 10:26:20.

This is the only notification you will receive while this person is away.

Re: [Wrapper-user] Error message from wrapper launching log

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

Ming,
What version of the Wrapper are you using?   It is difficult to say
exactly what is happening unless you enable the Wrapper's debug output
with wrapper.debug=true.

The Wrapper is killing the JVM because it is not receiving any
response from the JVM for more than the ping timeout which defaults to
30 seconds.   This is usually because the JVM is frozen, but it can
also happen if the Java process is being starved of CPU or IO.  The
most common is due to heavy disk swapping due to low memory.   Of
course when this happens, the JVM and your application will be
unresponsive for this time but if you really want to allow this then
you can extend the ping timeout.  This is a work around, but such long
JVM freezes are usually indicative of another problem:
http://wrapper.tanukisoftware.com/doc/english/prop-ping-timeout.html

Cheers,
Leif

On Fri, Jun 17, 2011 at 5:21 AM, Chen, Ming Ming <min...@hp...> wrote:
> Hi,
> I got the following error message in the wrapper log file for my application. This is the first time I see this kind message, why do I get this message? I don't think that my application/JVM was hung, it was running based on the messages in my own log file from my application.. My application/jvm was killed and restarted. Why does this happens.?
> Thanks in advance for your help.
> Regards
> Ming
>
>
> =========================
> STATUS | wrapper  | 2011/06/13 10:48:05 | Launching a JVM...
> INFO   | jvm 1    | 2011/06/13 10:48:06 | WrapperManager: Initializing...
> ERROR  | wrapper  | 2011/06/13 10:53:54 | JVM appears hung: Timed out waiting for signal from JVM.
> ERROR  | wrapper  | 2011/06/13 10:53:55 | JVM did not exit on request, terminated
> STATUS | wrapper  | 2011/06/13 10:54:00 | Launching a JVM...
> INFO   | jvm 2    | 2011/06/13 10:54:01 | WrapperManager: Initializing...
> STATUS | wrapper  | 2011/06/13 10:54:38 | <-- Wrapper Stopped
> STATUS | wrapper  | 2011/06/13 14:06:00 | --> Wrapper Started as Console

[Wrapper-user] Error message from wrapper launching log

[Chen, M. M. <min...@hp...>]

Hi,
I got the following error message in the wrapper log file for my application. This is the first time I see this kind message, why do I get this message? I don't think that my application/JVM was hung, it was running based on the messages in my own log file from my application.. My application/jvm was killed and restarted. Why does this happens.?
Thanks in advance for your help.
Regards
Ming


=========================
STATUS | wrapper  | 2011/06/13 10:48:05 | Launching a JVM...
INFO   | jvm 1    | 2011/06/13 10:48:06 | WrapperManager: Initializing...
ERROR  | wrapper  | 2011/06/13 10:53:54 | JVM appears hung: Timed out waiting for signal from JVM.
ERROR  | wrapper  | 2011/06/13 10:53:55 | JVM did not exit on request, terminated
STATUS | wrapper  | 2011/06/13 10:54:00 | Launching a JVM...
INFO   | jvm 2    | 2011/06/13 10:54:01 | WrapperManager: Initializing...
STATUS | wrapper  | 2011/06/13 10:54:38 | <-- Wrapper Stopped
STATUS | wrapper  | 2011/06/13 14:06:00 | --> Wrapper Started as Console

Re: [Wrapper-user] Wrapper shut down issue As a Service

[Christian M. <chr...@ta...>]

Hi Venkata,

It seems the timeout for the JVM to stop in a timely manner expired:
http://wrapper.tanukisoftware.com/doc/english/prop-jvm-exit-timeout.html

Hence that, the Wrapper will kill the application forcibly and exit
with exit code 1.

The default value for wrapper.jvm_exit.timeout is 15 seconds, so
probably you need to extend the timeout to a more appropriate value
for you.

Hope this helps you out.

Best Regards,
Christian


On Wed, Jun 15, 2011 at 8:11 AM, Venkata Jakka (vejakka)
<ve...@ci...> wrote:
>
> Hi All,
>
>
> I am able to setup  JBoss Application server as Windows service using
> JavaWebService . But i see some error while stoping the window service.  Log
> info details are below.
>
>
> INFO   | jvm 1    | 2011/06/14 16:03:03 | 16:03:03,210 INFO  [AjpProtocol]
> Pausing Coyote AJP/1.3 on ajp-127.0.0.1-8999
> ERROR  | wrapper  | 2011/06/14 16:03:03 | Shutdown failed: Timed out waiting
> for the JVM to terminate.
> ERROR  | wrapper  | 2011/06/14 16:03:04 | JVM did not exit on request,
> terminated
> STATUS | wrapper  | 2011/06/14 16:03:04 | <-- Wrapper Stopped
>
>
> Even i went and checked the event log, it shows the error message as "exit
> code return by wrapper.exe is 1. "
>
> Any suggestions / advise are required.
>
> Thanks
> Venkat
>
>
> Please find my configuration file detils below.
> =============================
>
> set.JBOSS_HOME=C:\newScale\jboss-4.2.3.GA
> set.JAVA_HOME=C:\thirdparty\sun\win32\jdk1.6.0_12
> wrapper.java.command=%JAVA_HOME%/bin/java
> # Java Main class.
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
> # Java Classpath (include wrapper.jar)
> wrapper.java.classpath.1=%JBOSS_HOME%/bin/run.jar
> wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
> wrapper.java.classpath.3=%JBOSS_HOME%/lib/wrapper.jar
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> #For 32-bit architectures
> wrapper.java.library.path.1=%JBOSS_HOME%/lib
> #For 64-bit architectures
> #wrapper.java.library.path.1=%JBOSS_HOME%/bin/native/lib64
> # Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit
> mode.
> wrapper.java.additional.auto_bits=TRUE
> # Java Additional Parameters
> # JVM settings
> wrapper.java.additional.1=-server
> wrapper.java.additional.2=-XX:MaxPermSize=512m
> wrapper.java.additional.3=-Dprogram.name=run.bat
> wrapper.java.additional.4=-Djava.endorsed.dirs=../lib/endorsed
> wrapper.java.additional.5=-Dorg.jboss.resolver.warning=true
> wrapper.java.additional.6=-Dsun.rmi.dgc.client.gcInterval=3600000
> wrapper.java.additional.7=-Dsun.rmi.dgc.server.gcInterval=3600000
> wrapper.java.additional.8=-Djava.net.preferIPv4Stack=true
> wrapper.java.additional.9=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
> # Initial Java Heap Size (in MB)
> wrapper.java.initmemory=128
> # Maximum Java Heap Size (in MB)
> wrapper.java.maxmemory=512
> # Application parameters.  Add parameters as needed starting from 1
> wrapper.app.parameter.1=org.jboss.Main
> wrapper.app.parameter.2=-c RequestCenter
>
> #********************************************************************
> # 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.
> # Name of the service
> #wra...@ap...@
> wrapper.name=RequestCenterServiceJWS
> # Display name of the service
> #wra...@ap...@
> wrapper.displayname=RequestCenter Service JWS
> # Description of the service
> #wra...@ap...@
> wrapper.description=This is for Paris RequestCenter Service JWS  testing
> wrapper.shutdown.timeout=30
>
> #********************************************************************
> # Wrapper Logging Properties
> #********************************************************************
> # Format of output for the console.  (See docs for formats)
> wrapper.console.format=PM
> # Log Level for console output.  (See docs for log levels)
> wrapper.console.loglevel=INFO
> # Log file to use for wrapper output logging.
> wrapper.logfile=C:\newScale\logs\wrapperRC.log
> # Format of output for the log file.  (See docs for formats)
> wrapper.logfile.format=LPTM
> # Log Level for log file output.  (See docs for log levels)
> wrapper.logfile.loglevel=INFO
> # 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 = 10 megabytes.
> wrapper.logfile.maxsize=1m
> # 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=20
>
>
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] Wrapper shut down issue As a Service

[Venkata J. (vejakka) <ve...@ci...>]

 
Hi All,
 
 
I am able to setup  JBoss Application server as Windows service using JavaWebService . But i see some error while stoping the window service.  Log info details are below.
 
 
INFO   | jvm 1    | 2011/06/14 16:03:03 | 16:03:03,210 INFO  [AjpProtocol] Pausing Coyote AJP/1.3 on ajp-127.0.0.1-8999
ERROR  | wrapper  | 2011/06/14 16:03:03 | Shutdown failed: Timed out waiting for the JVM to terminate.
ERROR  | wrapper  | 2011/06/14 16:03:04 | JVM did not exit on request, terminated
STATUS | wrapper  | 2011/06/14 16:03:04 | <-- Wrapper Stopped
 
 
Even i went and checked the event log, it shows the error message as "exit code return by wrapper.exe is 1. " 
 
Any suggestions / advise are required.
 
Thanks
Venkat
 
 
Please find my configuration file detils below.
=============================
 
set.JBOSS_HOME=C:\newScale\jboss-4.2.3.GA
set.JAVA_HOME=C:\thirdparty\sun\win32\jdk1.6.0_12
wrapper.java.command=%JAVA_HOME%/bin/java
# Java Main class.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
# Java Classpath (include wrapper.jar)
wrapper.java.classpath.1=%JBOSS_HOME%/bin/run.jar
wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
wrapper.java.classpath.3=%JBOSS_HOME%/lib/wrapper.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
#For 32-bit architectures
wrapper.java.library.path.1=%JBOSS_HOME%/lib
#For 64-bit architectures
#wrapper.java.library.path.1=%JBOSS_HOME%/bin/native/lib64
# Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=TRUE
# Java Additional Parameters
# JVM settings
wrapper.java.additional.1=-server
wrapper.java.additional.2=-XX:MaxPermSize=512m
wrapper.java.additional.3=-Dprogram.name=run.bat
wrapper.java.additional.4=-Djava.endorsed.dirs=../lib/endorsed
wrapper.java.additional.5=-Dorg.jboss.resolver.warning=true
wrapper.java.additional.6=-Dsun.rmi.dgc.client.gcInterval=3600000
wrapper.java.additional.7=-Dsun.rmi.dgc.server.gcInterval=3600000
wrapper.java.additional.8=-Djava.net.preferIPv4Stack=true
wrapper.java.additional.9=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=512
# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=org.jboss.Main
wrapper.app.parameter.2=-c RequestCenter

 
#********************************************************************
# 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.
# Name of the service
#wra...@ap...@
wrapper.name=RequestCenterServiceJWS
# Display name of the service
#wra...@ap...@
wrapper.displayname=RequestCenter Service JWS
# Description of the service
#wra...@ap...@
wrapper.description=This is for Paris RequestCenter Service JWS  testing
wrapper.shutdown.timeout=30
 
#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM
# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO
# Log file to use for wrapper output logging.
wrapper.logfile=C:\newScale\logs\wrapperRC.log
# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM
# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO
# 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 = 10 megabytes.
wrapper.logfile.maxsize=1m
# 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=20

 
 
 
 
 

[Wrapper-user] AUTO: Neeraja Kollu is out of office (returning 06/13/2011)

[Neeraja K. <nee...@in...>]

I am out of the office until 06/13/2011.


Please contact the following people for any asistance required during my
absence.

MMC - Sadanand Poorajan
Mercedes-Benz - Srinivasa K Korada




Note: This is an automated response to your message  "[Wrapper-user]
WrapperJarApp: Encountered an error running main.." sent on 10/6/11
13:15:43.

This is the only notification you will receive while this person is away.

Re: [Wrapper-user] koen.stoop@gondrand.be - Re: WrapperJarApp: Encountered an error runningmain.. - Bayesian Filter detected spam

[Koen S. <koe...@go...>]

Christian,

Adding Csv2Db.jar to the classpath, solved the problem. Many thanks.

As per the instructions of Method 4, I did add my jar to the wrapper.app.parameter.1 property.

What do you mean by:

"The Classloader handling in your application is slightly different when running with the WrapperJarApp.
You might need to get a little bit changed to actually use:
<Your Class>.class.getClassLoader().

instead of the static way with ClassLoader...

Changing the handling to that way, you wouldn't need to define Csv2Db.jar in the classpath..."

Do I have to change the source code ?

Regards,
Koen

-----Oorspronkelijk bericht-----
Van: Christian Mueller [mailto:chr...@ta...] 
Verzonden: vrijdag 10 juni 2011 10:28
Aan: wra...@li...
Onderwerp: koe...@go... - Re: [Wrapper-user] WrapperJarApp: Encountered an error runningmain.. - Bayesian Filter detected spam

Koen,

Can you try the following:
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/Csv2Db.jar
wrapper.java.classpath.3=../lib/lib/*.jar

Adding your jar to the class path should already fix your problem.
(I use a wildcard for the other jars just to make it a little bit more easy to handle the classpath)

The Classloader handling in your application is slightly different when running with the WrapperJarApp.
You might need to get a little bit changed to actually use:
<Your Class>.class.getClassLoader().

instead of the static way with ClassLoader...

Changing the handling to that way, you wouldn't need to define Csv2Db.jar in the classpath...

Please let me know if you have any further questions.

Best Regards,
Christian

On Fri, Jun 10, 2011 at 4:45 PM, Koen Stoop <koe...@go...> wrote:
> Hi all,
>
> I wrote a Java Application using Netbeans 7.0 IDE.
> The application monitors a folder for the deletion of a lockfile.
> When this happens the app starts processing by reading a csv-file in 
> the monitored folder, and writing the file to a MySQL database using 
> Persistence JPA 2.0
>
> This is how the {WRAPPER_HOME} folder looks like:
> <bin>
>      csv2db
>      wrapper
> <lib>
>       Csv2Db.jar
>       libwrapper.so
>       wrapper.jar
>       <lib>
>            eclipselink-2.2.0.jar
>            eclipselink-javax.persistence-2.0.jar
>            jpathwatch-0-94.jar
>            mysql-connector-java-5.1.13-bin.jar
>            opencsv-2.2.jar
> <logs>
>    wrapper.log
> <conf>
>     wrapper.conf
>
> when i run the program from the <lib> folder like: "java -jar Csv2Db" 
> all is working like it should be.
>
> I can start/stop it as a daemon using WrapperJarApp (Method 4) but 
> when the application starts processing the csv-file it gives the following error:
>
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error: 
> Encountered an error running main:
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:
> javax.persistence.PersistenceException: No Persistence provider for 
> EntityManager named Csv2DbPU INFO   | jvm 1    | 2011/06/10 08:30:04 | 
> WrapperJarApp Error:  at 
> javax.persistence.Persistence.createEntityManagerFactory(Unknown 
> Source) INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  
> at javax.persistence.Persistence.createEntityManagerFactory(Unknown 
> Source) INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  
> at
> csv2db.Csv2Db.main(Csv2Db.java:150)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) INFO   | 
> jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) INFO   | 
> jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) INFO   
> | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> java.lang.reflect.Method.invoke(Unknown Source) INFO   | jvm 1    | 
> 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> org.tanukisoftware.wrapper.WrapperJarApp.run(WrapperJarApp.java:385)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> java.lang.Thread.run(Unknown Source) INFO   | jvm 1    | 2011/06/10 
> 08:30:04 | WrapperManager Debug:
> WrapperManager.stop(1) called by thread: WrapperJarAppMain INFO   | 
> jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: Send a packet 
> STOP : 1 INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager 
> Debug: Stopped checking for control events.
> DEBUG  | wrapperp | 2011/06/10 08:30:04 | read a packet STOP : 1 DEBUG  
> | wrapper  | 2011/06/10 08:30:04 | JVM requested a shutdown. (1) DEBUG  
> | wrapper  | 2011/06/10 08:30:04 | wrapperStopProcess(1, FALSE) 
> called.
> DEBUG  | wrapper  | 2011/06/10 08:30:04 | Sending stop signal to JVM
>
> It seems the wrapper can't find the library "eclipselink-2.2.0.jar" 
> but he can find the library "jpathwatch-0-94.jar" !?
> What is going wrong ? How can i troubleshoot this ?
>
> Here's my wrapper.conf:
> ===============================================
> #encoding=UTF-8
> # Configuration files must begin with a line specifying the encoding #  
> of the the file.
>
> #********************************************************************
> # Wrapper License Properties (Ignored by Community Edition)
> #********************************************************************
> # Professional and Standard Editions of the Wrapper require a valid #  
> License Key to start.  Licenses can be purchased or a trial license #  
> requested on the following pages:
> # http://wrapper.tanukisoftware.com/purchase
> # http://wrapper.tanukisoftware.com/trial
>
> # Include file problems can be debugged by removing the first '#'
> #  from the following line:
> #include.debug
>
> # The Wrapper will look for either of the following optional files for 
> a #  valid License Key.  License Key properties can optionally be 
> included #  directly in this configuration file.
> #include ../conf/wrapper-license.conf
> #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
>
> # The following property will output information about which License 
> Key(s) #  are being found, and can aid in resolving any licensing problems.
> #wrapper.license.debug=TRUE
>
> #********************************************************************
> # Wrapper Localization
> #********************************************************************
> # Specify the locale which the Wrapper should use.  By default the 
> system #  locale is used.
> #wrapper.lang=en_US # en_US or ja_JP
>
> # Specify the location of the Wrapper's language resources.  If these 
> are #  missing, the Wrapper will default to the en_US locale.
> wrapper.lang.folder=../lang
>
> #********************************************************************
> # Wrapper Java Properties
> #********************************************************************
> # Java Application
> #  Locate the java binary on the system PATH:
> wrapper.java.command=java
> #  Specify a specific java binary:
> #set.JAVA_HOME=/java/path
> #wrapper.java.command=%JAVA_HOME%/bin/java
>
> # Tell the Wrapper to log the full generated Java command line.
> wrapper.java.command.loglevel=DEBUG
>
> # 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=org.tanukisoftware.wrapper.WrapperJarApp
>
> # Java Classpath (include wrapper.jar)  Add class path elements as #  
> needed starting from 1 
> wrapper.java.classpath.1=/usr/lib/csv2db/lib/wrapper.jar
> wrapper.java.classpath.2=/usr/lib/csv2db/lib/lib/eclipselink-javax.per
> sistence-2.0.jar 
> wrapper.java.classpath.3=/usr/lib/csv2db/lib/lib/eclipselink-2.2.0.jar
> wrapper.java.classpath.4=/usr/lib/csv2db/lib/lib/mysql-connector-java-
> 5.1.13-bin.jar 
> wrapper.java.classpath.5=/usr/lib/csv2db/lib/lib/jpathwatch-0-94.jar
> wrapper.java.classpath.6=/usr/lib/csv2db/lib/lib/opencsv-2.2.jar
>
> # Java Library Path (location of Wrapper.DLL or libwrapper.so) 
> wrapper.java.library.path.1=/usr/lib/csv2db/lib
>
> # Java Bits.  On applicable platforms, tells the JVM to run in 32 or 
> 64-bit mode.
> wrapper.java.additional.auto_bits=TRUE
>
> # Java Additional Parameters
> wrapper.java.additional.1=
>
> # Initial Java Heap Size (in MB)
> #wrapper.java.initmemory=3
>
> # Maximum Java Heap Size (in MB)
> #wrapper.java.maxmemory=64
>
> # Application parameters.  Add parameters as needed starting from 1 
> wrapper.app.parameter.1=/usr/lib/csv2db/lib/Csv2Db.jar
>
> #********************************************************************
> # Wrapper Logging Properties
> #********************************************************************
> # Enables Debug output from the Wrapper.
> wrapper.debug=TRUE
>
> # Format of output for the console.  (See docs for formats) 
> wrapper.console.format=PM
>
> # Log Level for console output.  (See docs for log levels) 
> wrapper.console.loglevel=INFO
>
> # Log file to use for wrapper output logging.
> wrapper.logfile=../logs/wrapper.log
>
> # Format of output for the log file.  (See docs for formats) 
> wrapper.logfile.format=LPTM
>
> # Log Level for log file output.  (See docs for log levels) 
> wrapper.logfile.loglevel=DEBUG
>
> # 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 = 10 megabytes.
> wrapper.logfile.maxsize=0
>
> # 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=0
>
> # Log Level for sys/event log output.  (See docs for log levels) 
> wrapper.syslog.loglevel=NONE
>
> #********************************************************************
> # Wrapper General Properties
> #********************************************************************
> # Allow for the use of non-contiguous numbered properties 
> wrapper.ignore_sequence_gaps=TRUE
>
> # Title to use when running as a console 
> wra...@ap...@
>
> #********************************************************************
> # Wrapper JVM Checks
> #********************************************************************
> # Detect DeadLocked Threads in the JVM. (Requires Standard Edition) 
> wrapper.check.deadlock=TRUE wrapper.check.deadlock.interval=60
> wrapper.check.deadlock.action=RESTART
> wrapper.check.deadlock.output=FULL
>
> # Out Of Memory detection.
> # (Simple match)
> wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
> # (Only match text in stack traces if -XX:+PrintClassHistogram is 
> being
> used.)
> #wrapper.filter.trigger.1000=Exception in thread "*"
> java.lang.OutOfMemoryError
> #wrapper.filter.allow_wildcards.1000=TRUE
> wrapper.filter.action.1000=RESTART
> wrapper.filter.message.1000=The JVM has run out of memory.
>
> #********************************************************************
> # Wrapper Email Notifications. (Requires Professional Edition)
> #********************************************************************
> # Common Event Email settings.
> #wrapper.event.default.email.debug=TRUE
> #wrapper.event.default.email.smtp.host=<SMTP_Host>
> #wrapper.event.default.email.smtp.port=25
> #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME
> %:%WRAPPER_EVENT_NAME%]
> Event Notification
> #wrapper.event.default.email.sender=<Sender email> 
> #wrapper.event.default.email.recipient=<Recipient email>
>
> # Configure the log attached to event emails.
> #wrapper.event.default.email.attach_log=TRUE
> #wrapper.event.default.email.maillog.lines=50
> #wrapper.event.default.email.maillog.format=LPTM
> #wrapper.event.default.email.maillog.loglevel=INFO
>
> # Enable specific event emails.
> #wrapper.event.wrapper_start.email=TRUE
> #wrapper.event.jvm_prelaunch.email=TRUE
> #wrapper.event.jvm_start.email=TRUE
> #wrapper.event.jvm_started.email=TRUE
> #wrapper.event.jvm_deadlock.email=TRUE
> #wrapper.event.jvm_stop.email=TRUE
> #wrapper.event.jvm_stopped.email=TRUE
> #wrapper.event.jvm_restart.email=TRUE
> #wrapper.event.jvm_failed_invocation.email=TRUE
> #wrapper.event.jvm_max_failed_invocations.email=TRUE
> #wrapper.event.jvm_kill.email=TRUE
> #wrapper.event.jvm_killed.email=TRUE
> #wrapper.event.jvm_unexpected_exit.email=TRUE
> #wrapper.event.wrapper_stop.email=TRUE
>
> # Specify custom mail content
> wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease 
> check on its status.\n
>
> #********************************************************************
> # 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.
>
> # Name of the service
> wra...@ap...@
>
> # Display name of the service
> wra...@ap...@
>
> # Description of the service
> wra...@ap...@
>
> # Service dependencies.  Add dependencies as needed starting from 1 
> wrapper.ntservice.dependency.1=
>
> # Mode in which the service is installed.  AUTO_START, DELAY_START or 
> DEMAND_START wrapper.ntservice.starttype=AUTO_START
>
> # Allow the service to interact with the desktop.
> wrapper.ntservice.interactive=false
>
>
>
> Thanks in advance
>
> Koen
>
>
> ----------------------------------------------------------------------
> -------- EditLive Enterprise is the world's most technically advanced 
> content authoring tool. Experience the power of Track Changes, Inline 
> Image Editing and ensure content is compliant with Accessibility 
> Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] WrapperJarApp: Encountered an error running main..

[Dave G. <dav...@ma...>]

I think I would be inclined to amend the following

wrapper.java.classpath.1=/usr/lib/csv2db/lib/wrapper.jar
wrapper.java.classpath.2=/usr/lib/csv2db/lib/lib/eclipselink-javax.persistence-2.0.jar
wrapper.java.classpath.3=/usr/lib/csv2db/lib/lib/eclipselink-2.2.0.jar
wrapper.java.classpath.4=/usr/lib/csv2db/lib/lib/mysql-connector-java-5.1.13-bin.jar
wrapper.java.classpath.5=/usr/lib/csv2db/lib/lib/jpathwatch-0-94.jar
wrapper.java.classpath.6=/usr/lib/csv2db/lib/lib/opencsv-2.2.jar

change to

wrapper.java.classpath.1=./usr/lib/csv2db/lib/wrapper.jar
wrapper.java.classpath.2=./usr/lib/csv2db/lib/lib/eclipselink-javax.persistence-2.0.jar
wrapper.java.classpath.3=./usr/lib/csv2db/lib/lib/eclipselink-2.2.0.jar
wrapper.java.classpath.4=./usr/lib/csv2db/lib/lib/mysql-connector-java-5.1.13-bin.jar
wrapper.java.classpath.5=./usr/lib/csv2db/lib/lib/jpathwatch-0-94.jar
wrapper.java.classpath.6=./usr/lib/csv2db/lib/lib/opencsv-2.2.jar

On 10/06/2011 08:45, Koen Stoop wrote:
> Hi all,
> I wrote a Java Application using Netbeans 7.0 IDE.
> The application monitors a folder for the deletion of a lockfile.
> When this happens the app starts processing by reading a csv-file in 
> the monitored folder, and writing the file to a MySQL database using 
> Persistence JPA 2.0
> This is how the {WRAPPER_HOME} folder looks like:
> <bin>
>      csv2db
>      wrapper
> <lib>
>       Csv2Db.jar
>       libwrapper.so
>       wrapper.jar
> <lib>
>            eclipselink-2.2.0.jar
>            eclipselink-javax.persistence-2.0.jar
>            jpathwatch-0-94.jar
>            mysql-connector-java-5.1.13-bin.jar
>            opencsv-2.2.jar
> <logs>
>    wrapper.log
> <conf>
>     wrapper.conf
> when i run the program from the <lib> folder like: "java -jar Csv2Db" 
> all is working like it should be.
> I can start/stop it as a daemon using WrapperJarApp (Method 4) but 
> when the application starts processing the csv-file it gives the 
> following error:
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error: 
> Encountered an error running main:
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error: 
> javax.persistence.PersistenceException: No Persistence provider for 
> EntityManager named Csv2DbPU
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> csv2db.Csv2Db.main(Csv2Db.java:150)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> java.lang.reflect.Method.invoke(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> org.tanukisoftware.wrapper.WrapperJarApp.run(WrapperJarApp.java:385)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at 
> java.lang.Thread.run(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: 
> WrapperManager.stop(1) called by thread: WrapperJarAppMain
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: Send a 
> packet STOP : 1
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: 
> Stopped checking for control events.
> DEBUG  | wrapperp | 2011/06/10 08:30:04 | read a packet STOP : 1
> DEBUG  | wrapper  | 2011/06/10 08:30:04 | JVM requested a shutdown. (1)
> DEBUG  | wrapper  | 2011/06/10 08:30:04 | wrapperStopProcess(1, FALSE) 
> called.
> DEBUG  | wrapper  | 2011/06/10 08:30:04 | Sending stop signal to JVM
> It seems the wrapper can't find the library "eclipselink-2.2.0.jar" 
> but he can find the library "jpathwatch-0-94.jar" !?
> What is going wrong ? How can i troubleshoot this ?
> Here's my wrapper.conf:
> ===============================================
> #encoding=UTF-8
> # Configuration files must begin with a line specifying the encoding
> #  of the the file.
> #********************************************************************
> # Wrapper License Properties (Ignored by Community Edition)
> #********************************************************************
> # Professional and Standard Editions of the Wrapper require a valid
> #  License Key to start.  Licenses can be purchased or a trial license
> #  requested on the following pages:
> # http://wrapper.tanukisoftware.com/purchase
> # http://wrapper.tanukisoftware.com/trial
> # Include file problems can be debugged by removing the first '#'
> #  from the following line:
> #include.debug
> # The Wrapper will look for either of the following optional files for a
> #  valid License Key.  License Key properties can optionally be included
> #  directly in this configuration file.
> #include ../conf/wrapper-license.conf
> #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
> # The following property will output information about which License 
> Key(s)
> #  are being found, and can aid in resolving any licensing problems.
> #wrapper.license.debug=TRUE
> #********************************************************************
> # Wrapper Localization
> #********************************************************************
> # Specify the locale which the Wrapper should use.  By default the system
> #  locale is used.
> #wrapper.lang=en_US # en_US or ja_JP
> # Specify the location of the Wrapper's language resources.  If these are
> #  missing, the Wrapper will default to the en_US locale.
> wrapper.lang.folder=../lang
> #********************************************************************
> # Wrapper Java Properties
> #********************************************************************
> # Java Application
> #  Locate the java binary on the system PATH:
> wrapper.java.command=java
> #  Specify a specific java binary:
> #set.JAVA_HOME=/java/path
> #wrapper.java.command=%JAVA_HOME%/bin/java
> # Tell the Wrapper to log the full generated Java command line.
> wrapper.java.command.loglevel=DEBUG
> # 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=org.tanukisoftware.wrapper.WrapperJarApp
> # Java Classpath (include wrapper.jar)  Add class path elements as
> #  needed starting from 1
> wrapper.java.classpath.1=/usr/lib/csv2db/lib/wrapper.jar
> wrapper.java.classpath.2=/usr/lib/csv2db/lib/lib/eclipselink-javax.persistence-2.0.jar
> wrapper.java.classpath.3=/usr/lib/csv2db/lib/lib/eclipselink-2.2.0.jar
> wrapper.java.classpath.4=/usr/lib/csv2db/lib/lib/mysql-connector-java-5.1.13-bin.jar
> wrapper.java.classpath.5=/usr/lib/csv2db/lib/lib/jpathwatch-0-94.jar
> wrapper.java.classpath.6=/usr/lib/csv2db/lib/lib/opencsv-2.2.jar
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=/usr/lib/csv2db/lib
> # Java Bits.  On applicable platforms, tells the JVM to run in 32 or 
> 64-bit mode.
> wrapper.java.additional.auto_bits=TRUE
> # Java Additional Parameters
> wrapper.java.additional.1=
> # Initial Java Heap Size (in MB)
> #wrapper.java.initmemory=3
> # Maximum Java Heap Size (in MB)
> #wrapper.java.maxmemory=64
> # Application parameters.  Add parameters as needed starting from 1
> wrapper.app.parameter.1=/usr/lib/csv2db/lib/Csv2Db.jar
> #********************************************************************
> # Wrapper Logging Properties
> #********************************************************************
> # Enables Debug output from the Wrapper.
> wrapper.debug=TRUE
> # Format of output for the console.  (See docs for formats)
> wrapper.console.format=PM
> # Log Level for console output.  (See docs for log levels)
> wrapper.console.loglevel=INFO
> # Log file to use for wrapper output logging.
> wrapper.logfile=../logs/wrapper.log
> # Format of output for the log file.  (See docs for formats)
> wrapper.logfile.format=LPTM
> # Log Level for log file output.  (See docs for log levels)
> wrapper.logfile.loglevel=DEBUG
> # 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 = 10 megabytes.
> wrapper.logfile.maxsize=0
> # 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=0
> # Log Level for sys/event log output.  (See docs for log levels)
> wrapper.syslog.loglevel=NONE
> #********************************************************************
> # Wrapper General Properties
> #********************************************************************
> # Allow for the use of non-contiguous numbered properties
> wrapper.ignore_sequence_gaps=TRUE
> # Title to use when running as a console
> wra...@ap... 
> <mailto:wra...@ap...>@
> #********************************************************************
> # Wrapper JVM Checks
> #********************************************************************
> # Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
> wrapper.check.deadlock=TRUE
> wrapper.check.deadlock.interval=60
> wrapper.check.deadlock.action=RESTART
> wrapper.check.deadlock.output=FULL
> # Out Of Memory detection.
> # (Simple match)
> wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
> # (Only match text in stack traces if -XX:+PrintClassHistogram is 
> being used.)
> #wrapper.filter.trigger.1000=Exception in thread "*" 
> java.lang.OutOfMemoryError
> #wrapper.filter.allow_wildcards.1000=TRUE
> wrapper.filter.action.1000=RESTART
> wrapper.filter.message.1000=The JVM has run out of memory.
> #********************************************************************
> # Wrapper Email Notifications. (Requires Professional Edition)
> #********************************************************************
> # Common Event Email settings.
> #wrapper.event.default.email.debug=TRUE
> #wrapper.event.default.email.smtp.host=<SMTP_Host>
> #wrapper.event.default.email.smtp.port=25
> #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%] 
> Event Notification
> #wrapper.event.default.email.sender=<Sender email>
> #wrapper.event.default.email.recipient=<Recipient email>
> # Configure the log attached to event emails.
> #wrapper.event.default.email.attach_log=TRUE
> #wrapper.event.default.email.maillog.lines=50
> #wrapper.event.default.email.maillog.format=LPTM
> #wrapper.event.default.email.maillog.loglevel=INFO
> # Enable specific event emails.
> #wrapper.event.wrapper_start.email=TRUE
> #wrapper.event.jvm_prelaunch.email=TRUE
> #wrapper.event.jvm_start.email=TRUE
> #wrapper.event.jvm_started.email=TRUE
> #wrapper.event.jvm_deadlock.email=TRUE
> #wrapper.event.jvm_stop.email=TRUE
> #wrapper.event.jvm_stopped.email=TRUE
> #wrapper.event.jvm_restart.email=TRUE
> #wrapper.event.jvm_failed_invocation.email=TRUE
> #wrapper.event.jvm_max_failed_invocations.email=TRUE
> #wrapper.event.jvm_kill.email=TRUE
> #wrapper.event.jvm_killed.email=TRUE
> #wrapper.event.jvm_unexpected_exit.email=TRUE
> #wrapper.event.wrapper_stop.email=TRUE
> # Specify custom mail content
> wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease 
> check on its status.\n
> #********************************************************************
> # 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.
> # Name of the service
> wra...@ap... <mailto:wra...@ap...>@
> # Display name of the service
> wra...@ap... 
> <mailto:wra...@ap...>@
> # Description of the service
> wra...@ap... 
> <mailto:wra...@ap...>@
> # Service dependencies.  Add dependencies as needed starting from 1
> wrapper.ntservice.dependency.1=
> # Mode in which the service is installed.  AUTO_START, DELAY_START or 
> DEMAND_START
> wrapper.ntservice.starttype=AUTO_START
> # Allow the service to interact with the desktop.
> wrapper.ntservice.interactive=false
>
> Thanks in advance
>
> Koen
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
>
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] WrapperJarApp: Encountered an error running main..

[Christian M. <chr...@ta...>]

Koen,

Can you try the following:
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../lib/Csv2Db.jar
wrapper.java.classpath.3=../lib/lib/*.jar

Adding your jar to the class path should already fix your problem.
(I use a wildcard for the other jars just to make it a little bit more
easy to handle the classpath)

The Classloader handling in your application is slightly different
when running with the WrapperJarApp.
You might need to get a little bit changed to actually use:
<Your Class>.class.getClassLoader().

instead of the static way with ClassLoader...

Changing the handling to that way, you wouldn't need to define
Csv2Db.jar in the classpath...

Please let me know if you have any further questions.

Best Regards,
Christian

On Fri, Jun 10, 2011 at 4:45 PM, Koen Stoop <koe...@go...> wrote:
> Hi all,
>
> I wrote a Java Application using Netbeans 7.0 IDE.
> The application monitors a folder for the deletion of a lockfile.
> When this happens the app starts processing by reading a csv-file in the
> monitored folder, and writing the file to a MySQL database using Persistence
> JPA 2.0
>
> This is how the {WRAPPER_HOME} folder looks like:
> <bin>
>      csv2db
>      wrapper
> <lib>
>       Csv2Db.jar
>       libwrapper.so
>       wrapper.jar
>       <lib>
>            eclipselink-2.2.0.jar
>            eclipselink-javax.persistence-2.0.jar
>            jpathwatch-0-94.jar
>            mysql-connector-java-5.1.13-bin.jar
>            opencsv-2.2.jar
> <logs>
>    wrapper.log
> <conf>
>     wrapper.conf
>
> when i run the program from the <lib> folder like: "java -jar Csv2Db" all is
> working like it should be.
>
> I can start/stop it as a daemon using WrapperJarApp (Method 4) but when the
> application starts processing the csv-file it gives the following error:
>
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error: Encountered
> an error running main:
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:
> javax.persistence.PersistenceException: No Persistence provider for
> EntityManager named Csv2DbPU
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> csv2db.Csv2Db.main(Csv2Db.java:150)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> java.lang.reflect.Method.invoke(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> org.tanukisoftware.wrapper.WrapperJarApp.run(WrapperJarApp.java:385)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
> java.lang.Thread.run(Unknown Source)
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug:
> WrapperManager.stop(1) called by thread: WrapperJarAppMain
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: Send a
> packet STOP : 1
> INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: Stopped
> checking for control events.
> DEBUG  | wrapperp | 2011/06/10 08:30:04 | read a packet STOP : 1
> DEBUG  | wrapper  | 2011/06/10 08:30:04 | JVM requested a shutdown. (1)
> DEBUG  | wrapper  | 2011/06/10 08:30:04 | wrapperStopProcess(1, FALSE)
> called.
> DEBUG  | wrapper  | 2011/06/10 08:30:04 | Sending stop signal to JVM
>
> It seems the wrapper can't find the library "eclipselink-2.2.0.jar" but he
> can find the library "jpathwatch-0-94.jar" !?
> What is going wrong ? How can i troubleshoot this ?
>
> Here's my wrapper.conf:
> ===============================================
> #encoding=UTF-8
> # Configuration files must begin with a line specifying the encoding
> #  of the the file.
>
> #********************************************************************
> # Wrapper License Properties (Ignored by Community Edition)
> #********************************************************************
> # Professional and Standard Editions of the Wrapper require a valid
> #  License Key to start.  Licenses can be purchased or a trial license
> #  requested on the following pages:
> # http://wrapper.tanukisoftware.com/purchase
> # http://wrapper.tanukisoftware.com/trial
>
> # Include file problems can be debugged by removing the first '#'
> #  from the following line:
> #include.debug
>
> # The Wrapper will look for either of the following optional files for a
> #  valid License Key.  License Key properties can optionally be included
> #  directly in this configuration file.
> #include ../conf/wrapper-license.conf
> #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
>
> # The following property will output information about which License Key(s)
> #  are being found, and can aid in resolving any licensing problems.
> #wrapper.license.debug=TRUE
>
> #********************************************************************
> # Wrapper Localization
> #********************************************************************
> # Specify the locale which the Wrapper should use.  By default the system
> #  locale is used.
> #wrapper.lang=en_US # en_US or ja_JP
>
> # Specify the location of the Wrapper's language resources.  If these are
> #  missing, the Wrapper will default to the en_US locale.
> wrapper.lang.folder=../lang
>
> #********************************************************************
> # Wrapper Java Properties
> #********************************************************************
> # Java Application
> #  Locate the java binary on the system PATH:
> wrapper.java.command=java
> #  Specify a specific java binary:
> #set.JAVA_HOME=/java/path
> #wrapper.java.command=%JAVA_HOME%/bin/java
>
> # Tell the Wrapper to log the full generated Java command line.
> wrapper.java.command.loglevel=DEBUG
>
> # 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=org.tanukisoftware.wrapper.WrapperJarApp
>
> # Java Classpath (include wrapper.jar)  Add class path elements as
> #  needed starting from 1
> wrapper.java.classpath.1=/usr/lib/csv2db/lib/wrapper.jar
> wrapper.java.classpath.2=/usr/lib/csv2db/lib/lib/eclipselink-javax.persistence-2.0.jar
> wrapper.java.classpath.3=/usr/lib/csv2db/lib/lib/eclipselink-2.2.0.jar
> wrapper.java.classpath.4=/usr/lib/csv2db/lib/lib/mysql-connector-java-5.1.13-bin.jar
> wrapper.java.classpath.5=/usr/lib/csv2db/lib/lib/jpathwatch-0-94.jar
> wrapper.java.classpath.6=/usr/lib/csv2db/lib/lib/opencsv-2.2.jar
>
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=/usr/lib/csv2db/lib
>
> # Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit
> mode.
> wrapper.java.additional.auto_bits=TRUE
>
> # Java Additional Parameters
> wrapper.java.additional.1=
>
> # Initial Java Heap Size (in MB)
> #wrapper.java.initmemory=3
>
> # Maximum Java Heap Size (in MB)
> #wrapper.java.maxmemory=64
>
> # Application parameters.  Add parameters as needed starting from 1
> wrapper.app.parameter.1=/usr/lib/csv2db/lib/Csv2Db.jar
>
> #********************************************************************
> # Wrapper Logging Properties
> #********************************************************************
> # Enables Debug output from the Wrapper.
> wrapper.debug=TRUE
>
> # Format of output for the console.  (See docs for formats)
> wrapper.console.format=PM
>
> # Log Level for console output.  (See docs for log levels)
> wrapper.console.loglevel=INFO
>
> # Log file to use for wrapper output logging.
> wrapper.logfile=../logs/wrapper.log
>
> # Format of output for the log file.  (See docs for formats)
> wrapper.logfile.format=LPTM
>
> # Log Level for log file output.  (See docs for log levels)
> wrapper.logfile.loglevel=DEBUG
>
> # 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 = 10 megabytes.
> wrapper.logfile.maxsize=0
>
> # 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=0
>
> # Log Level for sys/event log output.  (See docs for log levels)
> wrapper.syslog.loglevel=NONE
>
> #********************************************************************
> # Wrapper General Properties
> #********************************************************************
> # Allow for the use of non-contiguous numbered properties
> wrapper.ignore_sequence_gaps=TRUE
>
> # Title to use when running as a console
> wra...@ap...@
>
> #********************************************************************
> # Wrapper JVM Checks
> #********************************************************************
> # Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
> wrapper.check.deadlock=TRUE
> wrapper.check.deadlock.interval=60
> wrapper.check.deadlock.action=RESTART
> wrapper.check.deadlock.output=FULL
>
> # Out Of Memory detection.
> # (Simple match)
> wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
> # (Only match text in stack traces if -XX:+PrintClassHistogram is being
> used.)
> #wrapper.filter.trigger.1000=Exception in thread "*"
> java.lang.OutOfMemoryError
> #wrapper.filter.allow_wildcards.1000=TRUE
> wrapper.filter.action.1000=RESTART
> wrapper.filter.message.1000=The JVM has run out of memory.
>
> #********************************************************************
> # Wrapper Email Notifications. (Requires Professional Edition)
> #********************************************************************
> # Common Event Email settings.
> #wrapper.event.default.email.debug=TRUE
> #wrapper.event.default.email.smtp.host=<SMTP_Host>
> #wrapper.event.default.email.smtp.port=25
> #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
> Event Notification
> #wrapper.event.default.email.sender=<Sender email>
> #wrapper.event.default.email.recipient=<Recipient email>
>
> # Configure the log attached to event emails.
> #wrapper.event.default.email.attach_log=TRUE
> #wrapper.event.default.email.maillog.lines=50
> #wrapper.event.default.email.maillog.format=LPTM
> #wrapper.event.default.email.maillog.loglevel=INFO
>
> # Enable specific event emails.
> #wrapper.event.wrapper_start.email=TRUE
> #wrapper.event.jvm_prelaunch.email=TRUE
> #wrapper.event.jvm_start.email=TRUE
> #wrapper.event.jvm_started.email=TRUE
> #wrapper.event.jvm_deadlock.email=TRUE
> #wrapper.event.jvm_stop.email=TRUE
> #wrapper.event.jvm_stopped.email=TRUE
> #wrapper.event.jvm_restart.email=TRUE
> #wrapper.event.jvm_failed_invocation.email=TRUE
> #wrapper.event.jvm_max_failed_invocations.email=TRUE
> #wrapper.event.jvm_kill.email=TRUE
> #wrapper.event.jvm_killed.email=TRUE
> #wrapper.event.jvm_unexpected_exit.email=TRUE
> #wrapper.event.wrapper_stop.email=TRUE
>
> # Specify custom mail content
> wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease check
> on its status.\n
>
> #********************************************************************
> # 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.
>
> # Name of the service
> wra...@ap...@
>
> # Display name of the service
> wra...@ap...@
>
> # Description of the service
> wra...@ap...@
>
> # Service dependencies.  Add dependencies as needed starting from 1
> wrapper.ntservice.dependency.1=
>
> # Mode in which the service is installed.  AUTO_START, DELAY_START or
> DEMAND_START
> wrapper.ntservice.starttype=AUTO_START
>
> # Allow the service to interact with the desktop.
> wrapper.ntservice.interactive=false
>
>
>
> Thanks in advance
>
> Koen
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] WrapperJarApp: Encountered an error running main..

[Koen S. <koe...@go...>]

Hi all,
 
I wrote a Java Application using Netbeans 7.0 IDE.
The application monitors a folder for the deletion of a lockfile.
When this happens the app starts processing by reading a csv-file in the
monitored folder, and writing the file to a MySQL database using
Persistence JPA 2.0
 
This is how the {WRAPPER_HOME} folder looks like:
<bin>
     csv2db
     wrapper
<lib>
      Csv2Db.jar
      libwrapper.so
      wrapper.jar
      <lib>
           eclipselink-2.2.0.jar
           eclipselink-javax.persistence-2.0.jar
           jpathwatch-0-94.jar
           mysql-connector-java-5.1.13-bin.jar
           opencsv-2.2.jar
<logs>
   wrapper.log
<conf>
    wrapper.conf
 
when i run the program from the <lib> folder like: "java -jar Csv2Db"
all is working like it should be.
 
I can start/stop it as a daemon using WrapperJarApp (Method 4) but when
the application starts processing the csv-file it gives the following
error:
 
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:
Encountered an error running main:
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:
javax.persistence.PersistenceException: No Persistence provider for
EntityManager named Csv2DbPU
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
csv2db.Csv2Db.main(Csv2Db.java:150)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
java.lang.reflect.Method.invoke(Unknown Source)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
org.tanukisoftware.wrapper.WrapperJarApp.run(WrapperJarApp.java:385)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperJarApp Error:  at
java.lang.Thread.run(Unknown Source)
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug:
WrapperManager.stop(1) called by thread: WrapperJarAppMain
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: Send a
packet STOP : 1
INFO   | jvm 1    | 2011/06/10 08:30:04 | WrapperManager Debug: Stopped
checking for control events.
DEBUG  | wrapperp | 2011/06/10 08:30:04 | read a packet STOP : 1
DEBUG  | wrapper  | 2011/06/10 08:30:04 | JVM requested a shutdown. (1)
DEBUG  | wrapper  | 2011/06/10 08:30:04 | wrapperStopProcess(1, FALSE)
called.
DEBUG  | wrapper  | 2011/06/10 08:30:04 | Sending stop signal to JVM
 
It seems the wrapper can't find the library "eclipselink-2.2.0.jar" but
he can find the library "jpathwatch-0-94.jar" !?
What is going wrong ? How can i troubleshoot this ?
 
Here's my wrapper.conf:
===============================================
#encoding=UTF-8
# Configuration files must begin with a line specifying the encoding
#  of the the file.
 
#********************************************************************
# Wrapper License Properties (Ignored by Community Edition)
#********************************************************************
# Professional and Standard Editions of the Wrapper require a valid
#  License Key to start.  Licenses can be purchased or a trial license
#  requested on the following pages:
# http://wrapper.tanukisoftware.com/purchase
# http://wrapper.tanukisoftware.com/trial
 
# Include file problems can be debugged by removing the first '#'
#  from the following line:
#include.debug
 
# The Wrapper will look for either of the following optional files for a
#  valid License Key.  License Key properties can optionally be included
#  directly in this configuration file.
#include ../conf/wrapper-license.conf
#include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
 
# The following property will output information about which License
Key(s)
#  are being found, and can aid in resolving any licensing problems.
#wrapper.license.debug=TRUE
 
#********************************************************************
# Wrapper Localization
#********************************************************************
# Specify the locale which the Wrapper should use.  By default the
system
#  locale is used.
#wrapper.lang=en_US # en_US or ja_JP
 
# Specify the location of the Wrapper's language resources.  If these
are
#  missing, the Wrapper will default to the en_US locale.
wrapper.lang.folder=../lang
 
#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
#  Locate the java binary on the system PATH:
wrapper.java.command=java
#  Specify a specific java binary:
#set.JAVA_HOME=/java/path
#wrapper.java.command=%JAVA_HOME%/bin/java
 
# Tell the Wrapper to log the full generated Java command line.
wrapper.java.command.loglevel=DEBUG
 
# 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=org.tanukisoftware.wrapper.WrapperJarApp
 
# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=/usr/lib/csv2db/lib/wrapper.jar
wrapper.java.classpath.2=/usr/lib/csv2db/lib/lib/eclipselink-javax.persi
stence-2.0.jar
wrapper.java.classpath.3=/usr/lib/csv2db/lib/lib/eclipselink-2.2.0.jar
wrapper.java.classpath.4=/usr/lib/csv2db/lib/lib/mysql-connector-java-5.
1.13-bin.jar
wrapper.java.classpath.5=/usr/lib/csv2db/lib/lib/jpathwatch-0-94.jar
wrapper.java.classpath.6=/usr/lib/csv2db/lib/lib/opencsv-2.2.jar
 
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=/usr/lib/csv2db/lib
 
# Java Bits.  On applicable platforms, tells the JVM to run in 32 or
64-bit mode.
wrapper.java.additional.auto_bits=TRUE
 
# Java Additional Parameters
wrapper.java.additional.1=
 
# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=3
 
# Maximum Java Heap Size (in MB)
#wrapper.java.maxmemory=64
 
# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=/usr/lib/csv2db/lib/Csv2Db.jar
 
#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
wrapper.debug=TRUE
 
# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM
 
# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO
 
# Log file to use for wrapper output logging.
wrapper.logfile=../logs/wrapper.log
 
# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM
 
# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=DEBUG
 
# 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 = 10 megabytes.
wrapper.logfile.maxsize=0
 
# 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=0
 
# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=NONE
 
#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
wrapper.ignore_sequence_gaps=TRUE
 
# Title to use when running as a console
wra...@ap...@
 
#********************************************************************
# Wrapper JVM Checks
#********************************************************************
# Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
wrapper.check.deadlock=TRUE
wrapper.check.deadlock.interval=60
wrapper.check.deadlock.action=RESTART
wrapper.check.deadlock.output=FULL
 
# Out Of Memory detection.
# (Simple match)
wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
# (Only match text in stack traces if -XX:+PrintClassHistogram is being
used.)
#wrapper.filter.trigger.1000=Exception in thread "*"
java.lang.OutOfMemoryError
#wrapper.filter.allow_wildcards.1000=TRUE
wrapper.filter.action.1000=RESTART
wrapper.filter.message.1000=The JVM has run out of memory.
 
#********************************************************************
# Wrapper Email Notifications. (Requires Professional Edition)
#********************************************************************
# Common Event Email settings.
#wrapper.event.default.email.debug=TRUE
#wrapper.event.default.email.smtp.host=<SMTP_Host>
#wrapper.event.default.email.smtp.port=25
#wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:
%WRAPPER_EVENT_NAME%] Event Notification
#wrapper.event.default.email.sender=<Sender email>
#wrapper.event.default.email.recipient=<Recipient email>
 
# Configure the log attached to event emails.
#wrapper.event.default.email.attach_log=TRUE
#wrapper.event.default.email.maillog.lines=50
#wrapper.event.default.email.maillog.format=LPTM
#wrapper.event.default.email.maillog.loglevel=INFO
 
# Enable specific event emails.
#wrapper.event.wrapper_start.email=TRUE
#wrapper.event.jvm_prelaunch.email=TRUE
#wrapper.event.jvm_start.email=TRUE
#wrapper.event.jvm_started.email=TRUE
#wrapper.event.jvm_deadlock.email=TRUE
#wrapper.event.jvm_stop.email=TRUE
#wrapper.event.jvm_stopped.email=TRUE
#wrapper.event.jvm_restart.email=TRUE
#wrapper.event.jvm_failed_invocation.email=TRUE
#wrapper.event.jvm_max_failed_invocations.email=TRUE
#wrapper.event.jvm_kill.email=TRUE
#wrapper.event.jvm_killed.email=TRUE
#wrapper.event.jvm_unexpected_exit.email=TRUE
#wrapper.event.wrapper_stop.email=TRUE
 
# Specify custom mail content
wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease
check on its status.\n
 
#********************************************************************
# 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.
 
# Name of the service
wra...@ap...@
 
# Display name of the service
wra...@ap...@
 
# Description of the service
wra...@ap...@
 
# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=
 
# Mode in which the service is installed.  AUTO_START, DELAY_START or
DEMAND_START
wrapper.ntservice.starttype=AUTO_START
 
# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false
 
 

Thanks in advance

Koen

 

Re: [Wrapper-user] Can you help me, please ?

[Christian M. <chr...@ta...>]

Francesco,

thank you for your interest in the Java Service Wrapper.

Basically you will need the following properties in your conf file:

# From you command line it seems, you will need Integration Method #1
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# because of the signal handler of javaw, it is not very recommendable
for running of as service...
wrapper.java.command=java

# given all you jar files are in the lib directory, you can easily
include all of the by the following line:
wrapper.java.classpath.1=../lib/*.jar

wrapper.java.additional=-DFAXSHELL
wrapper.app.parameter=ssc.assilt.batch.fax.FaxShell

Please make sure to check out the integration documentation:
http://wrapper.tanukisoftware.com/doc/english/integrate-simple-win.html

Hope this helps you out.

Cheers
Christian


On Tue, May 31, 2011 at 7:34 PM, Francesco Dacquì <fc...@ho...> wrote:
> i have this batch   x.bat,
>
> in this script are this command
>
> javaw -DFAXSHELL -classpath
> "lib/faxshell.jar;lib/ojdbc14_10g.jar;lib/log4j-1.2.14.jar;lib/axis2-adb-1.4.1.jar;lib/axis2-jaxws-1.4.1.jar;lib/axis2-jaxws-api-1.4.1.jar;lib/axis2-kernel-1.4.1.jar;lib/axis2-xmlbeans-1.4.1.jar;lib/axiom-api-1.2.7.jar;lib/axiom-impl-1.2.7.jar;lib/wsdl4j-1.6.2.jar;lib/XmlSchema-1.4.2.jar;lib/commons-logging-1.0.4.jar;lib/backport-util-concurrent-3.1.jar;lib/neethi-2.0.4.jar;lib/commons-httpclient-3.1.jar;lib/commons-codec-1.3.jar;lib/commons-beanutils.jar;lib/assilt.jar"
> ssc.assilt.batch.fax.FaxShell
>
>
> now, i would create a service with the wrapper...   somebody can help me
> please ?
>
> (with wrapper.conf.. and witch method use to run this batch...)
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>