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

[Wrapper-user] Java Service Wrapper 3.5.44 released!

[Maxime <ma...@ta...>]

Hello everyone,

We are proud to announce the release of version 3.5.44 of the Java Service
Wrapper.
http://wrapper.tanukisoftware.org/doc/english/download.jsp

Most noticeable changes for this version are:
- a new signed and notarized package distribution for macOS.
- important fixes and improvements when installing and authenticating
Windows Services upon specific accounts.

It includes several other bug fixes and improvements, which you can review
in the release notes.
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Please let us know if you have any questions about the release.

Sincerely,

Java Service Wrapper Team
Tanuki Software, Ltd.
6-18-10-4F Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com

Re: [Wrapper-user] Wrapper.exe crashes without any notification

[Subhranil S. <sus...@at...>]

Ok sure.

From: Leif Mortenson <le...@ta...>
Sent: Wednesday, June 17, 2020 1:07 PM
To: Subhranil Sengupta <sus...@at...>
Cc: Wrapper User List <wra...@li...>
Subject: Re: [Wrapper-user] Wrapper.exe crashes without any notification

Subhranil
This is being asked in two places.  Will answer in the other thread.

Cheers,
Leif

On Wed, Jun 17, 2020 at 3:55 PM Subhranil Sengupta <sus...@at...<mailto:sus...@at...>> wrote:
Hi Leif,

We have plans to upgrade the wrapper service further in future releases. But for now we are using Version 3.2.1.

Can you kindly give a look at the wrapper.conf and wrapper.log and help me with the root cause or the resolution.

Your inputs will be very much appreciated.

Thanks
Subhranil Sengupta

From: Leif Mortenson <le...@ta...<mailto:le...@ta...>>
Sent: Wednesday, June 17, 2020 9:08 AM
To: Wrapper User List <wra...@li...<mailto:wra...@li...>>
Cc: Subhranil Sengupta <sus...@at...<mailto:sus...@at...>>
Subject: Re: [Wrapper-user] Wrapper.exe crashes without any notification

Dear Subhranil Sengupta

Thank you for contacting us.

Version 3.2.1 of the Wrapper is very old and contains a lot of issues that we fixed over the years.
If the Wrapper is crashing, there is a great chance it was fixed on a later version.

I would first recommend using the latest version of the Wrapper which can be downloaded from our website:
https://wrapper.tanukisoftware.com/doc/english/download.jsp

If the problem persists, please check the Event log to see if you have any error there.

Since version 3.5.42, we added a property to monitor unexpected terminations of the Wrapper process or Java application. This feature helps finding the cause even when no notification could be logged in the Wrapper log file.

Please check the following page for details:
https://wrapper.tanukisoftware.com/doc/english/props-monitor-exit.html

Please let me know if you have any questions.

Best Regards,
Leif

On Tue, Jun 16, 2020 at 9:11 PM Subhranil Sengupta via Wrapper-user <wra...@li...<mailto:wra...@li...>> wrote:
Hi Team,

The wrapper version we are using  is version = 3.2.1.
The OS details:  Microsoft Windows Server 2008 R2 Enterprise 64-bit build 7601
The wrapper.conf  and wrapper.log is attached.

The issue being the wrapper service crashes without any notifications or logs in the wrapper.log.
I am also attaching the appcrash WER files.

As there are no logs or evidence in the log files, we are unable to find the root cause behind the crash and hence cannot reproduce it.

In server.log.wrapper.log.3 file , we can see that at “2020/06/13 09:40:57 " the wrapper stops responding but we do not see any shutdown notifications.
The service is restarted again and we can see the startup logs in the from “2020/06/13 10:30:17”.

Also by seeing the dumps files we know that the wrapper.exe did crash but the reason is unknown.
This isn’t a periodic or reproducible crash and hence we couldn’t get the logs in debug mode.

Kindly help us in knowing the root cause and a possible solution to this. And do let us know in case you any other logs.

Thank You
Subhranil Sengupta
Customer Success ACM India

[cid:image002.jpg@01D3B06A.CD1454C0]
6th floor, Innovator Building, ITPB,
Bengaluru, Karnataka 560066
c +91-7331127762

Re: [Wrapper-user] Wrapper.exe crashes without any notification

[Subhranil S. <sus...@at...>]

Hi Leif,

We have plans to upgrade the wrapper service further in future releases. But for now we are using Version 3.2.1.

Can you kindly give a look at the wrapper.conf and wrapper.log and help me with the root cause or the resolution.

Your inputs will be very much appreciated.

Thanks
Subhranil Sengupta

From: Leif Mortenson <le...@ta...>
Sent: Wednesday, June 17, 2020 9:08 AM
To: Wrapper User List <wra...@li...>
Cc: Subhranil Sengupta <sus...@at...>
Subject: Re: [Wrapper-user] Wrapper.exe crashes without any notification

Dear Subhranil Sengupta

Thank you for contacting us.

Version 3.2.1 of the Wrapper is very old and contains a lot of issues that we fixed over the years.
If the Wrapper is crashing, there is a great chance it was fixed on a later version.

I would first recommend using the latest version of the Wrapper which can be downloaded from our website:
https://wrapper.tanukisoftware.com/doc/english/download.jsp

If the problem persists, please check the Event log to see if you have any error there.

Since version 3.5.42, we added a property to monitor unexpected terminations of the Wrapper process or Java application. This feature helps finding the cause even when no notification could be logged in the Wrapper log file.

Please check the following page for details:
https://wrapper.tanukisoftware.com/doc/english/props-monitor-exit.html

Please let me know if you have any questions.

Best Regards,
Leif

On Tue, Jun 16, 2020 at 9:11 PM Subhranil Sengupta via Wrapper-user <wra...@li...<mailto:wra...@li...>> wrote:
Hi Team,

The wrapper version we are using  is version = 3.2.1.
The OS details:  Microsoft Windows Server 2008 R2 Enterprise 64-bit build 7601
The wrapper.conf  and wrapper.log is attached.

The issue being the wrapper service crashes without any notifications or logs in the wrapper.log.
I am also attaching the appcrash WER files.

As there are no logs or evidence in the log files, we are unable to find the root cause behind the crash and hence cannot reproduce it.

In server.log.wrapper.log.3 file , we can see that at “2020/06/13 09:40:57 " the wrapper stops responding but we do not see any shutdown notifications.
The service is restarted again and we can see the startup logs in the from “2020/06/13 10:30:17”.

Also by seeing the dumps files we know that the wrapper.exe did crash but the reason is unknown.
This isn’t a periodic or reproducible crash and hence we couldn’t get the logs in debug mode.

Kindly help us in knowing the root cause and a possible solution to this. And do let us know in case you any other logs.

Thank You
Subhranil Sengupta
Customer Success ACM India

[cid:image002.jpg@01D3B06A.CD1454C0]
6th floor, Innovator Building, ITPB,
Bengaluru, Karnataka 560066
c +91-7331127762

[Wrapper-user] Wrapper.exe crashes without any notification

[Subhranil S. <sus...@at...>]

Hi Team,

The wrapper version we are using  is version = 3.2.1.
The OS details:  Microsoft Windows Server 2008 R2 Enterprise 64-bit build 7601
The wrapper.conf  and wrapper.log is attached.

The issue being the wrapper service crashes without any notifications or logs in the wrapper.log.
I am also attaching the appcrash WER files.

As there are no logs or evidence in the log files, we are unable to find the root cause behind the crash and hence cannot reproduce it.

In server.log.wrapper.log.3 file , we can see that at "2020/06/13 09:40:57 " the wrapper stops responding but we do not see any shutdown notifications.
The service is restarted again and we can see the startup logs in the from "2020/06/13 10:30:17".

Also by seeing the dumps files we know that the wrapper.exe did crash but the reason is unknown.
This isn't a periodic or reproducible crash and hence we couldn't get the logs in debug mode.

Kindly help us in knowing the root cause and a possible solution to this. And do let us know in case you any other logs.

Thank You
Subhranil Sengupta
Customer Success ACM India

[cid:image002.jpg@01D3B06A.CD1454C0]
6th floor, Innovator Building, ITPB,
Bengaluru, Karnataka 560066
c +91-7331127762

[Wrapper-user] Java Service Wrapper 3.5.43 released!

[Maxime <ma...@ta...>]

Hello everyone,

We are proud to announce the release of version 3.5.43 of the Java Service
Wrapper.
http://wrapper.tanukisoftware.org/doc/english/download.jsp

This version includes several bug fixes and improvements. You can review
the release notes for a full list of changes.
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Please let us know if you have any questions about the release.

Sincerely,

Java Service Wrapper Team
Tanuki Software, Ltd.

Re: [Wrapper-user] Java Service Wrapper 3.5.42 released!

[M R. <rel...@gm...>]

Thanks maxine.,/ tanuki community
I had a question about the community edition licensing.
Is it still valid ?

wrapper.tanukisoftware.org/doc/english/licenseCommunity.html Closed Source
Use The GPL does not restrict private software from being developed for
internal use which depends on software under the GPL as long as that
software is never distributed without making the full source of the entire
application available to all users. While we encourage corporate and
government users to make use of either a Server or Development License
Agreement, the Community License Agreement is acceptable as long as the
application is for internal use or will be always be distributed along with
its full src.
. – Vladimir <https://stackoverflow.com/users/194116/vladimir> Dec 30 '09
at 16:56
<https://stackoverflow.com/questions/68113/how-to-create-a-windows-service-from-java-app#comment1896747_68140>


On Tue, Jan 28, 2020 at 1:18 AM Maxime <ma...@ta...> wrote:

> Hello everyone,
>
> We are proud to announce the release of version 3.5.42 of the Java Service
> Wrapper.
> http://wrapper.tanukisoftware.org/doc/english/download.jsp
>
> This release adds the ability to manage permissions of Windows Services -
> i.e allow users or groups to execute certain actions to control your
> service, without UAC prompt - (*Professional Edition*), handles the
> password of Windows Services more securely, adds new properties to monitor
> unexpected exits of the Java or Wrapper processes (*Standard Edition*),
> improves the way daemons are installed and removed using the tools
> available on the different Linux distributions, etc.
>
> It includes several other bug fixes and improvements, which you can review
> through our release notes.
> http://wrapper.tanukisoftware.org/doc/english/release-notes.html
>
> Please let us know if you have any questions about the release.
>
> Sincerely,
>
> Java Service Wrapper Team
> Tanuki Software, Ltd.
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Java Service Wrapper 3.5.42 released!

[Maxime <ma...@ta...>]

Hello everyone,

We are proud to announce the release of version 3.5.42 of the Java Service
Wrapper.
http://wrapper.tanukisoftware.org/doc/english/download.jsp

This release adds the ability to manage permissions of Windows Services -
i.e allow users or groups to execute certain actions to control your
service, without UAC prompt - (*Professional Edition*), handles the
password of Windows Services more securely, adds new properties to monitor
unexpected exits of the Java or Wrapper processes (*Standard Edition*),
improves the way daemons are installed and removed using the tools
available on the different Linux distributions, etc.

It includes several other bug fixes and improvements, which you can review
through our release notes.
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Please let us know if you have any questions about the release.

Sincerely,

Java Service Wrapper Team
Tanuki Software, Ltd.

Re: [Wrapper-user] Conditionally pass property to app based on mode of running

[Maxime <ma...@ta...>]

Dear Prashant Sharma

Version 3.5.41 of the Wrapper is now available. This new version sets a
'WRAPPER_RUN_MODE' variable on startup which takes the value 'console' or
'service' depending on which mode the Wrapper is running. This environment
variable can be referenced in the include path of a sub-configuration file
which contains properties that should only be used for a specific mode.

This should offer a more simple alternative than the solutions previously
listed.

Please let me know if you have any questions.

Best Regards,

Maxime

On Thu, Aug 1, 2019 at 7:39 PM Maxime <ma...@ta...> wrote:

> Dear Prashant Sharma
>
> Thank you for your mail.
>
> There are a few solutions to achieve this:
>
> 1) if you only have a few properties that you want to override when
> running as a console, then you may use command line properties
> <https://wrapper.tanukisoftware.com/doc/english/props-command-line.html>.
> When the Wrapper is launched as a Service, only the properties of the
> configuration file will be used.
>
> 2) you may also specify a completely different configuration file when
> launching the Wrapper as a console. For example: wrapper.exe -c
> ../wrapper-console.conf
>
> 3) if you are launching the Wrapper using the batch files, you edit
> StartApp-NT.bat.in and App.bat.in (or alternatively AppCommand.bat.in)
> and set an environment variable at the top of the files.
> For example:
> SET RUN_MODE=console
> SET  RUN_MODE =service
> Then, in your configuration file, you can add an include file which
> references the RUN_MODE variable in its path or filename.
> #include ../conf/wrapper-% RUN_MODE %.conf
>
> 4) finally you may set an environment variable ( RUN_MODE =console) for
> the current user (Control Panel > Edit the system environment variables),
> and then write the following in your configuration file:
> set.default. RUN_MODE =service
> This will work because the service runs on a different account than the
> current user, and thus RUN_MODE will not be defined. When the
> "set.default." property name is used, the environment variable will only
> be set if it does not exist yet (i.e when running as a service). Otherwise
> the value set for the current user will be used.
> Then you can include as 3)
> NOTE that if you have several local users who can run the Wrapper you
> should set the variable for each of them.
>
> On the next version of the Wrapper we will probably add a
> 'WRAPPER_RUN_MODE' variable which will automatically be set to 'console' or
> 'service' by the Wrapper. This should offer a more simple alternative to 3)
> and 4).
>
> Please let me know if you have any questions.
>
> Best Regards,
>
> Maxime
>
>
>
>
>
> On Thu, Aug 1, 2019 at 1:19 AM Prashant Sharma <pra...@gm...>
> wrote:
>
>> Is there some way to identify if my application was started in console
>> mode or as a service.
>> I want to achieve the below.
>>
>> if wrapper.exe -c
>>     pass profile=X property to myApp
>> if wrapper.exe -t
>>     pass profile=Y property to myApp
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>

[Wrapper-user] Java Service Wrapper 3.5.41 released!

[Maxime <ma...@ta...>]

 Hello everyone,

We are proud to announce the release of version 3.5.41 of the Java Service
Wrapper.
http://wrapper.tanukisoftware.org/doc/english/download.jsp

This version includes several bug fixes and improvements. You can review
the release notes for a full list of changes.
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Please let us know if you have any questions about the release.

Sincerely,

Java Service Wrapper Team
Tanuki Software, Ltd.

Re: [Wrapper-user] Conditionally pass property to app based on mode of running

[Maxime <ma...@ta...>]

Dear Prashant Sharma

Thank you for your mail.

There are a few solutions to achieve this:

1) if you only have a few properties that you want to override when running
as a console, then you may use command line properties
<https://wrapper.tanukisoftware.com/doc/english/props-command-line.html>.
When the Wrapper is launched as a Service, only the properties of the
configuration file will be used.

2) you may also specify a completely different configuration file when
launching the Wrapper as a console. For example: wrapper.exe -c
../wrapper-console.conf

3) if you are launching the Wrapper using the batch files, you edit
StartApp-NT.bat.in and App.bat.in (or alternatively AppCommand.bat.in) and
set an environment variable at the top of the files.
For example:
SET RUN_MODE=console
SET  RUN_MODE =service
Then, in your configuration file, you can add an include file which
references the RUN_MODE variable in its path or filename.
#include ../conf/wrapper-% RUN_MODE %.conf

4) finally you may set an environment variable ( RUN_MODE =console) for the
current user (Control Panel > Edit the system environment variables), and
then write the following in your configuration file:
set.default. RUN_MODE =service
This will work because the service runs on a different account than the
current user, and thus RUN_MODE will not be defined. When the "set.default."
property name is used, the environment variable will only be set if it does
not exist yet (i.e when running as a service). Otherwise the value set for
the current user will be used.
Then you can include as 3)
NOTE that if you have several local users who can run the Wrapper you
should set the variable for each of them.

On the next version of the Wrapper we will probably add a
'WRAPPER_RUN_MODE' variable which will automatically be set to 'console' or
'service' by the Wrapper. This should offer a more simple alternative to 3)
and 4).

Please let me know if you have any questions.

Best Regards,

Maxime





On Thu, Aug 1, 2019 at 1:19 AM Prashant Sharma <pra...@gm...>
wrote:

> Is there some way to identify if my application was started in console
> mode or as a service.
> I want to achieve the below.
>
> if wrapper.exe -c
>     pass profile=X property to myApp
> if wrapper.exe -t
>     pass profile=Y property to myApp
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Conditionally pass property to app based on mode of running

[Prashant S. <pra...@gm...>]

Is there some way to identify if my application was started in console mode
or as a service.
I want to achieve the below.

if wrapper.exe -c
    pass profile=X property to myApp
if wrapper.exe -t
    pass profile=Y property to myApp

Re: [Wrapper-user] Log4j2 integration

[Andrei <and...@ya...>]

 Hi Maxime,
"The Wrapper should print everything written by the JVM in stdout & stderr." -> That it's also what I expect. 

 "Please confirm that log4j is using the same streams."-> in the new Log4j 2.x version I use new classes: -  org.apache.logging.log4j.core.appender.RollingFileAppender.class instead of deprecated (removed) org.apache.log4j.DailyRollingFileAppender.class
 - org.apache.logging.log4j.core.config.builder.api.AppenderComponentBuilder.class instead of deprecated (removed) org.apache.log4j.ConsoleAppender.ConsoleAppender.class
"Do you mean that no log output are skipped? Did you notice other differences?"-> Yes, there are displayed all the logs. 
Br,
Andrei
    On Tuesday, July 30, 2019, 12:11:06 PM GMT+3, Maxime <ma...@ta...> wrote:  
 
 Andrei

Thank you for the explanation.

Regarding the logging of the JVM output, the Wrapper doesn't nothing more than printing standard output at the INFO loglevel, regardless the logging tool used along with your Java application.

"wrapper.app.parameter.5=log4j.level=debug => The output of the gateway_service_log4j2.log will be only the Info logs."
> this is normal. The Wrapper always prints the JVM output at the INFO loglevel, regardless the loglevel used by log4j. There is currently no configuration to change this behavior. The same should be observed with Log4j v. 1.2.

However it is not normal that you have some debug output skipped when using the Wrapper. The Wrapper should print everything written by the JVM in stdout & stderr. Please confirm that log4j is using the same streams.

"The logging with the Log4j 1.2 version working perfectly"
> Do you mean that no log output are skipped? Did you notice other differences?

Best Regards,

Maxime
On Tue, Jul 30, 2019 at 3:19 PM 'Andrei' via Support Group <sup...@ta...> wrote:

 Hi, 
Attached you will find  - the Tanuki wrapper configuration file named: wrapper.conf                                     - the log4j2 (Log4j 2 version) named: log4j2.xml

also I attached files: - gateway_service_log4j2.log with the output when I run the project locally (on my PC) in the Eclipse environment. So here (locally) works like a charm. Note that locally I don't use Tanuki wrapper.                                 - gateway_service_all.log with the output when I run project on the server (on the environment where my app is deployed). So I use the Tanuki wrapper as a tool to run my application on the server. 
 Story: 
- When I run my application locally (my PC) environment without the Tanuky wrapper configuration, the Logging is working perfectly with all the feature offered by Log4j 2 version (including Automatic Reconfiguration). - When I run my application on the server environment with the Tanuky wrapper configuration "wrapper.conf", the Logging not working OK. Note that inside the wrapper.conf I point to the Log4j2 config -> "wrapper.java.additional.1=-Dlog4j.configurationFile=.\log4j2.xml". 
- Here the problems appear after I activate the log4j2 configuration. Even if I set the logging level to DEBUG or to INFO inside the wrapper.conf -> wrapper.app.parameter.5=log4j.level=debug => The output of the gateway_service_log4j2.log will be only the Info logs. So it does not take in consideration the DEBUG level, or does not interpret correctly . More that this only some few of the Info logs are displayed. - The logs which is output by the Wrapper itself so the gateway_service_all.log seems that is working OK also on the server side environment.
- That is the reason why I asked if somebody managed to integrate Log4j 2 version with Tanuki Wrapper Note! The logging with the Log4j 1.2 version working perfectly and I have the same environment locally and on also same environment on server.

Info from the manifest of the Tanuki wrapper that I use: 
Manifest-Version: 1.0Ant-Version: Apache Ant 1.8.2Created-By: 1.4.2_19-b04 (Sun Microsystems Inc.)Built-By: chrisPackage: org.tanukisoftware.wrapperExtension-Name: wrapperSpecification-Title: Java Service WrapperSpecification-Vendor: Tanuki Software, Ltd.Specification-Version: 3.5.15Implementation-Title: org.tanukisoftware.wrapperImplementation-Vendor: Tanuki Software, Ltd.Implementation-Version: 3.5.15

P.S. if someone has an example how he used the Log4j2 with the Tanuki wrapper please let me know. Also some documentation how to integrate Wrapper with Log4j2 will help.
Thanks in advance! 
Andrei 



    On Friday, July 26, 2019, 09:57:40 AM GMT+1, Maxime <ma...@ta...> wrote:  
 
 Andrei
Thank you for your email.
Could you show how the log are displayed? (I am not sure to understand what you mean by 'logs are not displayed correctly').Also please send your Wrapper configuration file and log file to su...@ta....
Which Version and Edition of the Wrapper are you using?
Best regards,
Maxime

On Thu, Jul 25, 2019 at 6:03 PM Andrei via Wrapper-user <wra...@li...> wrote:


Hi, 

 
I encountered some issues regarding Tanuki Wrapper when Iwas trying to upgrade the Log4j from 1.2 to 2.x version. 
My question is if somebody managed to integrate Log4j 2 versionwith Tanuki Wrapper and if this is possible in sense of a working properly thelogging feature.

If you have an example or some documentation on how toconfigure Log4j2 with Tanuki Wrapper please let me know. 
 The problem it is that logs are not displayed correctly and also I can not control the log4j2.xml during RunTime -> here I am talking about Automatic Reconfiguration  Log4j – Configuring Log4j 2 - Apache Log4j 2

| 
| 
|  | 
Log4j – Configuring Log4j 2 - Apache Log4j 2

Ralph Goers


 |

 |

 |




Thank you in advance!

_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
  
  

Re: [Wrapper-user] Log4j2 integration

[Maxime <ma...@ta...>]

Andrei

Thank you for the explanation.

Regarding the logging of the JVM output, the Wrapper doesn't nothing more
than printing standard output at the INFO loglevel, regardless the logging
tool used along with your Java application.

*"wrapper.app.parameter.5=log4j.level=debug => The output of the
gateway_service_log4j2.log will be only the Info logs."*
> this is normal. The Wrapper always prints the JVM output at the INFO
loglevel, regardless the loglevel used by log4j. There is currently no
configuration to change this behavior. The same should be observed with
Log4j v. 1.2.

However it is not normal that you have some debug output skipped when using
the Wrapper. The Wrapper should print everything written by the JVM in
stdout & stderr. Please confirm that log4j is using the same streams.

*"The logging with the Log4j 1.2 version working perfectly"*
> Do you mean that no log output are skipped? Did you notice other
differences?

Best Regards,

Maxime

On Tue, Jul 30, 2019 at 3:19 PM 'Andrei' via Support Group <
sup...@ta...> wrote:

> Hi,
>
> Attached you will find  - the Tanuki wrapper configuration file named:
> wrapper.conf
>                                     - the log4j2 (Log4j 2 version) named:
> log4j2.xml
>
> also I attached files: - gateway_service_log4j2.log with the output when
> I run the project locally (on my PC) in the Eclipse environment. So here
> (locally) works like a charm. Note that locally I don't use Tanuki wrapper.
>                                  - gateway_service_all.log with the
> output when I run project on the server (on the environment where my app is
> deployed). So I use the Tanuki wrapper as a tool to run my application on
> the server.
>
>
> Story:
>
> - When I run my application locally (my PC) environment without the Tanuky
> wrapper configuration, the Logging is working perfectly with all the
> feature offered by Log4j 2 version (including Automatic Reconfiguration).
> - When I run my application on the server environment with the Tanuky
> wrapper configuration "wrapper.conf", the Logging not working OK. Note
> that inside the wrapper.conf I point to the Log4j2 config -> "
> wrapper.java.additional.1=-Dlog4j.configurationFile=.\log4j2.xml".
>
> - Here the problems appear after I activate the log4j2 configuration. Even
> if I set the logging level to DEBUG or to INFO inside the wrapper.conf -> wrapper.app.parameter.5=log4j.level=debug
> => The output of the gateway_service_log4j2.log will be only the Info
> logs. So it does not take in consideration the DEBUG level, or does not
> interpret correctly . More that this only some few of the Info logs are
> displayed.
> - The logs which is output by the Wrapper itself so the gateway_service_all.log
> seems that is working OK also on the server side environment.
>
> - That is the reason why I asked if somebody managed to integrate Log4j 2
> version with Tanuki Wrapper
>
> Note! The logging with the Log4j 1.2 version working perfectly and I have
> the same environment locally and on also same environment on server.
>
>
> Info from the manifest of the Tanuki wrapper that I use:
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.8.2
> Created-By: 1.4.2_19-b04 (Sun Microsystems Inc.)
> Built-By: chris
> Package: org.tanukisoftware.wrapper
> Extension-Name: wrapper
> Specification-Title: Java Service Wrapper
> Specification-Vendor: Tanuki Software, Ltd.
> Specification-Version: 3.5.15
> Implementation-Title: org.tanukisoftware.wrapper
> Implementation-Vendor: Tanuki Software, Ltd.
> Implementation-Version: 3.5.15
>
>
> P.S. if someone has an example how he used the Log4j2 with the Tanuki
> wrapper please let me know. Also some documentation how to integrate
> Wrapper with Log4j2 will help.
>
> Thanks in advance!
>
> Andrei
>
>
>
>
> On Friday, July 26, 2019, 09:57:40 AM GMT+1, Maxime <
> ma...@ta...> wrote:
>
>
> Andrei
>
> Thank you for your email.
>
> Could you show how the log are displayed? (I am not sure to understand
> what you mean by 'logs are not displayed correctly').
> Also please send your Wrapper configuration file and log file to
> su...@ta....
>
> Which Version and Edition of the Wrapper are you using?
>
> Best regards,
>
> Maxime
>
> On Thu, Jul 25, 2019 at 6:03 PM Andrei via Wrapper-user <
> wra...@li...> wrote:
>
> Hi,
>
>
> I encountered some issues regarding Tanuki Wrapper when I was trying to
> upgrade the Log4j from 1.2 to 2.x version.
>
> My question is if somebody managed to integrate Log4j 2 version with
> Tanuki Wrapper and if this is possible in sense of a working properly the
> logging feature.
>
> If you have an example or some documentation on how to configure Log4j2
> with Tanuki Wrapper please let me know.
>  The problem it is that logs are not displayed correctly and also I can
> not control the log4j2.xml during RunTime -> here I am talking about
> Automatic Reconfiguration  Log4j – Configuring Log4j 2 - Apache Log4j 2
> <https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration>
>
> Log4j – Configuring Log4j 2 - Apache Log4j 2
>
> Ralph Goers
>
>
> <https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration>
>
>
> Thank you in advance!
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Log4j2 integration

[Andrei <and...@ya...>]

 Hi, 
Attached you will find  - the Tanuki wrapper configuration file named: wrapper.conf                                     - the log4j2 (Log4j 2 version) named: log4j2.xml

also I attached files: - gateway_service_log4j2.log with the output when I run the project locally (on my PC) in the Eclipse environment. So here (locally) works like a charm. Note that locally I don't use Tanuki wrapper.                                 - gateway_service_all.log with the output when I run project on the server (on the environment where my app is deployed). So I use the Tanuki wrapper as a tool to run my application on the server. 
 Story: 
- When I run my application locally (my PC) environment without the Tanuky wrapper configuration, the Logging is working perfectly with all the feature offered by Log4j 2 version (including Automatic Reconfiguration). - When I run my application on the server environment with the Tanuky wrapper configuration "wrapper.conf", the Logging not working OK. Note that inside the wrapper.conf I point to the Log4j2 config -> "wrapper.java.additional.1=-Dlog4j.configurationFile=.\log4j2.xml". 
- Here the problems appear after I activate the log4j2 configuration. Even if I set the logging level to DEBUG or to INFO inside the wrapper.conf -> wrapper.app.parameter.5=log4j.level=debug => The output of the gateway_service_log4j2.log will be only the Info logs. So it does not take in consideration the DEBUG level, or does not interpret correctly . More that this only some few of the Info logs are displayed. - The logs which is output by the Wrapper itself so the gateway_service_all.log seems that is working OK also on the server side environment.
- That is the reason why I asked if somebody managed to integrate Log4j 2 version with Tanuki Wrapper Note! The logging with the Log4j 1.2 version working perfectly and I have the same environment locally and on also same environment on server.

Info from the manifest of the Tanuki wrapper that I use: 
Manifest-Version: 1.0Ant-Version: Apache Ant 1.8.2Created-By: 1.4.2_19-b04 (Sun Microsystems Inc.)Built-By: chrisPackage: org.tanukisoftware.wrapperExtension-Name: wrapperSpecification-Title: Java Service WrapperSpecification-Vendor: Tanuki Software, Ltd.Specification-Version: 3.5.15Implementation-Title: org.tanukisoftware.wrapperImplementation-Vendor: Tanuki Software, Ltd.Implementation-Version: 3.5.15

P.S. if someone has an example how he used the Log4j2 with the Tanuki wrapper please let me know. Also some documentation how to integrate Wrapper with Log4j2 will help.
Thanks in advance! 
Andrei 



    On Friday, July 26, 2019, 09:57:40 AM GMT+1, Maxime <ma...@ta...> wrote:  
 
 Andrei
Thank you for your email.
Could you show how the log are displayed? (I am not sure to understand what you mean by 'logs are not displayed correctly').Also please send your Wrapper configuration file and log file to su...@ta....
Which Version and Edition of the Wrapper are you using?
Best regards,
Maxime

On Thu, Jul 25, 2019 at 6:03 PM Andrei via Wrapper-user <wra...@li...> wrote:


Hi, 

 
I encountered some issues regarding Tanuki Wrapper when Iwas trying to upgrade the Log4j from 1.2 to 2.x version. 
My question is if somebody managed to integrate Log4j 2 versionwith Tanuki Wrapper and if this is possible in sense of a working properly thelogging feature.

If you have an example or some documentation on how toconfigure Log4j2 with Tanuki Wrapper please let me know. 
 The problem it is that logs are not displayed correctly and also I can not control the log4j2.xml during RunTime -> here I am talking about Automatic Reconfiguration  Log4j – Configuring Log4j 2 - Apache Log4j 2

| 
| 
|  | 
Log4j – Configuring Log4j 2 - Apache Log4j 2

Ralph Goers


 |

 |

 |




Thank you in advance!

_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
  

Re: [Wrapper-user] Log4j2 integration

[Maxime <ma...@ta...>]

Andrei

Thank you for your email.

Could you show how the log are displayed? (I am not sure to understand what
you mean by 'logs are not displayed correctly').
Also please send your Wrapper configuration file and log file to
su...@ta....

Which Version and Edition of the Wrapper are you using?

Best regards,

Maxime

On Thu, Jul 25, 2019 at 6:03 PM Andrei via Wrapper-user <
wra...@li...> wrote:

> Hi,
>
>
> I encountered some issues regarding Tanuki Wrapper when I was trying to
> upgrade the Log4j from 1.2 to 2.x version.
>
> My question is if somebody managed to integrate Log4j 2 version with
> Tanuki Wrapper and if this is possible in sense of a working properly the
> logging feature.
>
> If you have an example or some documentation on how to configure Log4j2
> with Tanuki Wrapper please let me know.
>  The problem it is that logs are not displayed correctly and also I can
> not control the log4j2.xml during RunTime -> here I am talking about
> Automatic Reconfiguration  Log4j – Configuring Log4j 2 - Apache Log4j 2
> <https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration>
>
> Log4j – Configuring Log4j 2 - Apache Log4j 2
>
> Ralph Goers
>
>
> <https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration>
>
>
> Thank you in advance!
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Log4j2 integration

[Andrei <and...@ya...>]

Hi, 

 
I encountered some issues regarding Tanuki Wrapper when Iwas trying to upgrade the Log4j from 1.2 to 2.x version. 
My question is if somebody managed to integrate Log4j 2 versionwith Tanuki Wrapper and if this is possible in sense of a working properly thelogging feature.

If you have an example or some documentation on how toconfigure Log4j2 with Tanuki Wrapper please let me know. 
 The problem it is that logs are not displayed correctly and also I can not control the log4j2.xml during RunTime -> here I am talking about Automatic Reconfiguration  Log4j – Configuring Log4j 2 - Apache Log4j 2

| 
| 
|  | 
Log4j – Configuring Log4j 2 - Apache Log4j 2

Ralph Goers


 |

 |

 |




Thank you in advance!

[Wrapper-user] Java Service Wrapper 3.5.40 released!

[Maxime <ma...@ta...>]

 Hello everyone,

We are proud to announce the release of version 3.5.40 of the Java Service
Wrapper.
http://wrapper.tanukisoftware.org/doc/english/download.jsp

This version includes several bug fixes and improvements. You can review
the release notes for a full list of changes.
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Please let us know if you have any questions about the release.

Sincerely,

Java Service Wrapper Team
Tanuki Software, Ltd.

Re: [Wrapper-user] ERROR: Unable to allocate a console for the service: Not enough storage is available to process this command. (0x8)

[Maxime <ma...@ta...>]

Michael

Thank you for your email.

It seems your system is short of memory. Could you check the memory usage
at the moment the error happens.
It is also strange that you get the message "Configured log file set to
'C:\Program Files (x86)\AutoReceive\logs\service.log'." multiple times. Are
you running multiple instances of the Wrapper in parallel?

Best regards,

Maxime

On Sat, May 11, 2019 at 12:10 AM Conrad, Michael A <
Mic...@qu...> wrote:

> Java Service Wrapper Community Edition 32-bit 3.5.37
>
>   Copyright (C) 1999-2018 Tanuki Software, Ltd. All Rights Reserved.
>
>     http://wrapper.tanukisoftware.com
>
>
>
>
>
>
>
> Log
>
>
>
> DEBUG  | wrapperm | 2019/05/10 10:22:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:07 | Service command: "C:\Program
> Files (x86)\AutoReceive\wrapper.exe" -s "C:\Program Files
> (x86)\AutoReceive\wrapper.conf"
>
> STATUS | wrapperm | 2019/05/10 10:22:07 | AutoReceive service installed.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> STATUS | wrapperm | 2019/05/10 10:22:08 | Starting the AutoReceive
> service...
>
> DEBUG  | wrapper  | 2019/05/10 10:22:08 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> STATUS | wrapper  | 2019/05/10 10:22:08 | --> Wrapper Started as Service
>
> DEBUG  | wrapper  | 2019/05/10 10:22:08 | Allocating a console for the
> service.
>
> ERROR  | wrapper  | 2019/05/10 10:22:08 | ERROR: Unable to allocate a
> console for the service: Not enough storage is available to process this
> command. (0x8)
>
> STATUS | wrapper  | 2019/05/10 10:22:08 | <-- Wrapper Stopped
>
> ERROR  | wrapperm | 2019/05/10 10:22:10 | The AutoReceive service was
> launched, but failed to start.
>
> ERROR  | wrapperm | 2019/05/10 10:22:10 | Please check the log file for
> more information: C:\Program Files (x86)\AutoReceive\logs\service.log
>
> DEBUG  | wrapperm | 2019/05/10 10:22:10 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:02 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:02 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> STATUS | wrapperm | 2019/05/10 10:23:05 | Starting the AutoReceive
> service...
>
> DEBUG  | wrapper  | 2019/05/10 10:23:05 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
> STATUS | wrapper  | 2019/05/10 10:23:05 | --> Wrapper Started as Service
>
> DEBUG  | wrapper  | 2019/05/10 10:23:05 | Allocating a console for the
> service.
>
> ERROR  | wrapper  | 2019/05/10 10:23:05 | ERROR: Unable to allocate a
> console for the service: Not enough storage is available to process this
> command. (0x8)
>
> STATUS | wrapper  | 2019/05/10 10:23:05 | <-- Wrapper Stopped
>
> ERROR  | wrapperm | 2019/05/10 10:23:07 | The AutoReceive service was
> launched, but failed to start.
>
> ERROR  | wrapperm | 2019/05/10 10:23:07 | Please check the log file for
> more information: C:\Program Files (x86)\AutoReceive\logs\service.log
>
> DEBUG  | wrapperm | 2019/05/10 10:23:07 | Configured log file set to
> 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
>
>
>
>
>
> Wrapper.conf
>
>
>
> #********************************************************************
>
> # Wrapper Properties
>
> #********************************************************************
>
> # Java Application
>
> wrapper.java.command=./JRE1_8_0_162/bin/java
>
>
>
> # 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=com.medplus.autosend.client.ARService
>
>
>
> # Java Classpath (include wrapper.jar)  Add class path elements as
>
> #  needed starting from 1
>
> wrapper.java.classpath.1=autosend.jar
>
> wrapper.java.classpath.2=log4j-1.2.17.jar
>
> wrapper.java.classpath.3=slf4j-api-1.6.6.jar
>
> wrapper.java.classpath.4=slf4j-log4j12-1.6.6.jar
>
> wrapper.java.classpath.5=saaj.jar
>
> wrapper.java.classpath.6=wsdl4j-1.5.1.jar
>
> wrapper.java.classpath.7=commons-discovery-0.5.jar
>
> wrapper.java.classpath.8=commons-lang-2.6.jar
>
> wrapper.java.classpath.9=commons-logging-1.2.jar
>
> wrapper.java.classpath.10=us.jar
>
> wrapper.java.classpath.11=pjx-1.4.0.jar
>
> wrapper.java.classpath.12=commons-io-2.6.jar
>
> wrapper.java.classpath.13=commons-exec-1.3.jar
>
> wrapper.java.classpath.14=hapi-base-2.2.jar
>
> wrapper.java.classpath.15=hapi-structures-v23-2.2.jar
>
> wrapper.java.classpath.16=hapi-structures-v231-2.2.jar
>
> wrapper.java.classpath.17=iText-2.1.4.jar
>
> wrapper.java.classpath.18=bcprov.jar
>
> wrapper.java.classpath.19=bcpkix.jar
>
> wrapper.java.classpath.20=bcmail-jdk16-143.jar
>
> wrapper.java.classpath.21=jdatepicker-1.3.4.jar
>
> wrapper.java.classpath.22=wrapper.jar
>
>
>
>
>
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
>
> wrapper.java.library.path.1=.
>
>
>
> # Java Additional Parameters
>
> #wrapper.java.additional.1=
>
>
>
> # Initial Java Heap Size (in MB)
>
> #wrapper.java.initmemory=32
>
>
>
> # Maximum Java Heap Size (in MB)
>
> wrapper.java.maxmemory=1024
>
>
>
> # Application parameters.  Add parameters as needed starting from 1
>
> wrapper.app.parameter.1=
>
>
>
> #********************************************************************
>
> # Wrapper Logging Properties
>
> #********************************************************************
>
>
>
> 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=DEBUG
>
>
>
> # Log file to use for wrapper output logging.
>
> wrapper.logfile=logs/service.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=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=3
>
>
>
> # Log Level for sys/event log output.  (See docs for log levels)
>
> wrapper.syslog.loglevel=DEBUG
>
>
>
> #********************************************************************
>
> # Wrapper Windows Properties
>
> #********************************************************************
>
> # Title to use when running as a console
>
> wrapper.console.title=AutoReceive
>
>
>
> #********************************************************************
>
> # 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
>
> wrapper.ntservice.name=AutoReceive
>
>
>
> # Display name of the service
>
> wrapper.ntservice.displayname=AutoReceive
>
>
>
> # Description of the service
>
> wrapper.ntservice.description=AutoReceive service application
>
>
>
> # Service dependencies.  Add dependencies as needed starting from 1
>
> wrapper.ntservice.dependency.1=
>
>
>
> # Mode in which the service is installed.  AUTO_START or DEMAND_START
>
> wrapper.ntservice.starttype=AUTO_START
>
>
>
> # Allow the service to interact with the desktop.
>
> wrapper.ntservice.interactive=true
>
>
>
> # Set the minimum amount of time that an application must remain running in
>
> # order to be considered a successful invocation. See
> also:wrapper.max_failed_invocations
>
> # Setting to one second to keep the wrapper from failing when HUB or the
> network is down.
>
> # DE9362
>
> wrapper.successful_invocation_time=10
>
>
>
>
>
>
>
>
>
> *Michael A. Conrad*
>
> *Quest Diagnostics Incorporated* | Senior Software Engineer | Healthcare
> Technology & Analytics Solutions (HUB) | 4690 Parkway Drive | Mason, OH
> 45040 USA | *phone* +1.513.204.2942 | michael.a.conrad@
> questdiagnostics.com | www.questdiagnostics.com
>
> Please think about resource conservation before you print this message.
>
>
>
> ______________________________________________________________________
> The contents of this message, together with any attachments, are intended
> only for the use of the person(s) to which they are addressed and may
> contain confidential and/or privileged information. Further, any medical
> information herein is confidential and protected by law. It is unlawful for
> unauthorized persons to use, review, copy, disclose, or disseminate
> confidential medical information. If you are not the intended recipient,
> immediately advise the sender and delete this message and any attachments.
> Any distribution, or copying of this message, or any attachment, is
> prohibited.
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] ERROR: Unable to allocate a console for the service: Not enough storage is available to process this command. (0x8)

[Conrad, M. A <Mic...@qu...>]

Java Service Wrapper Community Edition 32-bit 3.5.37
  Copyright (C) 1999-2018 Tanuki Software, Ltd. All Rights Reserved.
    http://wrapper.tanukisoftware.com

[cid:image001.png@01D5071E.BCA17990]


Log

DEBUG  | wrapperm | 2019/05/10 10:22:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Service command: "C:\Program Files (x86)\AutoReceive\wrapper.exe" -s "C:\Program Files (x86)\AutoReceive\wrapper.conf"
STATUS | wrapperm | 2019/05/10 10:22:07 | AutoReceive service installed.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapperm | 2019/05/10 10:22:08 | Starting the AutoReceive service...
DEBUG  | wrapper  | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapper  | 2019/05/10 10:22:08 | --> Wrapper Started as Service
DEBUG  | wrapper  | 2019/05/10 10:22:08 | Allocating a console for the service.
ERROR  | wrapper  | 2019/05/10 10:22:08 | ERROR: Unable to allocate a console for the service: Not enough storage is available to process this command. (0x8)
STATUS | wrapper  | 2019/05/10 10:22:08 | <-- Wrapper Stopped
ERROR  | wrapperm | 2019/05/10 10:22:10 | The AutoReceive service was launched, but failed to start.
ERROR  | wrapperm | 2019/05/10 10:22:10 | Please check the log file for more information: C:\Program Files (x86)\AutoReceive\logs\service.log
DEBUG  | wrapperm | 2019/05/10 10:22:10 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:02 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:02 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapperm | 2019/05/10 10:23:05 | Starting the AutoReceive service...
DEBUG  | wrapper  | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapper  | 2019/05/10 10:23:05 | --> Wrapper Started as Service
DEBUG  | wrapper  | 2019/05/10 10:23:05 | Allocating a console for the service.
ERROR  | wrapper  | 2019/05/10 10:23:05 | ERROR: Unable to allocate a console for the service: Not enough storage is available to process this command. (0x8)
STATUS | wrapper  | 2019/05/10 10:23:05 | <-- Wrapper Stopped
ERROR  | wrapperm | 2019/05/10 10:23:07 | The AutoReceive service was launched, but failed to start.
ERROR  | wrapperm | 2019/05/10 10:23:07 | Please check the log file for more information: C:\Program Files (x86)\AutoReceive\logs\service.log
DEBUG  | wrapperm | 2019/05/10 10:23:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.


Wrapper.conf

#********************************************************************
# Wrapper Properties
#********************************************************************
# Java Application
wrapper.java.command=./JRE1_8_0_162/bin/java

# 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=com.medplus.autosend.client.ARService

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=autosend.jar
wrapper.java.classpath.2=log4j-1.2.17.jar
wrapper.java.classpath.3=slf4j-api-1.6.6.jar
wrapper.java.classpath.4=slf4j-log4j12-1.6.6.jar
wrapper.java.classpath.5=saaj.jar
wrapper.java.classpath.6=wsdl4j-1.5.1.jar
wrapper.java.classpath.7=commons-discovery-0.5.jar
wrapper.java.classpath.8=commons-lang-2.6.jar
wrapper.java.classpath.9=commons-logging-1.2.jar
wrapper.java.classpath.10=us.jar
wrapper.java.classpath.11=pjx-1.4.0.jar
wrapper.java.classpath.12=commons-io-2.6.jar
wrapper.java.classpath.13=commons-exec-1.3.jar
wrapper.java.classpath.14=hapi-base-2.2.jar
wrapper.java.classpath.15=hapi-structures-v23-2.2.jar
wrapper.java.classpath.16=hapi-structures-v231-2.2.jar
wrapper.java.classpath.17=iText-2.1.4.jar
wrapper.java.classpath.18=bcprov.jar
wrapper.java.classpath.19=bcpkix.jar
wrapper.java.classpath.20=bcmail-jdk16-143.jar
wrapper.java.classpath.21=jdatepicker-1.3.4.jar
wrapper.java.classpath.22=wrapper.jar


# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=.

# Java Additional Parameters
#wrapper.java.additional.1=

# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=32

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=

#********************************************************************
# Wrapper Logging Properties
#********************************************************************

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=DEBUG

# Log file to use for wrapper output logging.
wrapper.logfile=logs/service.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=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=3

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=DEBUG

#********************************************************************
# Wrapper Windows Properties
#********************************************************************
# Title to use when running as a console
wrapper.console.title=AutoReceive

#********************************************************************
# 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
wrapper.ntservice.name=AutoReceive

# Display name of the service
wrapper.ntservice.displayname=AutoReceive

# Description of the service
wrapper.ntservice.description=AutoReceive service application

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=true

# Set the minimum amount of time that an application must remain running in
# order to be considered a successful invocation. See also:wrapper.max_failed_invocations
# Setting to one second to keep the wrapper from failing when HUB or the network is down.
# DE9362
wrapper.successful_invocation_time=10




Michael A. Conrad
Quest Diagnostics Incorporated | Senior Software Engineer | Healthcare Technology & Analytics Solutions (HUB) | 4690 Parkway Drive | Mason, OH 45040 USA | phone +1.513.204.2942 | mic...@qu...<http://questdiagnostics.com/> | www.questdiagnostics.com<http://www.questdiagnostics.com/>
Please think about resource conservation before you print this message.


______________________________________________________________________
The contents of this message, together with any attachments, are intended only for the use of the person(s) to which they are addressed and may contain confidential and/or privileged information. Further, any medical information herein is confidential and protected by law. It is unlawful for unauthorized persons to use, review, copy, disclose, or disseminate confidential medical information. If you are not the intended recipient, immediately advise the sender and delete this message and any attachments. Any distribution, or copying of this message, or any attachment, is prohibited.

[Wrapper-user] ERROR: Unable to allocate a console for the service: Not enough storage is available to process this command. (0x8)

[Conrad, M. A <Mic...@qu...>]

Java Service Wrapper Community Edition 32-bit 3.5.37
  Copyright (C) 1999-2018 Tanuki Software, Ltd. All Rights Reserved.
    http://wrapper.tanukisoftware.com

[cid:image001.png@01D5071B.ABF24370]


Log

DEBUG  | wrapperm | 2019/05/10 10:22:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Service command: "C:\Program Files (x86)\AutoReceive\wrapper.exe" -s "C:\Program Files (x86)\AutoReceive\wrapper.conf"
STATUS | wrapperm | 2019/05/10 10:22:07 | AutoReceive service installed.
DEBUG  | wrapperm | 2019/05/10 10:22:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapperm | 2019/05/10 10:22:08 | Starting the AutoReceive service...
DEBUG  | wrapper  | 2019/05/10 10:22:08 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapper  | 2019/05/10 10:22:08 | --> Wrapper Started as Service
DEBUG  | wrapper  | 2019/05/10 10:22:08 | Allocating a console for the service.
ERROR  | wrapper  | 2019/05/10 10:22:08 | ERROR: Unable to allocate a console for the service: Not enough storage is available to process this command. (0x8)
STATUS | wrapper  | 2019/05/10 10:22:08 | <-- Wrapper Stopped
ERROR  | wrapperm | 2019/05/10 10:22:10 | The AutoReceive service was launched, but failed to start.
ERROR  | wrapperm | 2019/05/10 10:22:10 | Please check the log file for more information: C:\Program Files (x86)\AutoReceive\logs\service.log
DEBUG  | wrapperm | 2019/05/10 10:22:10 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:02 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:02 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:04 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
DEBUG  | wrapperm | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapperm | 2019/05/10 10:23:05 | Starting the AutoReceive service...
DEBUG  | wrapper  | 2019/05/10 10:23:05 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.
STATUS | wrapper  | 2019/05/10 10:23:05 | --> Wrapper Started as Service
DEBUG  | wrapper  | 2019/05/10 10:23:05 | Allocating a console for the service.
ERROR  | wrapper  | 2019/05/10 10:23:05 | ERROR: Unable to allocate a console for the service: Not enough storage is available to process this command. (0x8)
STATUS | wrapper  | 2019/05/10 10:23:05 | <-- Wrapper Stopped
ERROR  | wrapperm | 2019/05/10 10:23:07 | The AutoReceive service was launched, but failed to start.
ERROR  | wrapperm | 2019/05/10 10:23:07 | Please check the log file for more information: C:\Program Files (x86)\AutoReceive\logs\service.log
DEBUG  | wrapperm | 2019/05/10 10:23:07 | Configured log file set to 'C:\Program Files (x86)\AutoReceive\logs\service.log'.


Wrapper.conf

#********************************************************************
# Wrapper Properties
#********************************************************************
# Java Application
wrapper.java.command=./JRE1_8_0_162/bin/java

# 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=com.medplus.autosend.client.ARService

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=autosend.jar
wrapper.java.classpath.2=log4j-1.2.17.jar
wrapper.java.classpath.3=slf4j-api-1.6.6.jar
wrapper.java.classpath.4=slf4j-log4j12-1.6.6.jar
wrapper.java.classpath.5=saaj.jar
wrapper.java.classpath.6=wsdl4j-1.5.1.jar
wrapper.java.classpath.7=commons-discovery-0.5.jar
wrapper.java.classpath.8=commons-lang-2.6.jar
wrapper.java.classpath.9=commons-logging-1.2.jar
wrapper.java.classpath.10=us.jar
wrapper.java.classpath.11=pjx-1.4.0.jar
wrapper.java.classpath.12=commons-io-2.6.jar
wrapper.java.classpath.13=commons-exec-1.3.jar
wrapper.java.classpath.14=hapi-base-2.2.jar
wrapper.java.classpath.15=hapi-structures-v23-2.2.jar
wrapper.java.classpath.16=hapi-structures-v231-2.2.jar
wrapper.java.classpath.17=iText-2.1.4.jar
wrapper.java.classpath.18=bcprov.jar
wrapper.java.classpath.19=bcpkix.jar
wrapper.java.classpath.20=bcmail-jdk16-143.jar
wrapper.java.classpath.21=jdatepicker-1.3.4.jar
wrapper.java.classpath.22=wrapper.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=.

# Java Additional Parameters
#wrapper.java.additional.1=

# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=32

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=

#********************************************************************
# Wrapper Logging Properties
#********************************************************************

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=DEBUG

# Log file to use for wrapper output logging.
wrapper.logfile=logs/service.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=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=3

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=DEBUG

#********************************************************************
# Wrapper Windows Properties
#********************************************************************
# Title to use when running as a console
wrapper.console.title=AutoReceive

#********************************************************************
# 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
wrapper.ntservice.name=AutoReceive

# Display name of the service
wrapper.ntservice.displayname=AutoReceive

# Description of the service
wrapper.ntservice.description=AutoReceive service application

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=true

# Set the minimum amount of time that an application must remain running in
# order to be considered a successful invocation. See also:wrapper.max_failed_invocations
# Setting to one second to keep the wrapper from failing when HUB or the network is down.
# DE9362
wrapper.successful_invocation_time=10




Michael A. Conrad
Quest Diagnostics Incorporated | Senior Software Engineer | Healthcare Technology & Analytics Solutions (HUB) | 4690 Parkway Drive | Mason, OH 45040 USA | phone +1.513.204.2942 | mic...@qu...<http://questdiagnostics.com/> | www.questdiagnostics.com<http://www.questdiagnostics.com/>
Please think about resource conservation before you print this message.


______________________________________________________________________
The contents of this message, together with any attachments, are intended only for the use of the person(s) to which they are addressed and may contain confidential and/or privileged information. Further, any medical information herein is confidential and protected by law. It is unlawful for unauthorized persons to use, review, copy, disclose, or disseminate confidential medical information. If you are not the intended recipient, immediately advise the sender and delete this message and any attachments. Any distribution, or copying of this message, or any attachment, is prohibited.

[Wrapper-user] Java Service Wrapper 3.5.39 released!

[Maxime <ma...@ta...>]

Hello everyone,

We are proud to announce the release of version 3.5.39 of the Java Service
Wrapper.
http://wrapper.tanukisoftware.org/doc/english/download.jsp

This version includes several bug fixes and improvements. You can review
the release notes for a full list of changes.
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Please let us know if you have any questions about the release.

Sincerely,

Java Service Wrapper Team
Tanuki Software, Ltd.

Re: [Wrapper-user] Starting -> Running status with WrapperJarApp

[Maxime <ma...@ta...>]

James

Thank you for your email.

WrapperJarApp is an integration method that was added at a later stage. It
seems that when it was made available we forgot to update the description
of wrapper.startup.timeout. Thank you for reporting this lack. We will add
a mention to WrapperJarApp on this page of our documentation the next time
we update our website.

Regarding how the Wrapper considers the application's startup has
completed, WrapperJarApp works like WrapperSimpleApp and
WrapperStartStopApp:

By default the Wrapper considers that the application has started if the
main method of your application returns (without throwing an exception), or
if it runs normally for more than 2 seconds. This is done because many user
applications are written with main methods that do not return for the life
of the application.

You can change this behaviour by adding
-Dorg.tanukisoftware.wrapper.WrapperJarApp.waitForStartMain=TRUE in your
wrapper.java.additional.<n> properties. This will tell the Wrapper to wait
indefinitely for the main method to complete (if you know that your main
method should return within a certain amount of time).

You can also increase the time that the Wrapper should wait for your main
method by changing setting
-Dorg.tanukisoftware.wrapper.WrapperJarApp.maxStartMainWait.

Finally, if your start procedure takes some time, you can call
WrapperManager.signalStarting(waitHint) to let the Wrapper know that the
application is in starting normally and requires additional time. The
Wrapper will then wait at least for the specified 'waitHint'.

Please let me know if you have any questions.

Best Regards,

Maxime

On Tue, Apr 23, 2019 at 11:13 PM Ruairidh James <
rua...@sy...> wrote:

> Hello,
>
> The configuration property wrapper.startup.timeout is described as "Number
> of seconds to allow between the time that the Wrapper launches the JVM
> process and the time that the JVM side of the Wrapper responds that the
> application has started."
>
> It's not clear to me how "the Wrapper responds that the application has
> started", in particular in the case of the WrapperJarApp integration which
> is not covered in the troubleshooting advice
>
> *"The first possibility is that the start method call is not returning.
> This should not be an issue if you are using the WrapperSimpleApp
> <https://wrapper.tanukisoftware.com/doc/english/integrate.html#method1> or SimpleStartStopApp
> <https://wrapper.tanukisoftware.com/doc/english/integrate.html#method2> classes
> to launch your application. If you are implementing the WrapperListener
> <https://wrapper.tanukisoftware.com/doc/english/integrate.html#method3> however,
> please verify that the start method is indeed returning upon completion.
> You should be able to see this with DEBUG output enabled." *
>
> Are there any expectations of my application's main class that it
> implements a particular protocol for communicating the end of startup?
>
> Ruairidh James
> --
>
> Exchange Place 2
>
> 5 Semple Street
>
> Edinburgh
>
> EH3 8BL
>
> United Kingdom
>
>
> Telephone: +44 131 290 2318
>
> Email: rua...@sy...
>
> Website: www.symphonicsoft.com
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Starting -> Running status with WrapperJarApp

[Ruairidh J. <rua...@sy...>]

Hello,

The configuration property wrapper.startup.timeout is described as "Number
of seconds to allow between the time that the Wrapper launches the JVM
process and the time that the JVM side of the Wrapper responds that the
application has started."

It's not clear to me how "the Wrapper responds that the application has
started", in particular in the case of the WrapperJarApp integration which
is not covered in the troubleshooting advice

*"The first possibility is that the start method call is not returning.
This should not be an issue if you are using the WrapperSimpleApp
<https://wrapper.tanukisoftware.com/doc/english/integrate.html#method1>
or SimpleStartStopApp
<https://wrapper.tanukisoftware.com/doc/english/integrate.html#method2> classes
to launch your application. If you are implementing the WrapperListener
<https://wrapper.tanukisoftware.com/doc/english/integrate.html#method3>
however,
please verify that the start method is indeed returning upon completion.
You should be able to see this with DEBUG output enabled." *

Are there any expectations of my application's main class that it
implements a particular protocol for communicating the end of startup?

Ruairidh James
-- 

Exchange Place 2

5 Semple Street

Edinburgh

EH3 8BL

United Kingdom


Telephone: +44 131 290 2318

Email: rua...@sy...

Website: www.symphonicsoft.com

Re: [Wrapper-user] Unable to access embedded jars in a Spring Boot executable.

[Milind R. <mi...@gm...>]

Found the problem.  Don't understand it.  For some reason, it was only 
this solitary jar (Saxon-EE-9.5.1.9.jar) which it couldn't load from the 
executable jar.  All other jars it was able to load. Weird.  Once I 
added that to the lib directory manually and referenced it in the 
wrapper.conf, everything worked.

On 4/11/2019 1:00 AM, Milind Rao wrote:
> Thanks Maxime,
>
> I have sent an email to su...@ta... 
> <mailto:su...@ta...> with the details.
>
> The jar file can be run directly successfully and there are no issues 
> with that.
>
> Changing the wrapper.app.parameter.2 from the 
> "com.example.PaymentBridge" in the wrapper.conf file  to 
> "org.springframework.boot.loader.JarLauncher" did show me the spring 
> framework log messages that I was missing earlier.  But it didn't 
> solve the problem of not being to access the embedded jars in the 
> Spring Boot executable jar.
>
> On 4/10/2019 11:53 PM, Maxime wrote:
>> Dear Milind Rao
>>
>> Thank you for your email.
>>
>> Normally the Wrapper should only launch the 
>> org.springframework.boot.loader.JarLauncher.
>> Then Spring Boot will in turn scan the manifest and launch 
>> com.example.PaymentBridge with the dependencies specified in the 
>> manifest (inside BOOT-INF/lib/).
>> I am wondering why this is failing to be done by Spring Boot... It 
>> would be useful to see the full log file to better understand what is 
>> happening.
>> If possible, can you send it to su...@ta... 
>> <mailto:su...@ta...>? You may also set 
>> wrapper.debug=TRUE in your configuration file to get detailed output.
>>
>> Did you try to run your application with Spring Boot 2 without the 
>> Wrapper (without extracting the Jar and editing the classpath)? Do 
>> you encounter the same issue?
>>
>> Best Regards,
>>
>> Maxime
>>
>> On Thu, Apr 11, 2019 at 5:01 AM Milind Rao <mi...@gm... 
>> <mailto:mi...@gm...>> wrote:
>>
>>     I'm using Spring Boot to create an executable jar with an
>>     embedded Tomcat container.
>>
>>     This is the relevant information from the MANIFEST.MF file
>>
>>         Spring-Boot-Version: 2.0.5.RELEASE
>>         Main-Class: org.springframework.boot.loader.JarLauncher
>>         Start-Class: com.example.PaymentBridge
>>         Spring-Boot-Classes: BOOT-INF/classes/
>>         Spring-Boot-Lib: BOOT-INF/lib/
>>         Created-By: Apache Maven 3.0.5
>>         Build-Jdk: 1.8.0_191
>>
>>     I can run the jar file on Linux with no problem.
>>      java -jar example.jar
>>
>>     I used method 4 to wrap the jar file and when I run it, I get an
>>     error
>>
>>         Caused by: java.lang.RuntimeException:
>>         XPathFactory#newInstance() failed to create an XPathFactory
>>         for the default object model:
>>         http://java.sun.com/jaxp/xpath/dom with the
>>         XPathFactoryConfigurationException:
>>         javax.xml.xpath.XPathFactoryConfigurationException:
>>         java.util.ServiceConfigurationError:
>>         javax.xml.xpath.XPathFactory: Provider
>>         com.saxonica.config.EnterpriseXPathFactory could not be
>>         instantiated
>>
>>     This is because it couldn't find the Saxon-EE-9.5.1.9.jar file
>>     which is in the BOOT-INF/lib/ directory of the spring boot jar file.
>>
>>     I pulled out all the jars in the BOOT-INF/lib directory and
>>     copied them to a directory that I added to a lib2 directory to
>>     test.  Added the following property to the wrapper.conf file
>>         wrapper.java.classpath.2=../lib2/*.jar
>>     and it worked.
>>
>>     Clearly I don't want to do that with every file in the first
>>     place.  And I don't want to have to keep doing that every time my
>>     dependencies change.
>>
>>     How can I get the wrapper to add all the embedded jars to the
>>     classpath?
>>
>>     On startup, I do see this line.
>>
>>         Application started with classpath:
>>         [jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/classes!/,
>>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-starter-web-2.0.5.RELEASE.jar!/,
>>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-starter-2.0.5.RELEASE.jar!/,
>>
>>         ...
>>         ,
>>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/*Saxon-EE-9.5.1.9.jar!*/,
>>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/xercesImpl-2.10.0.jar!
>>
>>     On linux the classpath is separated by ':', I'm not sure if the
>>     comma between the jars is causing a problem or what.
>>
>>     Any help would be appreciated.
>>
>>     _______________________________________________
>>     Wrapper-user mailing list
>>     Wra...@li...
>>     <mailto:Wra...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>>
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Unable to access embedded jars in a Spring Boot executable.

[Milind R. <mi...@gm...>]

Thanks Maxime,

I have sent an email to su...@ta... 
<mailto:su...@ta...> with the details.

The jar file can be run directly successfully and there are no issues 
with that.

Changing the wrapper.app.parameter.2 from the 
"com.example.PaymentBridge" in the wrapper.conf file  to 
"org.springframework.boot.loader.JarLauncher" did show me the spring 
framework log messages that I was missing earlier.  But it didn't solve 
the problem of not being to access the embedded jars in the Spring Boot 
executable jar.

On 4/10/2019 11:53 PM, Maxime wrote:
> Dear Milind Rao
>
> Thank you for your email.
>
> Normally the Wrapper should only launch the 
> org.springframework.boot.loader.JarLauncher.
> Then Spring Boot will in turn scan the manifest and launch 
> com.example.PaymentBridge with the dependencies specified in the 
> manifest (inside BOOT-INF/lib/).
> I am wondering why this is failing to be done by Spring Boot... It 
> would be useful to see the full log file to better understand what is 
> happening.
> If possible, can you send it to su...@ta... 
> <mailto:su...@ta...>? You may also set 
> wrapper.debug=TRUE in your configuration file to get detailed output.
>
> Did you try to run your application with Spring Boot 2 without the 
> Wrapper (without extracting the Jar and editing the classpath)? Do you 
> encounter the same issue?
>
> Best Regards,
>
> Maxime
>
> On Thu, Apr 11, 2019 at 5:01 AM Milind Rao <mi...@gm... 
> <mailto:mi...@gm...>> wrote:
>
>     I'm using Spring Boot to create an executable jar with an embedded
>     Tomcat container.
>
>     This is the relevant information from the MANIFEST.MF file
>
>         Spring-Boot-Version: 2.0.5.RELEASE
>         Main-Class: org.springframework.boot.loader.JarLauncher
>         Start-Class: com.example.PaymentBridge
>         Spring-Boot-Classes: BOOT-INF/classes/
>         Spring-Boot-Lib: BOOT-INF/lib/
>         Created-By: Apache Maven 3.0.5
>         Build-Jdk: 1.8.0_191
>
>     I can run the jar file on Linux with no problem.
>      java -jar example.jar
>
>     I used method 4 to wrap the jar file and when I run it, I get an error
>
>         Caused by: java.lang.RuntimeException:
>         XPathFactory#newInstance() failed to create an XPathFactory
>         for the default object model:
>         http://java.sun.com/jaxp/xpath/dom with the
>         XPathFactoryConfigurationException:
>         javax.xml.xpath.XPathFactoryConfigurationException:
>         java.util.ServiceConfigurationError:
>         javax.xml.xpath.XPathFactory: Provider
>         com.saxonica.config.EnterpriseXPathFactory could not be
>         instantiated
>
>     This is because it couldn't find the Saxon-EE-9.5.1.9.jar file
>     which is in the BOOT-INF/lib/ directory of the spring boot jar file.
>
>     I pulled out all the jars in the BOOT-INF/lib directory and copied
>     them to a directory that I added to a lib2 directory to test. 
>     Added the following property to the wrapper.conf file
>         wrapper.java.classpath.2=../lib2/*.jar
>     and it worked.
>
>     Clearly I don't want to do that with every file in the first
>     place.  And I don't want to have to keep doing that every time my
>     dependencies change.
>
>     How can I get the wrapper to add all the embedded jars to the
>     classpath?
>
>     On startup, I do see this line.
>
>         Application started with classpath:
>         [jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/classes!/,
>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-starter-web-2.0.5.RELEASE.jar!/,
>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-starter-2.0.5.RELEASE.jar!/,
>
>         ...
>         ,
>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/*Saxon-EE-9.5.1.9.jar!*/,
>         jar:file:/opt/example/0.1.0/bin/../lib/example-bridge-0.1.0-SNAPSHOT.jar!/BOOT-INF/lib/xercesImpl-2.10.0.jar!
>
>     On linux the classpath is separated by ':', I'm not sure if the
>     comma between the jars is causing a problem or what.
>
>     Any help would be appreciated.
>
>     _______________________________________________
>     Wrapper-user mailing list
>     Wra...@li...
>     <mailto:Wra...@li...>
>     https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user