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

Re: [Wrapper-user] Please add "JSON" to logging format

[Karthik K. V. <kar...@gm...>]

It's a good idea, but I have these ideas on them:

- JSON isn't an appendable format, and this sort of log will not be well
formed JSON.
- CSV and YAML are good ideas - and they do support incremental updates and
parsing libraries are available.
- TXT files do allow appending and incremental updates are possible -
except, they require escaping \n s in Exceptions etc.

On 23 July 2017 at 10:29, Y.Watanabe <na...@gm...> wrote:

> Hi.
> I hope that JSW have "JSON" format configuration on
> "wrapper.console.format".
>
> Belong to "12-factor app" theory, (https://12factor.net/ )
> Our Java-Web application logs to STDOUT,
> and JSW catches the stdout log, write into "wrapper.log"
>
> So, both of JSW log and application log into one file like below.
>
> STATUS | wrapper  | 2015/11/01 13:45:33.560 | JVM start......
> {"severity":"INFO","datetime":"2015-11-01 17:05:27 -0700","msg":"foobar"}
>
> But it is not convinient to use jq command line tool like this.
>
> $ cat test.log | jq .
> parse error: Invalid numeric literal at line 1, column 7
>
> If JSW log format support JSON,
>
> {"STATUS":"wrapper","datetime":"2015/11/01 13:45:33.560", "msg":"JVM
> start."}
> {"severity":"INFO","datetime":"2015-11-01 17:05:27 -0700","msg":"foobar"}
>
> I can use "jq" or any other tool for json !
>
> $ cat test.log | jq .
> {
>   "STATUS": "wrapper",
>   "datetime": "2015/11/01 13:45:33.560",
>   "msg": "JVM start."
> }
> {
>   "severity": "INFO",
>   "datetime": "2015-11-01 17:05:27 -0700",
>   "msg": "foobar"
> }
>
>
> Regards.
>
> ----
> Watanabe.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Please add "JSON" to logging format

[Y.Watanabe <na...@gm...>]

Hi.
I hope that JSW have "JSON" format configuration on "wrapper.console.format".

Belong to "12-factor app" theory, (https://12factor.net/ )
Our Java-Web application logs to STDOUT,
and JSW catches the stdout log, write into "wrapper.log"

So, both of JSW log and application log into one file like below.

STATUS | wrapper  | 2015/11/01 13:45:33.560 | JVM start......
{"severity":"INFO","datetime":"2015-11-01 17:05:27 -0700","msg":"foobar"}

But it is not convinient to use jq command line tool like this.

$ cat test.log | jq .
parse error: Invalid numeric literal at line 1, column 7

If JSW log format support JSON,

{"STATUS":"wrapper","datetime":"2015/11/01 13:45:33.560", "msg":"JVM start."}
{"severity":"INFO","datetime":"2015-11-01 17:05:27 -0700","msg":"foobar"}

I can use "jq" or any other tool for json !

$ cat test.log | jq .
{
  "STATUS": "wrapper",
  "datetime": "2015/11/01 13:45:33.560",
  "msg": "JVM start."
}
{
  "severity": "INFO",
  "datetime": "2015-11-01 17:05:27 -0700",
  "msg": "foobar"
}


Regards.

----
Watanabe.

[Wrapper-user] AUTO: Sahin Ilerisoy ist außer Haus (Rückkehr am 23.07.2017)

[<Sah...@vo...>]

Ich bin bis 23.07.2017 abwesend.




Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht  "Re:
[Wrapper-user] Java 9 support" gesendet am 7/4/2017 10:32:26 AM.

Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während
diese Person abwesend ist.

Re: [Wrapper-user] Java 9 support

[Thomas I. <Tho...@ma...>]

Hi Alexandre,

That’s great, thanks very much for going out of your way to test this.

Tom

From: Alexandre Klein [mailto:ale...@ta...]
Sent: Tuesday, July 04, 2017 9:32 AM
To: wra...@li...
Subject: Re: [Wrapper-user] Java 9 support

Hi Tom,
I downloaded Java 9+176 and ran the Wrapper (wrapper-windows-x86-64-3.5.32-pro) without any problem.
Please note Java 9+176 is a preview version. The final version will be released later. I'm optimistic that the Wrapper will be compatible with the final version of Java 9.
Regards,
Alexandre Klein

Alexandre Klein
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<http://www.tanukisoftware.com/>

On Fri, Jun 30, 2017 at 11:51 PM, Thomas Ibbotson <Tho...@ma...<mailto:Tho...@ma...>> wrote:
Hi all,

Can anyone confirm if the Java Service Wrapper currently supports Java 9, or if it is planned for a future release?

Thanks,
Tom

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Wrapper-user mailing list
Wra...@li...<mailto:Wra...@li...>
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] PPC Linkage in Java Service Wrapper?

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

William,

Sorry for the late reply.

Actually we already planned to no longer build the Wrapper for the PPC
architecture on macosx as Apple dropped its support since OS X 10.5. We
however want to make this change in our next major release (version 4.0).
Its release date has not been fixed yet, but it should be out in a few
months...
We rather want to avoid making this change in a minor release as there may
still be some users who expect support for this old architecture.

Best Regards,

Maxime

2017-06-20 12:09 GMT+09:00 William Woodruff <wi...@tu...>:

> Hi all,
>
> I'm a maintainer over at Homebrew [1], where we package a few Java
> programs that use the Java Service Wrapper. We've noticed with a few of
> them still contain PPC slices (even though OS X hasn't had a PPC release
> in over a decade), and that these PPC slices have broken linkages on
> modern versions of OS X.
>
> In particular, the PPC slices reference
> "/usr/lib/libgcc_s_ppc64.1.dylib", which hasn't been provided by
> OS X for quite a while and is currently breaking some of our
> linkage tests.
>
> We think the linkage might be being introduced in the JSW, based on
> one of our issues [2]. Could anybody shed some light on this and;
> if the root turns out to be the JSW, propose a more permanent
> fix for this (like removing PPC builds on OS X)?
>
> I'm currently working on a "fix" for this that just ignores this
> particular linkage, but it would be great to have an upstream
> correct it more permanently!
>
> Best,
> William Woodruff
> wi...@tu... / wi...@yo...
>
>
> [1]: https://github.com/Homebrew
> [2]: https://github.com/Homebrew/homebrew-core/pull/3613
> [3]: https://github.com/Homebrew/brew/pull/2805
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Java 9 support

[Alexandre K. <ale...@ta...>]

Hi Tom,

I downloaded Java 9+176 and ran the Wrapper
(wrapper-windows-x86-64-3.5.32-pro) without any problem.

Please note Java 9+176 is a preview version. The final version will be
released later. I'm optimistic that the Wrapper will be compatible with the
final version of Java 9.

Regards,
Alexandre Klein

Alexandre Klein
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

On Fri, Jun 30, 2017 at 11:51 PM, Thomas Ibbotson <
Tho...@ma...> wrote:

> Hi all,
>
>
>
> Can anyone confirm if the Java Service Wrapper currently supports Java 9,
> or if it is planned for a future release?
>
>
>
> Thanks,
>
> Tom
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] Java 9 support

[Thomas I. <Tho...@ma...>]

Hi all,

Can anyone confirm if the Java Service Wrapper currently supports Java 9, or if it is planned for a future release?

Thanks,
Tom

[Wrapper-user] Can the address for the wrapper.jvm.port be changed?

[Barbara Rosi-S. <bar...@mu...>]

Hello all.

With property wrapper.port, it is possible to set the address that the port
binds to via the wrapper.port.address property. I cannot find a similar way
to bind wrapper.jvm.port to a specific address. Is there a way to do that?

TIA,
B.

-- 
<http://www.mulesoft.com/>
*Barbara Rosi-Schwartz*, Customer Architect

2nd Floor, Fitzwilliam House, 10 St. Mary Axe, London, EC3A 8BF

O + <415.123.4567>44 20 7921 2391  M + <847.899.1565>44 7538 438 335

<https://www.linkedin.com/company/www.mulesoft.com>
<https://twitter.com/mulesoft>   <https://www.facebook.com/MuleSoft>
<https://www.youtube.com/user/mulesoftvids> We're hiring!
<http://www.mulesoft.com/careers>

[Wrapper-user] PPC Linkage in Java Service Wrapper?

[William W. <wi...@tu...>]

Hi all,

I'm a maintainer over at Homebrew [1], where we package a few Java
programs that use the Java Service Wrapper. We've noticed with a few of
them still contain PPC slices (even though OS X hasn't had a PPC release
in over a decade), and that these PPC slices have broken linkages on
modern versions of OS X.

In particular, the PPC slices reference
"/usr/lib/libgcc_s_ppc64.1.dylib", which hasn't been provided by
OS X for quite a while and is currently breaking some of our
linkage tests.

We think the linkage might be being introduced in the JSW, based on
one of our issues [2]. Could anybody shed some light on this and;
if the root turns out to be the JSW, propose a more permanent
fix for this (like removing PPC builds on OS X)?

I'm currently working on a "fix" for this that just ignores this
particular linkage, but it would be great to have an upstream
correct it more permanently!

Best,
William Woodruff
wi...@tu... / wi...@yo...


[1]: https://github.com/Homebrew
[2]: https://github.com/Homebrew/homebrew-core/pull/3613
[3]: https://github.com/Homebrew/brew/pull/2805

[Wrapper-user] Java Service Wrapper 3.5.32 released!

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

Hello everyone,

We are proud to announce the release of version 3.5.32 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] Shutdown timeout on a stopped process

[John P. <pot...@gm...>]

Hello Maxime!

Thank you for your answer and time. It turns out that it was a problem on
the application side and not with the Wrapper. It looks like Apache Karaf
was using org.tanukisoftware.wrapper.WrapperManager#signalStopping(5000*2)
[1] which I'm not sure why it was done but I think it overrides the
wrapper.shutdown.timeout timeout. I've submitted a pull request to have
that changed to Karaf's shutdown timeout and it seems to work. I've tested
the case where the timeout is exceeded and not.

Thanks again for everything,

John.


[1] https://github.com/apache/karaf/pull/290

On Thu, Mar 23, 2017 at 5:01 AM, Maxime <ma...@ta...> wrote:

> Hello John
>
> Thank you for your email.
>
> When requested to shutdown, the Wrapper asks the JVM to stop and waits for
> the JVM to respond that it is stopping, then wait until the process
> actually stopped.
>
> If you send a SIGSTOP to the JVM right after killing the Wrapper, then JVM
> will go in a paused state and may not be able to respond to the Wrapper. In
> this case the Wrapper will simply wait until wrapper.shutdown.timeout
> exceed and then will shutdown.
>
> https://wrapper.tanukisoftware.com/doc/english/prop-shutdown-timeout.html
>
> If you leave a few milliseconds between "kill $wrapper_pid" and "kill
> -STOP $java_pid", then the JVM may have enough time to signal it is
> stopping but will eventually go in a pause state before it can actually
> shutdown. In this case the Wrapper will simply wait until
> wrapper.jvm_exit.timeout exceed and then will shutdown.
>
> https://wrapper.tanukisoftware.com/doc/english/prop-jvm-exit-timeout.html
>
> I could test both cases with the testwrapper sample application that is
> provided with the Wrapper, but I could not reproduce a case where any of
> these timeouts are ignored. If I wait longer between the two command, the
> JVM will have enough time stop cleanly and the Wrapper will stop normally
> right after.
>
> *case 1 (almost same time):*
> kill $(head -n 1 testwrapper.pid) & kill -STOP $(head -n 1 jvm.pid)
>
> *case 2 (manually execute the command one after the other ~200ms between
> them):*
> kill $(head -n 1 testwrapper.pid)
> kill -STOP $(head -n 1 jvm.pid)
>
> Could you also have a try with the testwrapper sample application?
> Approximately how long do you wait between the two commands?
>
> PS: note that wrapper.ping.timeout.action=300 is not correct. This
> property should specify an action (RESTART, DEBUG, etc.) and not a number
> of seconds.
>
> Regards,
>
> Maxime
>
> On Tue, Mar 21, 2017 at 9:13 PM, John Poth <pot...@gm...> wrote:
>
>> Hi wrapper users,
>>
>> When using the service wrapper on Apache Karaf 4.0.8, I noticed that the
>> shutdown timeouts aren't respected when the underlying java process changes
>> status from 'Running' to 'Stopped' (this can be triggered by using the kill
>> -STOP karaf_java_pid) after the kill $wrapper_pid was called. This doesn't
>> allow for graceful shutdown in this scenario. I noticed the following line
>> in the attached logs:
>>
>> ERROR  | wrapper  | 2017/03/21 11:15:23 | Shutdown failed: Timed out
>> waiting for signal from JVM.
>>
>> which seems to indicated the timeout setting I'm looking for. I was
>> wondering if there was a way to configure this timeout? I've tried a couple
>> with no success (see attached conf):
>>
>> wrapper.jvm_cleanup.timeout=300
>> wrapper.shutdown.timeout=300
>> wrapper.ping.timeout=300
>> wrapper.startup_thread.timeout=300
>> wrapper.startup.timeout=300
>> wrapper.cpu.timeout=300
>> wrapper.jvm_exit.timeout=300
>> wrapper.ping.timeout.action=300
>>
>> To reproduce, simply execute a kill $wrapper_pid and right after that a
>> kill -STOP $java_pid and you'll see that the 300 seconds aren't taken into
>> account. Oddly, If you do a kill -STOP $java_pid first and then kill
>> $wrapper_pid you'll see the 300 seconds are taken into account.
>>
>> I'd be happy to provide a full reproducer with Apache Karaf just let me
>> know.
>>
>> Thanks a lot,
>>
>> John.
>>
>> PS: the required info
>>
>> Wrapper (Version 3.2.3)
>> Linux 4.7.3-200.fc24.x86_ GNU/Linux
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Shutdown timeout on a stopped process

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

Hello John

Thank you for your email.

When requested to shutdown, the Wrapper asks the JVM to stop and waits for
the JVM to respond that it is stopping, then wait until the process
actually stopped.

If you send a SIGSTOP to the JVM right after killing the Wrapper, then JVM
will go in a paused state and may not be able to respond to the Wrapper. In
this case the Wrapper will simply wait until wrapper.shutdown.timeout
exceed and then will shutdown.

https://wrapper.tanukisoftware.com/doc/english/prop-shutdown-timeout.html

If you leave a few milliseconds between "kill $wrapper_pid" and "kill -STOP
$java_pid", then the JVM may have enough time to signal it is stopping but
will eventually go in a pause state before it can actually shutdown. In
this case the Wrapper will simply wait until wrapper.jvm_exit.timeout
exceed and then will shutdown.

https://wrapper.tanukisoftware.com/doc/english/prop-jvm-exit-timeout.html

I could test both cases with the testwrapper sample application that is
provided with the Wrapper, but I could not reproduce a case where any of
these timeouts are ignored. If I wait longer between the two command, the
JVM will have enough time stop cleanly and the Wrapper will stop normally
right after.

*case 1 (almost same time):*
kill $(head -n 1 testwrapper.pid) & kill -STOP $(head -n 1 jvm.pid)

*case 2 (manually execute the command one after the other ~200ms between
them):*
kill $(head -n 1 testwrapper.pid)
kill -STOP $(head -n 1 jvm.pid)

Could you also have a try with the testwrapper sample application?
Approximately how long do you wait between the two commands?

PS: note that wrapper.ping.timeout.action=300 is not correct. This property
should specify an action (RESTART, DEBUG, etc.) and not a number of seconds.

Regards,

Maxime

On Tue, Mar 21, 2017 at 9:13 PM, John Poth <pot...@gm...> wrote:

> Hi wrapper users,
>
> When using the service wrapper on Apache Karaf 4.0.8, I noticed that the
> shutdown timeouts aren't respected when the underlying java process changes
> status from 'Running' to 'Stopped' (this can be triggered by using the kill
> -STOP karaf_java_pid) after the kill $wrapper_pid was called. This doesn't
> allow for graceful shutdown in this scenario. I noticed the following line
> in the attached logs:
>
> ERROR  | wrapper  | 2017/03/21 11:15:23 | Shutdown failed: Timed out
> waiting for signal from JVM.
>
> which seems to indicated the timeout setting I'm looking for. I was
> wondering if there was a way to configure this timeout? I've tried a couple
> with no success (see attached conf):
>
> wrapper.jvm_cleanup.timeout=300
> wrapper.shutdown.timeout=300
> wrapper.ping.timeout=300
> wrapper.startup_thread.timeout=300
> wrapper.startup.timeout=300
> wrapper.cpu.timeout=300
> wrapper.jvm_exit.timeout=300
> wrapper.ping.timeout.action=300
>
> To reproduce, simply execute a kill $wrapper_pid and right after that a
> kill -STOP $java_pid and you'll see that the 300 seconds aren't taken into
> account. Oddly, If you do a kill -STOP $java_pid first and then kill
> $wrapper_pid you'll see the 300 seconds are taken into account.
>
> I'd be happy to provide a full reproducer with Apache Karaf just let me
> know.
>
> Thanks a lot,
>
> John.
>
> PS: the required info
>
> Wrapper (Version 3.2.3)
> Linux 4.7.3-200.fc24.x86_ GNU/Linux
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] Shutdown timeout on a stopped process

[John P. <pot...@gm...>]

Hi wrapper users,

When using the service wrapper on Apache Karaf 4.0.8, I noticed that the
shutdown timeouts aren't respected when the underlying java process changes
status from 'Running' to 'Stopped' (this can be triggered by using the kill
-STOP karaf_java_pid) after the kill $wrapper_pid was called. This doesn't
allow for graceful shutdown in this scenario. I noticed the following line
in the attached logs:

ERROR  | wrapper  | 2017/03/21 11:15:23 | Shutdown failed: Timed out
waiting for signal from JVM.

which seems to indicated the timeout setting I'm looking for. I was
wondering if there was a way to configure this timeout? I've tried a couple
with no success (see attached conf):

wrapper.jvm_cleanup.timeout=300
wrapper.shutdown.timeout=300
wrapper.ping.timeout=300
wrapper.startup_thread.timeout=300
wrapper.startup.timeout=300
wrapper.cpu.timeout=300
wrapper.jvm_exit.timeout=300
wrapper.ping.timeout.action=300

To reproduce, simply execute a kill $wrapper_pid and right after that a
kill -STOP $java_pid and you'll see that the 300 seconds aren't taken into
account. Oddly, If you do a kill -STOP $java_pid first and then kill
$wrapper_pid you'll see the 300 seconds are taken into account.

I'd be happy to provide a full reproducer with Apache Karaf just let me
know.

Thanks a lot,

John.

PS: the required info

Wrapper (Version 3.2.3)
Linux 4.7.3-200.fc24.x86_ GNU/Linux

Re: [Wrapper-user] pause command on linux

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

Alexey,

I invite you to test the new version of the Wrapper (3.5.31). It now
supports the pause/resume actions from the Unix shell script.

The property PAUSABLE_MODE makes it possible to specify how the script file
communicates these actions to the running instance of the Wrapper. The
default is to use the SIGUSR1 and SIGUSR2 signals, but you may configure to
use the Wrapper command file instead. Note that using signals can be more
reactive and does not cause file permission issue. Please look at lines 99
and 105 of the script file for usage descriptions.

You may also have a look at the release notes for a full list of changes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

Please let me know if you have any questions or feedback.

Best Regards,

Maxime

On Wed, Jan 11, 2017 at 9:42 PM, Alexey Shetinin <av...@gm...> wrote:

> Thanks!
> I've updated script a little bit so it uses command file to issue
> pause/resume commands - works like a charm.
>
> On Wed, Jan 11, 2017 at 8:58 AM, Maxime <ma...@ta...> wrote:
>
>> Alexey,
>>
>> Thank you for your email.
>>
>> The script currently doesn't support the actions PAUSE and RESUME, but
>> you can trigger these actions from the command file.
>>
>> https://wrapper.tanukisoftware.com/doc/english/prop-commandfile.html
>>
>> Note that you should set wrapper.pausable to TRUE.
>>
>> There are two different methods to pause your application. In the first
>> method, the Wrapper requests the JVM to shutdown until the service is
>> resumed or stopped. In the second method, the Wrapper will send a service
>> control event to the JVM which can be handled in your code to put the
>> Application into a paused state. This can be controlled with the
>> wrapper.pausable.stop_jvm property.
>>
>> Please let me know if you have any questions.
>>
>> Regards,
>>
>> Maxime
>>
>> On Wed, Jan 11, 2017 at 3:25 AM, Alexey Shetinin <av...@gm...>
>> wrote:
>>
>>> I wonder if wrapper really support pause/resume commands on linux
>>> platform
>>> Currently, app (neither wrapper, according to wrapper log files) dont
>>> receive anything on pause or resume service commands, and according to
>>> launch script it also does nothing:
>>>
>>>
>>> pause() {
>>>     eval echo `gettext 'Pausing $APP_LONG_NAME.'`
>>> }
>>>
>>> resume() {
>>>     eval echo `gettext 'Resuming $APP_LONG_NAME.'`
>>> }
>>>
>>>
>>> --
>>>
>>> avs
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today. http://sdm.link/xeonphi
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
>
> --
>
> avs
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] Java Service Wrapper 3.5.31 released!

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

Hello everyone,

We are proud to announce the release of version 3.5.31 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] DEP / ASLR on Windows x86 binaries

[yi-jing c. <yij...@gm...>]

Hi Maxime,

Thanks for your response.

Do you have any schedule to release the build to enable ASLR and DEP/NX?

For ASLR and DEP/NX in Windows x86, add "/NXCOMPAT" and "/DYNAMICBASE" into
compile options can enable them.
I understand your consideration about to support different platforms, but
for Windows x86 that is simple to add the compile options.
Could you please consider to release the build which ASLR and DEP/NX are
enabled for Windows x86 first?

Thanks.

Best regards,
Gino

2017-01-12 16:59 GMT+08:00 Maxime <ma...@ta...>:

> Hello
>
> Thank you for your email.
>
> The Wrapper is indeed not compiled with the ASLR and DEP/NX compile flags
> in its current version.
> We will investigate about the possible implications this may have on the
> different platforms we support, and consider adding these protections on a
> future release.
>
> Best Regards,
>
> Maxime
>
>
> On Wed, Jan 11, 2017 at 4:08 PM, yi-jing chou <yij...@gm...>
> wrote:
>
>> Hi,
>>
>> I find the wrapper.exe and wrapper.dll for Windows x86 doesn't enable
>> DEP(Data Execution Prevention) and ASLR(Address space layout randomization).
>> It is a security risk and some malicious code can attack the program if
>> it doesn't enable DEP / ASLR.
>>
>> Do you have plan to enhance it?
>>
>>
>> Thank you
>> Gino Chou
>>
>>
>> DEP / ASLR on Windows x86 binaries
>>
>> ------------------------------------------------------------
>> ------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Problem to log in WARN level before stopping

[Fabian G. <fab...@mu...>]

Hello, Maxime!

I've managed to get what I want using your suggestion.

Thank you very much for your help!



On Mon, Feb 20, 2017 at 12:18 AM, Maxime <ma...@ta...> wrote:

> Hello Fabian
>
> Thank you for your email.
>
> The problem is that you are using WrapperManager.log() too early, when the
> backend is not yet ready to transmit the message to the Wrapper.
> One thing you could do is to subscribe to the WrapperLogFileChangedEvent
> event which is raised shortly after the backend is connected.
>
> First, your class has to implement WrapperEventListener:
>     https://wrapper.tanukisoftware.com/jdoc/index.html?org/tanukisoftware/
> wrapper/event/WrapperEventListener.html
>
> Basically you only need to implement the fired() method. It would look
> like this:
>
>
>
>
>
>
>
> *    public void fired( WrapperEvent event )    {        if (event
> instanceof WrapperLogFileChangedEvent )        {
> WrapperManager.log(WrapperManager.WRAPPER_LOG_LEVEL_WARN, "Bootstrap
> abruptly cancelled");        }    }*
>
> If you want to be sure that your message will only be logged once, you may
> stop listening for this event after the first call.
>
> Then you need to add your instance of WrapperEventListener
> (ErrorMuleContainerWrapper) with the appropriate mask. This can be done
> like this:
>
>
>
> *        ErrorMuleContainerWrapper emcw = new
> ErrorMuleContainerWrapper();        WrapperManager.addWrapperEventListener(
> emcw, WrapperEventListener.EVENT_FLAG_LOGGING );        start(emcw,
> remainingArgs);*
>
> https://wrapper.tanukisoftware.com/jdoc/org/tanukisoftware/wrapper/
> WrapperManager.html#addWrapperEventListener(org.
> tanukisoftware.wrapper.event.WrapperEventListener,%20long)
>
> Now your class should listen to the logging event which will be fired just
> after the backend is opened, when the Wrapper notifies the location of the
> log file. In response to this event, the fired() method will ask the
> WrapperManager to log your message. After that you may be able to use
> filters set up in your configuration file.
>
> Please let me know if this work.
>
> Best Regards,
>
> Maxime
>
>
> On Fri, Feb 17, 2017 at 10:32 PM, Fabian Gonzalez <
> fab...@mu...> wrote:
>
>> Hello, Maxime
>>
>> thank you very much for your answer!
>>
>> I'm trying to get the behaviour I want using filters. The problem is that
>> it is only responding to messages appended to stdout directly.
>>
>> If I set this filter:
>>
>> wrapper.filter.trigger.1=Bootstrap abruptly cancelled
>> wrapper.filter.action.1=SHUTDOWN
>> wrapper.filter.message.1=Shutting down...
>>
>> and from java I add the following code:
>>
>> start(new ErrorMuleContainerWrapper(), remainingArgs);
>> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
>> cancelled");
>>
>> It will not shutdown.
>>
>> It will not shutdown even if I use:
>>
>> start(new ErrorMuleContainerWrapper(), remainingArgs);
>> WrapperManager.log(WRAPPER_LOG_LEVEL_INFO, "Bootstrap abruptly
>> cancelled");
>>
>> It will trigger the event when I add the following code:
>>
>> start(new ErrorMuleContainerWrapper(), remainingArgs);
>> System.out.println("Bootstrap abruptly cancelled")
>>
>> But in that case, with a WARN level of logging, no message will be
>> displayed (even the message set in wrapper.filter.message.1). With a log
>> level of INFO everything is displayed as expected.
>>
>> If I add the following code:
>>
>> start(new ErrorMuleContainerWrapper(), remainingArgs);
>> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
>> cancelled");
>> System.out.println("Bootstrap abruptly cancelled")
>>
>> the shutdown will be triggered but no message is displayed in WARN level
>> (this is the same situation as the one when I try to use log without
>> setting an Thread,.sleep).
>>
>> I was trying to use other options, but I am being unable to DEBUG or even
>> SUSPEND the application and getting the backend to receive the log in WARN
>> level and print it on screen or the log file (or even display the filter
>> message in WARN level).
>>
>> What's even more curious is that if I use the following code:
>>
>> start(new ErrorMuleContainerWrapper(), remainingArgs);
>> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
>> cancelled");
>> while(true);
>>
>> The message is not displayed (I suspect it is never flushed in the
>> backend).
>> The only way I'm still getting it to work is like this:
>>
>> start(new ErrorMuleContainerWrapper(), remainingArgs);
>> Thread.sleep(1000);
>> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
>> cancelled");
>>
>> Am I missing something about the use of filters?
>>
>> Thanks in advance!
>>
>> On Thu, Feb 16, 2017 at 10:51 PM, Maxime <ma...@ta...>
>> wrote:
>>
>>> Hello Fabian
>>>
>>> Thank you for your email.
>>>
>>> What about using filters ? Filters work by searching for sequences of
>>> text in log outputs of the JVM. When the specified pattern is found,
>>> several actions can then be taken. For example you can stop the Wrapper or
>>> trigger a user event that can be transmitted back to your application. In
>>> your case, this is probably a good way to confirm that your message is
>>> logged.
>>>
>>> Please check our documentation to know more about filters:
>>> https://wrapper.tanukisoftware.com/doc/english/prop-filter-x-n.html
>>>
>>> I remain at your disposal should you have any questions.
>>>
>>> Best Regards,
>>>
>>> Maxime
>>>
>>> On Thu, Feb 16, 2017 at 12:35 AM, Fabian Gonzalez <
>>> fab...@mu...> wrote:
>>>
>>>> Hello,
>>>>
>>>> This is my first mail so greetings to all.
>>>>
>>>> I'm a having the following issue.
>>>> The log level is set to WARN in wrapper.conf both for the console and
>>>> the log file.
>>>>
>>>> Before starting the wrapper through WrapperManager.start, I should
>>>> perform a verification. In case this verification fails, I have to start
>>>> the java side of the wrapper only to log to wrapper log file as well as the
>>>> console.
>>>> So, what I do is perform WrapperManager.start WrapperManager.log and
>>>> the WrapperManger.stop.
>>>> The issue I'm having is that I have no way to verify that the socket
>>>> connection to the wrapper backend is actually opened, so if I perform:
>>>>
>>>> WrapperManager.start
>>>> WrapperManager.log
>>>> WrapperManager.stop
>>>>
>>>> the log command is not sent to the backend before stopping the java
>>>> side of the application.
>>>>
>>>> If I use something like this:
>>>>
>>>> WrapperManager.start
>>>> Thread.sleep(10000)
>>>> WrapperManager.log
>>>> WrapperManager.stop
>>>>
>>>> I manage to get the the message logged, but I am being confident that
>>>> the sleep time is the appropriate (kind of a hack).
>>>>
>>>> From:
>>>>
>>>> https://sourceforge.net/p/wrapper/mailman/message/30555007/
>>>>
>>>> that for levels above INFO, that's the only way I have to log one of my
>>>> messages to the logfile and the console as it is managed by the backend. Is
>>>> there any other way apart from the sleep to make sure that the message is
>>>> logged before sending the WrapperManager.stop.
>>>>
>>>> Thanks in advance!
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Wrapper-user mailing list
>>>> Wra...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>>
>>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Problem to log in WARN level before stopping

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

Hello Fabian

Thank you for your email.

The problem is that you are using WrapperManager.log() too early, when the
backend is not yet ready to transmit the message to the Wrapper.
One thing you could do is to subscribe to the WrapperLogFileChangedEvent
event which is raised shortly after the backend is connected.

First, your class has to implement WrapperEventListener:

https://wrapper.tanukisoftware.com/jdoc/index.html?org/tanukisoftware/wrapper/event/WrapperEventListener.html

Basically you only need to implement the fired() method. It would look like
this:







*    public void fired( WrapperEvent event )    {        if (event
instanceof WrapperLogFileChangedEvent )        {
WrapperManager.log(WrapperManager.WRAPPER_LOG_LEVEL_WARN, "Bootstrap
abruptly cancelled");        }    }*

If you want to be sure that your message will only be logged once, you may
stop listening for this event after the first call.

Then you need to add your instance of WrapperEventListener
(ErrorMuleContainerWrapper) with the appropriate mask. This can be done
like this:



*        ErrorMuleContainerWrapper emcw = new
ErrorMuleContainerWrapper();        WrapperManager.addWrapperEventListener(
emcw, WrapperEventListener.EVENT_FLAG_LOGGING );        start(emcw,
remainingArgs);*

https://wrapper.tanukisoftware.com/jdoc/org/tanukisoftware/wrapper/WrapperManager.html#addWrapperEventListener(org.tanukisoftware.wrapper.event.WrapperEventListener,%20long)

Now your class should listen to the logging event which will be fired just
after the backend is opened, when the Wrapper notifies the location of the
log file. In response to this event, the fired() method will ask the
WrapperManager to log your message. After that you may be able to use
filters set up in your configuration file.

Please let me know if this work.

Best Regards,

Maxime


On Fri, Feb 17, 2017 at 10:32 PM, Fabian Gonzalez <
fab...@mu...> wrote:

> Hello, Maxime
>
> thank you very much for your answer!
>
> I'm trying to get the behaviour I want using filters. The problem is that
> it is only responding to messages appended to stdout directly.
>
> If I set this filter:
>
> wrapper.filter.trigger.1=Bootstrap abruptly cancelled
> wrapper.filter.action.1=SHUTDOWN
> wrapper.filter.message.1=Shutting down...
>
> and from java I add the following code:
>
> start(new ErrorMuleContainerWrapper(), remainingArgs);
> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
> cancelled");
>
> It will not shutdown.
>
> It will not shutdown even if I use:
>
> start(new ErrorMuleContainerWrapper(), remainingArgs);
> WrapperManager.log(WRAPPER_LOG_LEVEL_INFO, "Bootstrap abruptly
> cancelled");
>
> It will trigger the event when I add the following code:
>
> start(new ErrorMuleContainerWrapper(), remainingArgs);
> System.out.println("Bootstrap abruptly cancelled")
>
> But in that case, with a WARN level of logging, no message will be
> displayed (even the message set in wrapper.filter.message.1). With a log
> level of INFO everything is displayed as expected.
>
> If I add the following code:
>
> start(new ErrorMuleContainerWrapper(), remainingArgs);
> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
> cancelled");
> System.out.println("Bootstrap abruptly cancelled")
>
> the shutdown will be triggered but no message is displayed in WARN level
> (this is the same situation as the one when I try to use log without
> setting an Thread,.sleep).
>
> I was trying to use other options, but I am being unable to DEBUG or even
> SUSPEND the application and getting the backend to receive the log in WARN
> level and print it on screen or the log file (or even display the filter
> message in WARN level).
>
> What's even more curious is that if I use the following code:
>
> start(new ErrorMuleContainerWrapper(), remainingArgs);
> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
> cancelled");
> while(true);
>
> The message is not displayed (I suspect it is never flushed in the
> backend).
> The only way I'm still getting it to work is like this:
>
> start(new ErrorMuleContainerWrapper(), remainingArgs);
> Thread.sleep(1000);
> WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly
> cancelled");
>
> Am I missing something about the use of filters?
>
> Thanks in advance!
>
> On Thu, Feb 16, 2017 at 10:51 PM, Maxime <ma...@ta...>
> wrote:
>
>> Hello Fabian
>>
>> Thank you for your email.
>>
>> What about using filters ? Filters work by searching for sequences of
>> text in log outputs of the JVM. When the specified pattern is found,
>> several actions can then be taken. For example you can stop the Wrapper or
>> trigger a user event that can be transmitted back to your application. In
>> your case, this is probably a good way to confirm that your message is
>> logged.
>>
>> Please check our documentation to know more about filters:
>> https://wrapper.tanukisoftware.com/doc/english/prop-filter-x-n.html
>>
>> I remain at your disposal should you have any questions.
>>
>> Best Regards,
>>
>> Maxime
>>
>> On Thu, Feb 16, 2017 at 12:35 AM, Fabian Gonzalez <
>> fab...@mu...> wrote:
>>
>>> Hello,
>>>
>>> This is my first mail so greetings to all.
>>>
>>> I'm a having the following issue.
>>> The log level is set to WARN in wrapper.conf both for the console and
>>> the log file.
>>>
>>> Before starting the wrapper through WrapperManager.start, I should
>>> perform a verification. In case this verification fails, I have to start
>>> the java side of the wrapper only to log to wrapper log file as well as the
>>> console.
>>> So, what I do is perform WrapperManager.start WrapperManager.log and the
>>> WrapperManger.stop.
>>> The issue I'm having is that I have no way to verify that the socket
>>> connection to the wrapper backend is actually opened, so if I perform:
>>>
>>> WrapperManager.start
>>> WrapperManager.log
>>> WrapperManager.stop
>>>
>>> the log command is not sent to the backend before stopping the java side
>>> of the application.
>>>
>>> If I use something like this:
>>>
>>> WrapperManager.start
>>> Thread.sleep(10000)
>>> WrapperManager.log
>>> WrapperManager.stop
>>>
>>> I manage to get the the message logged, but I am being confident that
>>> the sleep time is the appropriate (kind of a hack).
>>>
>>> From:
>>>
>>> https://sourceforge.net/p/wrapper/mailman/message/30555007/
>>>
>>> that for levels above INFO, that's the only way I have to log one of my
>>> messages to the logfile and the console as it is managed by the backend. Is
>>> there any other way apart from the sleep to make sure that the message is
>>> logged before sending the WrapperManager.stop.
>>>
>>> Thanks in advance!
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Problem to log in WARN level before stopping

[Fabian G. <fab...@mu...>]

Hello, Maxime

thank you very much for your answer!

I'm trying to get the behaviour I want using filters. The problem is that
it is only responding to messages appended to stdout directly.

If I set this filter:

wrapper.filter.trigger.1=Bootstrap abruptly cancelled
wrapper.filter.action.1=SHUTDOWN
wrapper.filter.message.1=Shutting down...

and from java I add the following code:

start(new ErrorMuleContainerWrapper(), remainingArgs);
WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly cancelled");

It will not shutdown.

It will not shutdown even if I use:

start(new ErrorMuleContainerWrapper(), remainingArgs);
WrapperManager.log(WRAPPER_LOG_LEVEL_INFO, "Bootstrap abruptly cancelled");

It will trigger the event when I add the following code:

start(new ErrorMuleContainerWrapper(), remainingArgs);
System.out.println("Bootstrap abruptly cancelled")

But in that case, with a WARN level of logging, no message will be
displayed (even the message set in wrapper.filter.message.1). With a log
level of INFO everything is displayed as expected.

If I add the following code:

start(new ErrorMuleContainerWrapper(), remainingArgs);
WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly cancelled");
System.out.println("Bootstrap abruptly cancelled")

the shutdown will be triggered but no message is displayed in WARN level
(this is the same situation as the one when I try to use log without
setting an Thread,.sleep).

I was trying to use other options, but I am being unable to DEBUG or even
SUSPEND the application and getting the backend to receive the log in WARN
level and print it on screen or the log file (or even display the filter
message in WARN level).

What's even more curious is that if I use the following code:

start(new ErrorMuleContainerWrapper(), remainingArgs);
WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly cancelled");
while(true);

The message is not displayed (I suspect it is never flushed in the backend).
The only way I'm still getting it to work is like this:

start(new ErrorMuleContainerWrapper(), remainingArgs);
Thread.sleep(1000);
WrapperManager.log(WRAPPER_LOG_LEVEL_WARN, "Bootstrap abruptly cancelled");

Am I missing something about the use of filters?

Thanks in advance!

On Thu, Feb 16, 2017 at 10:51 PM, Maxime <ma...@ta...> wrote:

> Hello Fabian
>
> Thank you for your email.
>
> What about using filters ? Filters work by searching for sequences of text
> in log outputs of the JVM. When the specified pattern is found, several
> actions can then be taken. For example you can stop the Wrapper or trigger
> a user event that can be transmitted back to your application. In your
> case, this is probably a good way to confirm that your message is logged.
>
> Please check our documentation to know more about filters:
> https://wrapper.tanukisoftware.com/doc/english/prop-filter-x-n.html
>
> I remain at your disposal should you have any questions.
>
> Best Regards,
>
> Maxime
>
> On Thu, Feb 16, 2017 at 12:35 AM, Fabian Gonzalez <
> fab...@mu...> wrote:
>
>> Hello,
>>
>> This is my first mail so greetings to all.
>>
>> I'm a having the following issue.
>> The log level is set to WARN in wrapper.conf both for the console and the
>> log file.
>>
>> Before starting the wrapper through WrapperManager.start, I should
>> perform a verification. In case this verification fails, I have to start
>> the java side of the wrapper only to log to wrapper log file as well as the
>> console.
>> So, what I do is perform WrapperManager.start WrapperManager.log and the
>> WrapperManger.stop.
>> The issue I'm having is that I have no way to verify that the socket
>> connection to the wrapper backend is actually opened, so if I perform:
>>
>> WrapperManager.start
>> WrapperManager.log
>> WrapperManager.stop
>>
>> the log command is not sent to the backend before stopping the java side
>> of the application.
>>
>> If I use something like this:
>>
>> WrapperManager.start
>> Thread.sleep(10000)
>> WrapperManager.log
>> WrapperManager.stop
>>
>> I manage to get the the message logged, but I am being confident that the
>> sleep time is the appropriate (kind of a hack).
>>
>> From:
>>
>> https://sourceforge.net/p/wrapper/mailman/message/30555007/
>>
>> that for levels above INFO, that's the only way I have to log one of my
>> messages to the logfile and the console as it is managed by the backend. Is
>> there any other way apart from the sleep to make sure that the message is
>> logged before sending the WrapperManager.stop.
>>
>> Thanks in advance!
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Problem to log in WARN level before stopping

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

Hello Fabian

Thank you for your email.

What about using filters ? Filters work by searching for sequences of text
in log outputs of the JVM. When the specified pattern is found, several
actions can then be taken. For example you can stop the Wrapper or trigger
a user event that can be transmitted back to your application. In your
case, this is probably a good way to confirm that your message is logged.

Please check our documentation to know more about filters:
https://wrapper.tanukisoftware.com/doc/english/prop-filter-x-n.html

I remain at your disposal should you have any questions.

Best Regards,

Maxime

On Thu, Feb 16, 2017 at 12:35 AM, Fabian Gonzalez <
fab...@mu...> wrote:

> Hello,
>
> This is my first mail so greetings to all.
>
> I'm a having the following issue.
> The log level is set to WARN in wrapper.conf both for the console and the
> log file.
>
> Before starting the wrapper through WrapperManager.start, I should perform
> a verification. In case this verification fails, I have to start the java
> side of the wrapper only to log to wrapper log file as well as the console.
> So, what I do is perform WrapperManager.start WrapperManager.log and the
> WrapperManger.stop.
> The issue I'm having is that I have no way to verify that the socket
> connection to the wrapper backend is actually opened, so if I perform:
>
> WrapperManager.start
> WrapperManager.log
> WrapperManager.stop
>
> the log command is not sent to the backend before stopping the java side
> of the application.
>
> If I use something like this:
>
> WrapperManager.start
> Thread.sleep(10000)
> WrapperManager.log
> WrapperManager.stop
>
> I manage to get the the message logged, but I am being confident that the
> sleep time is the appropriate (kind of a hack).
>
> From:
>
> https://sourceforge.net/p/wrapper/mailman/message/30555007/
>
> that for levels above INFO, that's the only way I have to log one of my
> messages to the logfile and the console as it is managed by the backend. Is
> there any other way apart from the sleep to make sure that the message is
> logged before sending the WrapperManager.stop.
>
> Thanks in advance!
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] Problem to log in WARN level before stopping

[Fabian G. <fab...@mu...>]

Hello,

This is my first mail so greetings to all.

I'm a having the following issue.
The log level is set to WARN in wrapper.conf both for the console and the
log file.

Before starting the wrapper through WrapperManager.start, I should perform
a verification. In case this verification fails, I have to start the java
side of the wrapper only to log to wrapper log file as well as the console.
So, what I do is perform WrapperManager.start WrapperManager.log and the
WrapperManger.stop.
The issue I'm having is that I have no way to verify that the socket
connection to the wrapper backend is actually opened, so if I perform:

WrapperManager.start
WrapperManager.log
WrapperManager.stop

the log command is not sent to the backend before stopping the java side of
the application.

If I use something like this:

WrapperManager.start
Thread.sleep(10000)
WrapperManager.log
WrapperManager.stop

I manage to get the the message logged, but I am being confident that the
sleep time is the appropriate (kind of a hack).

From:

https://sourceforge.net/p/wrapper/mailman/message/30555007/

that for levels above INFO, that's the only way I have to log one of my
messages to the logfile and the console as it is managed by the backend. Is
there any other way apart from the sleep to make sure that the message is
logged before sending the WrapperManager.stop.

Thanks in advance!

Re: [Wrapper-user] using the Wrapper 32-bit to start 64 bit JVM

[Alexandre K. <ale...@ta...>]

Afif,

Thank you for your email.

When using the Wrapper 32-bit with a 64-bit JVM, the Wrapper native library
(dll) will not be loaded. Therefore, the Wrapper will not work as expected.

Please note, from version 3.5.31 of the Wrapper, we will stop allowing the
Wrapper to run when versions of the Wrapper executable, native library and
jar file do not match.

Regards,
Alexandre Klein


Alexandre Klein
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

On Mon, Feb 13, 2017 at 8:00 PM, Afif Bouzidi <afi...@gm...>
wrote:

> Hello,
>
>
>
> Currently I am using the Wrapper 32-bit to start 64 bit JVM. The java
> application seems to work correctly
>
>
>
> Is there any hidden problem I should be worry about?
>
>
>
> Thank you for your time and consideration.
>
>
>
> Sincerely,
>
> Afif Bouzidi
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] using the Wrapper 32-bit to start 64 bit JVM

[Afif B. <afi...@gm...>]

Hello,



Currently I am using the Wrapper 32-bit to start 64 bit JVM. The java
application seems to work correctly



Is there any hidden problem I should be worry about?



Thank you for your time and consideration.



Sincerely,

Afif Bouzidi

Re: [Wrapper-user] TR: information request

[Alexandre K. <ale...@ta...>]

Houssem,

Thank you for your message.

The bit of the Wrapper must match the bit of the JVM. The 32-bit Wrapper
will only work on a 32-bit JVM.

On a 64-bit OS, you can install a 32-bit JVM and use the 32-bit Wrapper.

Using a 32-bit JVM vs 64-bit JVM has some advantages and disadvantages,
such as a lower amount of memory available on 32-bit JVM. A quick search on
Google should give you more information.

Regards,
Alexandre Klein

Alexandre Klein
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

On Thu, Jan 26, 2017 at 5:35 PM, houssem slimi <sli...@ho...>
wrote:

>
>
> Hello,
>
>
> I would like to know if I use wrapper 32 bit in JVM 64 bit I can have
> problem of performance in my application.
>
>
> best regards
>
> Houssem Slimi
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] TR: information request

[houssem s. <sli...@ho...>]

Hello,


I would like to know if I use wrapper 32 bit in JVM 64 bit I can have problem of performance in my application.


best regards

Houssem Slimi