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

[Wrapper-user] Java Service Wrapper 3.5.12

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

Hi all,
I would like to announce the release of 3.5.12 of the Java Service
Wrapper.  This version is primarily a bug fix release:

*) We fixed a security problem on UNIX platforms where files created by
the JVM and Wrapper had access which was too open unless specifically
configured otherwise.

*) Improved output when the WrapperJarApp helper class is used with an
non-executable jar.

*) Improve parsing of log formats.

An a few other minor issues.

Please see the release notes for a full list of changes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html#3.5.12

The full release is available on the Wrapper site:
http://wrapper.tanukisoftware.com/doc/english/download.jsp

In addition to our internal testing, when release new versions, they
are released as "Unstable" for a period of approximately 2 weeks.   If
after that time we have not received any reports of critical problems
the version will be upgraded to "Stable" on the site.  This makes it
possible for you to decide whether you would like to try out the
latest and greatest version or stick with a safer known version for
deployment with your applications.

As always, please let us know how we can continue to improve the Java
Service Wrapper to meet your needs.

Sincerely,
Leif Mortenson
Tanuki Software, Ltd.
http://www.tanukisoftware.com

Re: [Wrapper-user] Notification for JVM Hungs

[karthik K. <kar...@gm...>]

Hi Leif,

Thanks again for ur reply!!!

Checked the version.. Its 3.2.3 :( .. A Old version...
Is there a similar command to find  the Edition!!!.. Whether its a Standard
edition or a Proff edition.. or..is there somewhere this could be
mentioned?? 

Now as i have a old version...coming to something You mentioned the below in
first mail..

When the JVM is restarted, the first JVM is first shutdown.    What 
version of the Wrapper are you using though?  There was a problem 
fixed in 3.3.1 where the Wrapper was sometimes failing to actually 
kill a JVM process which it decided to kill.   If you are having this 
problem then you will need to upgrade.   Depending on the OS you are 
running, it is also possible that the ports are still in a locked 
state until their timeout has expired

How can i actually find if the Wrapper was sometimes failing to kill a JVM
Process which it decided to kill...??? How do i identify this problem...
This will give me a picture to take it to the customer for a upgrade of
version!!!

I see that the JVM id increments by 1 when JVM is hung and restart.....But
the JVM id is JVM1 
when i stop and start the wrapper.. What could be the effect of this.. So,
does this mean that when JVM is actually hung and restarted by itself.. it
does not cleanup the temp files/memory

Thanks in advance!!!
Karthik Ananthakrishnan


Leif Mortenson-3 wrote:
> 
> Karthik,
> You can get the Wrapper version by running "wrapper -v" from the
> command line.   If you don't get a version then it is older than 3.3.0
> as the version used to be displayed differently.
> 
> The ability to execute external commands is a Professional Edition
> feature so that is not going to be possible with the Standard or
> Community Editions.
> 
> The message that you are seeing about the JVM being frozen is being
> generated by the Wrapper binary as it kills the Java process.  For
> this reason there is not a way for you to run other code unless you
> use the Professional Edition.  If you want to try it out, you can get
> a one month trial license using the button on the top right of the
> wrapper's page:
> http://wrapper.tanukisoftware.com/
> 
> The Wrapper has several checks that it uses to monitor the JVM.  The
> one that is timing out in your case is a ping test.  The Wrapper, by
> default sends a ping to the JVM and then expects a reply almost
> immediately.  The ping reply can be delayed by heavily loaded systems,
> so the Wrapper waits for up to the wrapper.ping.timeout (30 second
> default) before deciding that the JVM will not reply.  At that point,
> it assumes it is frozen and starts the restart process.   This is
> described in more detail with a diagram on the following page:
> http://wrapper.tanukisoftware.com/doc/english/prop-ping-timeout.html
> 
> Cheers,
> Leif
> 
> On Sun, Sep 11, 2011 at 8:06 PM, karthik Krishnan <kar...@gm...>
> wrote:
>>
>> Hi Leif,
>>
>> thanks a ton for ur reply!!!
>>
>> The appl. is installed a year ago in the client machine by someone
>> unknown
>> to me.. So i really dont know the Wrapper edition and version..
>>
>> Can u please tell me How to find that.. is there any command i can try to
>> find the version and edition.. which will be helpful in my case to do
>> somethng for the JVM Hungs..
>>
>> Also.. Can you tell me if its possible to invoke external appl. in the
>> standard edition..
>> Or can u tell me what is the file that invokes the wrapper to restart the
>> service.. or where does the Wrapper concludes that JVM is Hung!!!.. i see
>> there is a log that JVM is Hung!!!.. Which file does that writing into
>> log....If i know this.. i can try to invoke a external prog from that
>> point
>> before it writes JVM hung to wrapper..
>>
>> Thanks in advance
>>
>> Karthik
>>
>> Leif Mortenson-3 wrote:
>>>
>>> Karthik,
>>> JVM restarts like this are usually caused by the JVM itself freezing
>>> and needing to be restarted.   There are however times where the JVM
>>> is temporarily frozen by heavy disk IO or memory swapping.   If you
>>> are seeing this problem repeatedly, I would suggest setting the
>>> wrapper.ping.timeout to a longer value and seeing if the JVM recovers
>>> on its own.   Whether it is a permanent or temporary freeze, there is
>>> a problem that needs to be resolved as your application will not be
>>> responsive to user requests when it is unable to respond to the
>>> Wrapper's pings.
>>>
>>> When the JVM is restarted, the first JVM is first shutdown.    What
>>> version of the Wrapper are you using though?  There was a problem
>>> fixed in 3.3.1 where the Wrapper was sometimes failing to actually
>>> kill a JVM process which it decided to kill.   If you are having this
>>> problem then you will need to upgrade.   Depending on the OS you are
>>> running, it is also possible that the ports are still in a locked
>>> state until their timeout has expired.   In this case, you may want to
>>> try increasing the delay before launching the second JVM instant.  You
>>> can do this with the wrapper.restart.delay property.
>>> http://wrapper.tanukisoftware.com/doc/english/prop-restart-delay.html
>>>
>>> The professional edition of the Wrapper makes it possible for you to
>>> launch an external process at various points in the Wrapper and JVM
>>> lifecycle.  This includes just before a JVM restart:
>>> http://wrapper.tanukisoftware.com/doc/english/props-event.html#command
>>>
>>> Please let me know how these options work for you.
>>>
>>> Cheers,
>>> Leif
>>>
>>>
>>> On Sun, Sep 11, 2011 at 5:30 AM, karthik Krishnan <kar...@gm...>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Reposting due to some mailing list subscription issue!!! Please ignore
>>>> if
>>>> this is repeated. Inconvenience regretted..
>>>>
>>>> I m facing issues like, when the JVM Hungs and restarts with below
>>>> message..
>>>> sometimes, few services are not bound properly and giving us some
>>>> issues..
>>>>
>>>> wrapper  | JVM appears hung: Timed out waiting for signal from JVM.
>>>> wrapper  | Java Virtual Machine did not exit on request, terminated
>>>> wrapper  | Launching a JVM...
>>>> jvm 2    | Initializing...
>>>>
>>>> So, i need to write a program which will be called whenever the JVM
>>>> Hungs
>>>> and restarts by itself to check if the services are bound properly. for
>>>> that
>>>> i need to know, from where can i invoke this program.. (Likely to call
>>>> a
>>>> batch file from somewhere..).. Need to know which file and steps the
>>>> Wrapper
>>>> calls to restarts the service..
>>>>
>>>> Or, is there any property that can be set to send a notification by
>>>> mail
>>>> when there is a JVM Hung.. I know there is a email Notification
>>>> available
>>>> in
>>>> prof edition. We are using a standard edition.
>>>> Can someone help me or let me know if u have done something similar to
>>>> this.
>>>>
>>>> Someone can throw light on why this happens.. and what could be done to
>>>> avoid such JVM Hang and restarts.
>>>>
>>>> Any help in this regard will be useful
>>>>
>>>> Thanks in Advance,
>>>>
>>>> Regards,
>>>> Karthik Krishnan
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage 
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 
> 

-- 
View this message in context: http://old.nabble.com/Notification-for-JVM-Hungs-tp32421697p32443616.html
Sent from the Java Service Wrapper mailing list archive at Nabble.com.

Re: [Wrapper-user] Notification for JVM Hungs

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

Karthik,
You can get the Wrapper version by running "wrapper -v" from the
command line.   If you don't get a version then it is older than 3.3.0
as the version used to be displayed differently.

The ability to execute external commands is a Professional Edition
feature so that is not going to be possible with the Standard or
Community Editions.

The message that you are seeing about the JVM being frozen is being
generated by the Wrapper binary as it kills the Java process.  For
this reason there is not a way for you to run other code unless you
use the Professional Edition.  If you want to try it out, you can get
a one month trial license using the button on the top right of the
wrapper's page:
http://wrapper.tanukisoftware.com/

The Wrapper has several checks that it uses to monitor the JVM.  The
one that is timing out in your case is a ping test.  The Wrapper, by
default sends a ping to the JVM and then expects a reply almost
immediately.  The ping reply can be delayed by heavily loaded systems,
so the Wrapper waits for up to the wrapper.ping.timeout (30 second
default) before deciding that the JVM will not reply.  At that point,
it assumes it is frozen and starts the restart process.   This is
described in more detail with a diagram on the following page:
http://wrapper.tanukisoftware.com/doc/english/prop-ping-timeout.html

Cheers,
Leif

On Sun, Sep 11, 2011 at 8:06 PM, karthik Krishnan <kar...@gm...> wrote:
>
> Hi Leif,
>
> thanks a ton for ur reply!!!
>
> The appl. is installed a year ago in the client machine by someone unknown
> to me.. So i really dont know the Wrapper edition and version..
>
> Can u please tell me How to find that.. is there any command i can try to
> find the version and edition.. which will be helpful in my case to do
> somethng for the JVM Hungs..
>
> Also.. Can you tell me if its possible to invoke external appl. in the
> standard edition..
> Or can u tell me what is the file that invokes the wrapper to restart the
> service.. or where does the Wrapper concludes that JVM is Hung!!!.. i see
> there is a log that JVM is Hung!!!.. Which file does that writing into
> log....If i know this.. i can try to invoke a external prog from that point
> before it writes JVM hung to wrapper..
>
> Thanks in advance
>
> Karthik
>
> Leif Mortenson-3 wrote:
>>
>> Karthik,
>> JVM restarts like this are usually caused by the JVM itself freezing
>> and needing to be restarted.   There are however times where the JVM
>> is temporarily frozen by heavy disk IO or memory swapping.   If you
>> are seeing this problem repeatedly, I would suggest setting the
>> wrapper.ping.timeout to a longer value and seeing if the JVM recovers
>> on its own.   Whether it is a permanent or temporary freeze, there is
>> a problem that needs to be resolved as your application will not be
>> responsive to user requests when it is unable to respond to the
>> Wrapper's pings.
>>
>> When the JVM is restarted, the first JVM is first shutdown.    What
>> version of the Wrapper are you using though?  There was a problem
>> fixed in 3.3.1 where the Wrapper was sometimes failing to actually
>> kill a JVM process which it decided to kill.   If you are having this
>> problem then you will need to upgrade.   Depending on the OS you are
>> running, it is also possible that the ports are still in a locked
>> state until their timeout has expired.   In this case, you may want to
>> try increasing the delay before launching the second JVM instant.  You
>> can do this with the wrapper.restart.delay property.
>> http://wrapper.tanukisoftware.com/doc/english/prop-restart-delay.html
>>
>> The professional edition of the Wrapper makes it possible for you to
>> launch an external process at various points in the Wrapper and JVM
>> lifecycle.  This includes just before a JVM restart:
>> http://wrapper.tanukisoftware.com/doc/english/props-event.html#command
>>
>> Please let me know how these options work for you.
>>
>> Cheers,
>> Leif
>>
>>
>> On Sun, Sep 11, 2011 at 5:30 AM, karthik Krishnan <kar...@gm...>
>> wrote:
>>>
>>> Hi,
>>>
>>> Reposting due to some mailing list subscription issue!!! Please ignore if
>>> this is repeated. Inconvenience regretted..
>>>
>>> I m facing issues like, when the JVM Hungs and restarts with below
>>> message..
>>> sometimes, few services are not bound properly and giving us some
>>> issues..
>>>
>>> wrapper  | JVM appears hung: Timed out waiting for signal from JVM.
>>> wrapper  | Java Virtual Machine did not exit on request, terminated
>>> wrapper  | Launching a JVM...
>>> jvm 2    | Initializing...
>>>
>>> So, i need to write a program which will be called whenever the JVM Hungs
>>> and restarts by itself to check if the services are bound properly. for
>>> that
>>> i need to know, from where can i invoke this program.. (Likely to call a
>>> batch file from somewhere..).. Need to know which file and steps the
>>> Wrapper
>>> calls to restarts the service..
>>>
>>> Or, is there any property that can be set to send a notification by mail
>>> when there is a JVM Hung.. I know there is a email Notification available
>>> in
>>> prof edition. We are using a standard edition.
>>> Can someone help me or let me know if u have done something similar to
>>> this.
>>>
>>> Someone can throw light on why this happens.. and what could be done to
>>> avoid such JVM Hang and restarts.
>>>
>>> Any help in this regard will be useful
>>>
>>> Thanks in Advance,
>>>
>>> Regards,
>>> Karthik Krishnan

Re: [Wrapper-user] Notification for JVM Hungs

[karthik K. <kar...@gm...>]

Hi Leif,

thanks a ton for ur reply!!!

The appl. is installed a year ago in the client machine by someone unknown
to me.. So i really dont know the Wrapper edition and version..

Can u please tell me How to find that.. is there any command i can try to
find the version and edition.. which will be helpful in my case to do
somethng for the JVM Hungs..

Also.. Can you tell me if its possible to invoke external appl. in the
standard edition..
Or can u tell me what is the file that invokes the wrapper to restart the
service.. or where does the Wrapper concludes that JVM is Hung!!!.. i see
there is a log that JVM is Hung!!!.. Which file does that writing into
log....If i know this.. i can try to invoke a external prog from that point
before it writes JVM hung to wrapper..

Thanks in advance

Karthik

Leif Mortenson-3 wrote:
> 
> Karthik,
> JVM restarts like this are usually caused by the JVM itself freezing
> and needing to be restarted.   There are however times where the JVM
> is temporarily frozen by heavy disk IO or memory swapping.   If you
> are seeing this problem repeatedly, I would suggest setting the
> wrapper.ping.timeout to a longer value and seeing if the JVM recovers
> on its own.   Whether it is a permanent or temporary freeze, there is
> a problem that needs to be resolved as your application will not be
> responsive to user requests when it is unable to respond to the
> Wrapper's pings.
> 
> When the JVM is restarted, the first JVM is first shutdown.    What
> version of the Wrapper are you using though?  There was a problem
> fixed in 3.3.1 where the Wrapper was sometimes failing to actually
> kill a JVM process which it decided to kill.   If you are having this
> problem then you will need to upgrade.   Depending on the OS you are
> running, it is also possible that the ports are still in a locked
> state until their timeout has expired.   In this case, you may want to
> try increasing the delay before launching the second JVM instant.  You
> can do this with the wrapper.restart.delay property.
> http://wrapper.tanukisoftware.com/doc/english/prop-restart-delay.html
> 
> The professional edition of the Wrapper makes it possible for you to
> launch an external process at various points in the Wrapper and JVM
> lifecycle.  This includes just before a JVM restart:
> http://wrapper.tanukisoftware.com/doc/english/props-event.html#command
> 
> Please let me know how these options work for you.
> 
> Cheers,
> Leif
> 
> 
> On Sun, Sep 11, 2011 at 5:30 AM, karthik Krishnan <kar...@gm...>
> wrote:
>>
>> Hi,
>>
>> Reposting due to some mailing list subscription issue!!! Please ignore if
>> this is repeated. Inconvenience regretted..
>>
>> I m facing issues like, when the JVM Hungs and restarts with below
>> message..
>> sometimes, few services are not bound properly and giving us some
>> issues..
>>
>> wrapper  | JVM appears hung: Timed out waiting for signal from JVM.
>> wrapper  | Java Virtual Machine did not exit on request, terminated
>> wrapper  | Launching a JVM...
>> jvm 2    | Initializing...
>>
>> So, i need to write a program which will be called whenever the JVM Hungs
>> and restarts by itself to check if the services are bound properly. for
>> that
>> i need to know, from where can i invoke this program.. (Likely to call a
>> batch file from somewhere..).. Need to know which file and steps the
>> Wrapper
>> calls to restarts the service..
>>
>> Or, is there any property that can be set to send a notification by mail
>> when there is a JVM Hung.. I know there is a email Notification available
>> in
>> prof edition. We are using a standard edition.
>> Can someone help me or let me know if u have done something similar to
>> this.
>>
>> Someone can throw light on why this happens.. and what could be done to
>> avoid such JVM Hang and restarts.
>>
>> Any help in this regard will be useful
>>
>> Thanks in Advance,
>>
>> Regards,
>> Karthik Krishnan
> 
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage 
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 
> 

-- 
View this message in context: http://old.nabble.com/Notification-for-JVM-Hungs-tp32421697p32441661.html
Sent from the Java Service Wrapper mailing list archive at Nabble.com.

Re: [Wrapper-user] Notification for JVM Hungs

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

Karthik,
JVM restarts like this are usually caused by the JVM itself freezing
and needing to be restarted.   There are however times where the JVM
is temporarily frozen by heavy disk IO or memory swapping.   If you
are seeing this problem repeatedly, I would suggest setting the
wrapper.ping.timeout to a longer value and seeing if the JVM recovers
on its own.   Whether it is a permanent or temporary freeze, there is
a problem that needs to be resolved as your application will not be
responsive to user requests when it is unable to respond to the
Wrapper's pings.

When the JVM is restarted, the first JVM is first shutdown.    What
version of the Wrapper are you using though?  There was a problem
fixed in 3.3.1 where the Wrapper was sometimes failing to actually
kill a JVM process which it decided to kill.   If you are having this
problem then you will need to upgrade.   Depending on the OS you are
running, it is also possible that the ports are still in a locked
state until their timeout has expired.   In this case, you may want to
try increasing the delay before launching the second JVM instant.  You
can do this with the wrapper.restart.delay property.
http://wrapper.tanukisoftware.com/doc/english/prop-restart-delay.html

The professional edition of the Wrapper makes it possible for you to
launch an external process at various points in the Wrapper and JVM
lifecycle.  This includes just before a JVM restart:
http://wrapper.tanukisoftware.com/doc/english/props-event.html#command

Please let me know how these options work for you.

Cheers,
Leif


On Sun, Sep 11, 2011 at 5:30 AM, karthik Krishnan <kar...@gm...> wrote:
>
> Hi,
>
> Reposting due to some mailing list subscription issue!!! Please ignore if
> this is repeated. Inconvenience regretted..
>
> I m facing issues like, when the JVM Hungs and restarts with below message..
> sometimes, few services are not bound properly and giving us some issues..
>
> wrapper  | JVM appears hung: Timed out waiting for signal from JVM.
> wrapper  | Java Virtual Machine did not exit on request, terminated
> wrapper  | Launching a JVM...
> jvm 2    | Initializing...
>
> So, i need to write a program which will be called whenever the JVM Hungs
> and restarts by itself to check if the services are bound properly. for that
> i need to know, from where can i invoke this program.. (Likely to call a
> batch file from somewhere..).. Need to know which file and steps the Wrapper
> calls to restarts the service..
>
> Or, is there any property that can be set to send a notification by mail
> when there is a JVM Hung.. I know there is a email Notification available in
> prof edition. We are using a standard edition.
> Can someone help me or let me know if u have done something similar to this.
>
> Someone can throw light on why this happens.. and what could be done to
> avoid such JVM Hang and restarts.
>
> Any help in this regard will be useful
>
> Thanks in Advance,
>
> Regards,
> Karthik Krishnan

[Wrapper-user] Notification for JVM Hungs

[karthik K. <kar...@gm...>]

Hi,

Reposting due to some mailing list subscription issue!!! Please ignore if
this is repeated. Inconvenience regretted..

I m facing issues like, when the JVM Hungs and restarts with below message..
sometimes, few services are not bound properly and giving us some issues..

wrapper  | JVM appears hung: Timed out waiting for signal from JVM.
wrapper  | Java Virtual Machine did not exit on request, terminated
wrapper  | Launching a JVM...
jvm 2    | Initializing...

So, i need to write a program which will be called whenever the JVM Hungs
and restarts by itself to check if the services are bound properly. for that
i need to know, from where can i invoke this program.. (Likely to call a
batch file from somewhere..).. Need to know which file and steps the Wrapper
calls to restarts the service..

Or, is there any property that can be set to send a notification by mail
when there is a JVM Hung.. I know there is a email Notification available in
prof edition. We are using a standard edition.
Can someone help me or let me know if u have done something similar to this.

Someone can throw light on why this happens.. and what could be done to
avoid such JVM Hang and restarts.

Any help in this regard will be useful
  
Thanks in Advance,

Regards,
Karthik Krishnan


-- 
View this message in context: http://old.nabble.com/Notification-for-JVM-Hungs-tp32421697p32421697.html
Sent from the Java Service Wrapper mailing list archive at Nabble.com.

Re: [Wrapper-user] JBoss AS7 problems

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

Hi,

you are very welcome.
Please let me know if you have any other questions.

Thank you,
Christian

On Fri, Sep 9, 2011 at 11:58 PM, qt4x11 <qt...@gm...> wrote:
>
> This information was very helpful, I was able to get JBoss 7 running as a
> service.  Thank you again!
>
> On Thu, Sep 8, 2011 at 8:13 PM, Christian Mueller
> <chr...@ta...> wrote:
>>
>> Hi,
>>
>> Please see the output 1 line above the message you posted:
>> Load native library. One or more attempts may fail if platform
>> specific libraries do not exist.  This is NORMAL and is only a problem
>> if they all fail.
>>
>> The Wrapper tries first to load the library according to the OS-arch
>> format we are using in the delta pack. You are running windows on a
>> x86 32 bit machine, so this derives to wrapper-windows-x86-32.dll
>> Since you are not running the delta pack, there is only a wrapper.dll
>> file, so in the next attempt, the wrapper tries to load wrapper.dll
>>
>> This is successful as the output states:
>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
>> Loaded native library:
>>
>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug: Loaded
>> native localization method.
>>
>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
>> Calling native initialization method.
>>
>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug:
>> Initializing WrapperManager native library.
>>
>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug: Java
>> Executable: C:\Program Files\Java\jdk1.6.0_16\bin\java.exe
>>
>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug: Native
>> Library: D:\jboss-as-7.0.0.Final\lib\wrapper.dll
>>
>>
>> So there is nothing wrong with the native library.
>>
>> However I see the following in your conf file:
>> wrapper.app.parameter.1=%JBOSS_HOME%\bin\run.jar
>>
>> I think it is better to change it to:
>> wrapper.app.parameter.1=../jboss-modules.jar
>>
>> Also in your classpath with the above mentioned,
>> wrapper.java.classpath.2 and wrapper.java.classpath.3 can be removed
>> and classpath.1&4 is only needed.
>>
>> Please let me know if you have any further questions.
>>
>> Thank you,
>> Christian
>>
>>
>> On Fri, Sep 9, 2011 at 9:50 AM, Charles <cpr...@go...> wrote:
>> > copy wrapper.dll to
>> > %JBOSS_HOME%\lib
>> > and set
>> > wrapper.java.library.path.1=%JBOSS_HOME%\lib
>> > in the conf file in %JBOSS_HOME%\conf
>> >
>> >
>> > On Fri, Sep 9, 2011 at 2:48 AM, Charles <cpr...@go...>
>> > wrote:
>> >>
>> >> copy wrapper.dll to
>> >> %JBOSS_HOME%\lib
>> >> and set
>> >> wrapper.java.library.path.1=%JBOSS_HOME%\lib
>> >> in the conf file in %JBOSS_HOME%\conf
>> >>
>> >> On Thu, Sep 8, 2011 at 6:34 PM, qt4x11 <qt...@gm...> wrote:
>> >>>
>> >>> Thanks, I've been following your advice and used method 4.  I believe
>> >>> I'm
>> >>> pretty close to making it work.  Right now I'm receiving the error
>> >>> message
>> >>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
>> >>> Unable
>> >>> to load native library: wrapper-windows-x86-32.dll  Cause: no
>> >>> wrapper-windows-x86-32 in java.library.path
>> >>> It seems like wrapper is not able to load the native library?  I'm not
>> >>> sure why this is - I've made sure that java.library.path config option
>> >>> points to the location of a valid wrapper.dll file.  I'm attaching my
>> >>> current conf file and recent logs, if you can take a look
>> >>>
>> >>> On Wed, Sep 7, 2011 at 8:38 PM, Christian Mueller
>> >>> <chr...@ta...> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> JBoss AS7 has changed in several ways how it is launching.
>> >>>>
>> >>>> You are using Integration method 1, however it seems that you are
>> >>>> passing in a jar file as the first parameter to
>> >>>> org.tanukisoftware.wrapper.WrapperSimpleApp. WrapperSimpleApp expects
>> >>>> the name of your main class as parameter. So you should go for
>> >>>> integration method 4 and pass the jar file to
>> >>>> org.tanukisoftware.wrapper.WrapperJarApp.
>> >>>>
>> >>>> We have had some guys recently with the same questions and helped
>> >>>> them
>> >>>> resolving the problem:
>> >>>>
>> >>>> https://issues.jboss.org/browse/AS7-1547
>> >>>>
>> >>>> Hope this information helps you out.
>> >>>>
>> >>>> Please let me know if you have any further questions.
>> >>>>
>> >>>> Thank you,
>> >>>> Christian
>> >>>>
>> >>>> PS: I also replied with above answer to your question on
>> >>>> stackoverflow
>> >>>> as well.
>> >>>>
>> >>>> On Thu, Sep 8, 2011 at 12:41 AM, qt4x11 <qt...@gm...> wrote:
>> >>>> > I'm trying to use jsw 3.3.5 32 bit with JBoss AS7 on a Windows 7 64
>> >>>> > bit
>> >>>> > machine.  I have a hunch the reason I'm having problems is due our
>> >>>> > 32
>> >>>> > bit
>> >>>> > version, but we have been able to use the 32 bit version of jsw
>> >>>> > with
>> >>>> > other
>> >>>> > applications (ActiveMQ) successfully, so I thought I'd try the 32
>> >>>> > bit
>> >>>> > version first.  If it's advisable to upgrade to the pro version we
>> >>>> > will do
>> >>>> > so.
>> >>>> > I'm pasting my wrapper.log and wrapper.conf below.  Right now the
>> >>>> > service is
>> >>>> > not able to start normally.  I tried troubleshooting the
>> >>>> >  UnsatisfiedLinkError: no wrapper-windows-x86-32 in
>> >>>> > java.library.path
>> >>>> > error
>> >>>> > by making sure jsw was finding my java.library.path by hard coding
>> >>>> > paths for
>> >>>> > JAVA_HOME and JBOSS_HOME in my conf.  The second error seems
>> >>>> > unusual
>> >>>> > to me,
>> >>>> > as  D:\jboss-as-7.0.0.Final/jboss-module.jar definitely exists on
>> >>>> > the
>> >>>> > file
>> >>>> > system.
>> >>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | --> Wrapper Started as
>> >>>> > Console
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Using tick timer.
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | server listening on port
>> >>>> > 32001.
>> >>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | Launching a JVM...
>> >>>> > INFO   | wrapper  | 2011/09/07 08:01:33 | command: "C:\Program
>> >>>> > Files\Java\jdk1.6.0_16\bin\java" -XX:MaxPermSize=256m
>> >>>> > -Dorg.jboss.resolver.warning=true
>> >>>> > -Dsun.rmi.dgc.client.gcInterval=3600000
>> >>>> > -Dsun.rmi.dgc.server.gcInterval=3600000
>> >>>> > -Djboss.modules.system.pkgs=org.jboss.byteman
>> >>>> > -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
>> >>>> >
>> >>>> >
>> >>>> > -Dlogging.configuration=file:D:\jboss-as-7.0.0.Final/standalone/configuration/logging.properties
>> >>>> > -Djava.library.path="D:\jboss-as-7.0.0.Final/lib" -classpath
>> >>>> > "D:\jboss-as-7.0.0.Final/lib/wrapper.jar;C:\Program
>> >>>> >
>> >>>> >
>> >>>> > Files\Java\jdk1.6.0_16/lib/tools.jar;D:\jboss-as-7.0.0.Final/bin/run.jar;D:\jboss-as-7.0.0.Final/jboss-modules.jar"
>> >>>> > -Dwrapper.key="ExYkelyCNrKjXXAf" -Dwrapper.port=32001
>> >>>> > -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
>> >>>> > -Dwrapper.debug="TRUE" -Dwrapper.pid=3200 -Dwrapper.version="3.2.3"
>> >>>> > -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
>> >>>> > -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp
>> >>>> > D:\jboss-as-7.0.0.Final/jboss-modules.jar
>> >>>> > D:\jboss-as-7.0.0.Final\modules
>> >>>> > org.jboss.logmanager org.jboss.as.standalone
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM started (PID=3336)
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager class
>> >>>> > initialized
>> >>>> > by thread: main  Using classloader:
>> >>>> > sun.misc.Launcher$AppClassLoader@11b86e7
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper (Version 3.2.3)
>> >>>> > http://wrapper.tanukisoftware.org
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   Copyright 1999-2006
>> >>>> > Tanuki
>> >>>> > Software, Inc.  All Rights Reserved.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: JVM #1
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Running a 32-bit JVM.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager:
>> >>>> > Registering
>> >>>> > shutdown hook
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Using
>> >>>> > wrapper
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Load native library.  One
>> >>>> > or
>> >>>> > more
>> >>>> > attempts may fail if platform specific libraries do not exist.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loading native library
>> >>>> > failed:
>> >>>> > wrapper-windows-x86-32.dll  Cause: java.lang.UnsatisfiedLinkError:
>> >>>> > no
>> >>>> > wrapper-windows-x86-32 in java.library.path
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loaded native library:
>> >>>> > wrapper.dll
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Calling native
>> >>>> > initialization
>> >>>> > method.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Initializing
>> >>>> > WrapperManager
>> >>>> > native
>> >>>> > library.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Executable:
>> >>>> > C:\Program
>> >>>> > Files\Java\jdk1.6.0_16\bin\java.exe
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Windows version: 5.2.3790
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Version   :
>> >>>> > 1.6.0_16-b01 Java
>> >>>> > HotSpot(TM) Client VM
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java VM Vendor : Sun
>> >>>> > Microsystems
>> >>>> > Inc.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp: Unable
>> >>>> > to
>> >>>> > locate
>> >>>> > the class D:\jboss-as-7.0.0.Final/jboss-modules.jar:
>> >>>> > java.lang.ClassNotFoundException:
>> >>>> > D:\jboss-as-7.0.0.Final/jboss-modules.jar
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp Usage:
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   java
>> >>>> > org.tanukisoftware.wrapper.WrapperSimpleApp {app_class}
>> >>>> > [app_arguments]
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Where:
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_class:      The
>> >>>> > fully
>> >>>> > qualified class name of the application to run.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_arguments:  The
>> >>>> > arguments
>> >>>> > that would normally be passed to the
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>> >>>> > application.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager.stop(1)
>> >>>> > called by
>> >>>> > thread: main
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Control event monitor
>> >>>> > thread
>> >>>> > started.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Startup runner thread
>> >>>> > started.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Communications runner
>> >>>> > thread
>> >>>> > started.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Open socket to
>> >>>> > wrapper...Wrapper-Connection
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
>> >>>> > using
>> >>>> > local
>> >>>> > port 31000
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
>> >>>> > using
>> >>>> > local
>> >>>> > port 31001
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
>> >>>> > using
>> >>>> > local
>> >>>> > port 31002
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
>> >>>> > using
>> >>>> > local
>> >>>> > port 31003
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Opened Socket from 31004
>> >>>> > to
>> >>>> > 32001
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet KEY :
>> >>>> > ExYkelyCNrKjXXAf
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>> >>>> > handleSocket(Socket[addr=/127.0.0.1,port=32001,localport=31004])
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet STOP : 1
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | accepted a socket from
>> >>>> > 127.0.0.1
>> >>>> > on port 31004
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet KEY :
>> >>>> > ExYkelyCNrKjXXAf
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Got key from JVM:
>> >>>> > ExYkelyCNrKjXXAf
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet
>> >>>> > LOW_LOG_LEVEL
>> >>>> > : 1
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet
>> >>>> > PING_TIMEOUT :
>> >>>> > 30
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PROPERTIES
>> >>>> > :
>> >>>> > (Property Values)
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet STOP : 1
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM requested a shutdown.
>> >>>> > (1)
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | wrapperStopProcess(1)
>> >>>> > called.
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Sending stop signal to
>> >>>> > JVM
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet STOP : NULL
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
>> >>>> > LOW_LOG_LEVEL :
>> >>>> > 1
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager:
>> >>>> > LowLogLevel
>> >>>> > from
>> >>>> > Wrapper is 1
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
>> >>>> > PING_TIMEOUT :
>> >>>> > 30
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | PingTimeout from Wrapper
>> >>>> > is
>> >>>> > 30000
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
>> >>>> > PROPERTIES
>> >>>> > :
>> >>>> > (Property Values)
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet STOP :
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Thread, main, handling
>> >>>> > the
>> >>>> > shutdown process.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | shutdownJVM(1)
>> >>>> > Thread:main
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Send a packet STOPPED : 1
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | read a packet STOPPED : 1
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:34 | JVM signalled that it was
>> >>>> > stopped.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closing socket.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closed socket:
>> >>>> > java.net.SocketException: socket closed
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | socket read no code
>> >>>> > (closed?).
>> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:35 | server listening on port
>> >>>> > 32002.
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | Server daemon shut down
>> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | calling System.exit(1)
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM process exited with a
>> >>>> > code of
>> >>>> > 1, however the wrapper exit code was already 1.
>> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM exited normally.
>> >>>> > STATUS | wrapper  | 2011/09/07 08:01:35 | <-- Wrapper Stopped
>> >>>> > My wrapper.conf is below
>> >>>> > #encoding=UTF-8
>> >>>> > # Configuration files must begin with a line specifying the
>> >>>> > encoding
>> >>>> > #  of the the file.
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Wrapper License Properties (Ignored by Community Edition)
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Professional and Standard Editions of the Wrapper require a valid
>> >>>> > #  License Key to start.  Licenses can be purchased or a trial
>> >>>> > license
>> >>>> > #  requested on the following pages:
>> >>>> > # http://wrapper.tanukisoftware.com/purchase
>> >>>> > # http://wrapper.tanukisoftware.com/trial
>> >>>> > # Include file problems can be debugged by removing the first '#'
>> >>>> > #  from the following line:
>> >>>> > ##include.debug
>> >>>> > # The Wrapper will look for either of the following optional files
>> >>>> > for
>> >>>> > a
>> >>>> > #  valid License Key.  License Key properties can optionally be
>> >>>> > included
>> >>>> > #  directly in this configuration file.
>> >>>> > #include ../conf/wrapper-license.conf
>> >>>> > #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
>> >>>> > # The following property will output information about which
>> >>>> > License
>> >>>> > Key(s)
>> >>>> > #  are being found, and can aid in resolving any licensing
>> >>>> > problems.
>> >>>> > #wrapper.license.debug=TRUE
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Wrapper Localization
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Specify the locale which the Wrapper should use.  By default the
>> >>>> > system
>> >>>> > #  locale is used.
>> >>>> > #wrapper.lang=en_US # en_US or ja_JP
>> >>>> > # Specify the location of the Wrapper's language resources.  If
>> >>>> > these
>> >>>> > are
>> >>>> > #  missing, the Wrapper will default to the en_US locale.
>> >>>> > wrapper.lang.folder=../lang
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Wrapper Java Properties
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Java Application
>> >>>> > #  Locate the java binary on the system PATH:
>> >>>> > #wrapper.java.command=java
>> >>>> > #  Specify a specific java binary:
>> >>>> > set.JBOSS_HOME=D:\jboss-as-7.0.0.Final
>> >>>> > set.JAVA_HOME=C:\Program Files\Java\jdk1.6.0_16
>> >>>> > wrapper.java.command=%JAVA_HOME%/bin/java
>> >>>> > # Tell the Wrapper to log the full generated Java command line.
>> >>>> > wrapper.java.command.loglevel=INFO
>> >>>> > # Java Main class.  This class must implement the WrapperListener
>> >>>> > interface
>> >>>> > #  or guarantee that the WrapperManager class is initialized.
>> >>>> >  Helper
>> >>>> > #  classes are provided to do this for you.  See the Integration
>> >>>> > section
>> >>>> > #  of the documentation for details.
>> >>>> > wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>> >>>> > # Java Classpath (include wrapper.jar)  Add class path elements as
>> >>>> > #  needed starting from 1
>> >>>> > wrapper.java.classpath.1=%JBOSS_HOME%/lib/wrapper.jar
>> >>>> > wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
>> >>>> > wrapper.java.classpath.3=%JBOSS_HOME%/bin/run.jar
>> >>>> > wrapper.java.classpath.4=%JBOSS_HOME%/jboss-modules.jar
>> >>>> > # Java Library Path (location of Wrapper.DLL or libwrapper.so)
>> >>>> > wrapper.java.library.path.1=%JBOSS_HOME%/lib
>> >>>> > # Java Bits.  On applicable platforms, tells the JVM to run in 32
>> >>>> > or
>> >>>> > 64-bit
>> >>>> > mode.
>> >>>> > wrapper.java.additional.auto_bits=TRUE
>> >>>> > # Java Additional Parameters
>> >>>> > #wrapper.java.additional.1=-server
>> >>>> > wrapper.java.additional.1=-XX:MaxPermSize=256m
>> >>>> > wrapper.java.additional.2=-Dorg.jboss.resolver.warning=true
>> >>>> > wrapper.java.additional.3=-Dsun.rmi.dgc.client.gcInterval=3600000
>> >>>> > wrapper.java.additional.4=-Dsun.rmi.dgc.server.gcInterval=3600000
>> >>>> >
>> >>>> >
>> >>>> > wrapper.java.additional.5=-Djboss.modules.system.pkgs=org.jboss.byteman
>> >>>> >
>> >>>> >
>> >>>> > wrapper.java.additional.6=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
>> >>>> >
>> >>>> >
>> >>>> > wrapper.java.additional.7=-Dlogging.configuration=file:%JBOSS_HOME%/standalone/configuration/logging.properties
>> >>>> > # Initial Java Heap Size (in MB)
>> >>>> > #wrapper.java.initmemory=128
>> >>>> > # Maximum Java Heap Size (in MB)
>> >>>> > #wrapper.java.maxmemory=512
>> >>>> > # Application parameters.  Add parameters as needed starting from 1
>> >>>> > wrapper.app.parameter.1=%JBOSS_HOME%/jboss-modules.jar
>> >>>> > wrapper.app.parameter.2=-mp
>> >>>> > wrapper.app.parameter.2=%JBOSS_HOME%\modules
>> >>>> > wrapper.app.parameter.3=-logmodule
>> >>>> > wrapper.app.parameter.3=org.jboss.logmanager
>> >>>> > wrapper.app.parameter.4=-jaxpmodule
>> >>>> > wrapper.app.parameter.4=javax.xml.jaxp-provider
>> >>>> > wrapper.app.parameter.4=org.jboss.as.standalone
>> >>>> > wrapper.app.parameter.9=-Djboss.home.dir=%JBOSS_HOME%
>> >>>> >
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Wrapper Logging Properties
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Enables Debug output from the Wrapper.
>> >>>> > wrapper.debug=TRUE
>> >>>> > # Format of output for the console.  (See docs for formats)
>> >>>> > wrapper.console.format=PM
>> >>>> > # Log Level for console output.  (See docs for log levels)
>> >>>> > wrapper.console.loglevel=INFO
>> >>>> > # Log file to use for wrapper output logging.
>> >>>> > wrapper.logfile=../standalone/log/wrapper.log
>> >>>> > # Format of output for the log file.  (See docs for formats)
>> >>>> > wrapper.logfile.format=LPTM
>> >>>> > # Log Level for log file output.  (See docs for log levels)
>> >>>> > wrapper.logfile.loglevel=INFO
>> >>>> > # Maximum size that the log file will be allowed to grow to before
>> >>>> > #  the log is rolled. Size is specified in bytes.  The default
>> >>>> > value
>> >>>> > #  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
>> >>>> > #  'm' (mb) suffix.  For example: 10m = 10 megabytes.
>> >>>> > wrapper.logfile.maxsize=0
>> >>>> > # Maximum number of rolled log files which will be allowed before
>> >>>> > old
>> >>>> > #  files are deleted.  The default value of 0 implies no limit.
>> >>>> > wrapper.logfile.maxfiles=0
>> >>>> > # Log Level for sys/event log output.  (See docs for log levels)
>> >>>> > wrapper.syslog.loglevel=NONE
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Wrapper General Properties
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Allow for the use of non-contiguous numbered properties
>> >>>> > #wrapper.ignore_sequence_gaps=TRUE
>> >>>> > # Title to use when running as a console
>> >>>> > #wra...@ap...@
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Wrapper JVM Checks
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
>> >>>> > #wrapper.check.deadlock=TRUE
>> >>>> > #wrapper.check.deadlock.interval=60
>> >>>> > #wrapper.check.deadlock.action=RESTART
>> >>>> > #wrapper.check.deadlock.output=FULL
>> >>>> > # Out Of Memory detection.
>> >>>> > # (Simple match)
>> >>>> > #wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
>> >>>> > # (Only match text in stack traces if -XX:+PrintClassHistogram is
>> >>>> > being
>> >>>> > used.)
>> >>>> > #wrapper.filter.trigger.1000=Exception in thread "*"
>> >>>> > java.lang.OutOfMemoryError
>> >>>> > #wrapper.filter.allow_wildcards.1000=TRUE
>> >>>> > #wrapper.filter.action.1000=RESTART
>> >>>> > #wrapper.filter.message.1000=The JVM has run out of memory.
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Wrapper Email Notifications. (Requires Professional Edition)
>> >>>> >
>> >>>> > #********************************************************************
>> >>>> > # Common Event Email settings.
>> >>>> > #wrapper.event.default.email.debug=TRUE
>> >>>> > #wrapper.event.default.email.smtp.host=<SMTP_Host>
>> >>>> > #wrapper.event.default.email.smtp.port=25
>> >>>> >
>> >>>> >
>> >>>> > #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
>> >>>> > Event Notification
>> >>>> > #wrapper.event.default.email.sender=<Sender email>
>> >>>> > #wrapper.event.default.email.recipient=<Recipient email>
>> >>>> > # Configure the log attached to event emails.
>> >>>> > #wrapper.event.default.email.attach_log=TRUE
>> >>>> > #wrapper.event.default.email.maillog.lines=50
>> >>>> > #wrapper.event.default.email.maillog.format=LPTM
>> >>>> > #wrapper.event.default.email.maillog.loglevel=INFO
>> >>>> > # Enable specific event emails.
>> >>>> > #wrapper.event.wrapper_start.email=TRUE
>> >>>> > #wrapper.event.jvm_prelaunch.email=TRUE
>> >>>> > #wrapper.event.jvm_start.email=TRUE
>> >>>> > #wrapper.event.jvm_started.email=TRUE
>> >>>> > #wrapper.event.jvm_deadlock.email=TRUE
>> >>>> > #wrapper.event.jvm_stop.email=TRUE
>> >>>> > #wrapper.event.jvm_stopped.email=TRUE
>> >>>> > #wrapper.event.jvm_restart.email=TRUE
>> >>>> > #wrapper.event.jvm_failed_invocation.email=TRUE
>> >>>> > #wrapper.event.jvm_max_failed_invocations.email=TRUE
>> >>>> > #wrapper.event.jvm_kill.email=TRUE
>> >>>> > #wrapper.event.jvm_killed.email=TRUE
>> >>>> > #wrapper.event.jvm_unexpected_exit.email=TRUE
>> >>>> > #wrapper.event.wrapper_stop.email=TRUE
>> >>>> > # Specify custom mail content
>> >>>> > #wrapper.event.jvm_restart.email.body=The JVM was
>> >>>> > restarted.\n\nPlease
>> >>>> > check
>> >>>> > on its status.\n
>> >>>> > Anyone know what's going on?  Do these errors have to do with my 32
>> >>>> > bit
>> >>>> > version?  If we need to upgrade to pro we'll do so.  Thanks!
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > ------------------------------------------------------------------------------
>> >>>> > Using storage to extend the benefits of virtualization and iSCSI
>> >>>> > Virtualization increases hardware utilization and delivers a new
>> >>>> > level
>> >>>> > of
>> >>>> > agility. Learn what those decisions are and how to modernize your
>> >>>> > storage
>> >>>> > and backup environments for virtualization.
>> >>>> > http://www.accelacomm.com/jaw/sfnl/114/51434361/
>> >>>> > _______________________________________________
>> >>>> > Wrapper-user mailing list
>> >>>> > Wra...@li...
>> >>>> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
>> >>>> >
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Doing More with Less: The Next Generation Virtual Desktop
>> >>>> What are the key obstacles that have prevented many mid-market
>> >>>> businesses
>> >>>> from deploying virtual desktops?   How do next-generation virtual
>> >>>> desktops
>> >>>> provide companies an easier-to-deploy, easier-to-manage and more
>> >>>> affordable
>> >>>> virtual desktop
>> >>>> model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>> >>>> _______________________________________________
>> >>>> Wrapper-user mailing list
>> >>>> Wra...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Doing More with Less: The Next Generation Virtual Desktop
>> >>> What are the key obstacles that have prevented many mid-market
>> >>> businesses
>> >>> from deploying virtual desktops?   How do next-generation virtual
>> >>> desktops
>> >>> provide companies an easier-to-deploy, easier-to-manage and more
>> >>> affordable
>> >>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>> >>> _______________________________________________
>> >>> Wrapper-user mailing list
>> >>> Wra...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>> >>>
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Why Cloud-Based Security and Archiving Make Sense
>> > Osterman Research conducted this study that outlines how and why cloud
>> > computing security and archiving is rapidly being adopted across the IT
>> > space for its ease of implementation, lower cost, and increased
>> > reliability. Learn more.
>> > http://www.accelacomm.com/jaw/sfnl/114/51425301/
>> > _______________________________________________
>> > Wrapper-user mailing list
>> > Wra...@li...
>> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Why Cloud-Based Security and Archiving Make Sense
>> Osterman Research conducted this study that outlines how and why cloud
>> computing security and archiving is rapidly being adopted across the IT
>> space for its ease of implementation, lower cost, and increased
>> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] JBoss AS7 problems

[qt4x11 <qt...@gm...>]

This information was very helpful, I was able to get JBoss 7 running as a
service.  Thank you again!


On Thu, Sep 8, 2011 at 8:13 PM, Christian Mueller <
chr...@ta...> wrote:

> Hi,
>
> Please see the output 1 line above the message you posted:
> Load native library. One or more attempts may fail if platform
> specific libraries do not exist.  This is NORMAL and is only a problem
> if they all fail.
>
> The Wrapper tries first to load the library according to the OS-arch
> format we are using in the delta pack. You are running windows on a
> x86 32 bit machine, so this derives to wrapper-windows-x86-32.dll
> Since you are not running the delta pack, there is only a wrapper.dll
> file, so in the next attempt, the wrapper tries to load wrapper.dll
>
> This is successful as the output states:
> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
> Loaded native library:
>
> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug: Loaded
> native localization method.
>
> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
> Calling native initialization method.
>
> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug:
> Initializing WrapperManager native library.
>
> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug: Java
> Executable: C:\Program Files\Java\jdk1.6.0_16\bin\java.exe
>
> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug: Native
> Library: D:\jboss-as-7.0.0.Final\lib\wrapper.dll
>
>
> So there is nothing wrong with the native library.
>
> However I see the following in your conf file:
> wrapper.app.parameter.1=%JBOSS_HOME%\bin\run.jar
>
> I think it is better to change it to:
> wrapper.app.parameter.1=../jboss-modules.jar
>
> Also in your classpath with the above mentioned,
> wrapper.java.classpath.2 and wrapper.java.classpath.3 can be removed
> and classpath.1&4 is only needed.
>
> Please let me know if you have any further questions.
>
> Thank you,
> Christian
>
>
> On Fri, Sep 9, 2011 at 9:50 AM, Charles <cpr...@go...> wrote:
> > copy wrapper.dll to
> > %JBOSS_HOME%\lib
> > and set
> > wrapper.java.library.path.1=%JBOSS_HOME%\lib
> > in the conf file in %JBOSS_HOME%\conf
> >
> >
> > On Fri, Sep 9, 2011 at 2:48 AM, Charles <cpr...@go...>
> wrote:
> >>
> >> copy wrapper.dll to
> >> %JBOSS_HOME%\lib
> >> and set
> >> wrapper.java.library.path.1=%JBOSS_HOME%\lib
> >> in the conf file in %JBOSS_HOME%\conf
> >>
> >> On Thu, Sep 8, 2011 at 6:34 PM, qt4x11 <qt...@gm...> wrote:
> >>>
> >>> Thanks, I've been following your advice and used method 4.  I believe
> I'm
> >>> pretty close to making it work.  Right now I'm receiving the error
> message
> >>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
> Unable
> >>> to load native library: wrapper-windows-x86-32.dll  Cause: no
> >>> wrapper-windows-x86-32 in java.library.path
> >>> It seems like wrapper is not able to load the native library?  I'm not
> >>> sure why this is - I've made sure that java.library.path config option
> >>> points to the location of a valid wrapper.dll file.  I'm attaching my
> >>> current conf file and recent logs, if you can take a look
> >>>
> >>> On Wed, Sep 7, 2011 at 8:38 PM, Christian Mueller
> >>> <chr...@ta...> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> JBoss AS7 has changed in several ways how it is launching.
> >>>>
> >>>> You are using Integration method 1, however it seems that you are
> >>>> passing in a jar file as the first parameter to
> >>>> org.tanukisoftware.wrapper.WrapperSimpleApp. WrapperSimpleApp expects
> >>>> the name of your main class as parameter. So you should go for
> >>>> integration method 4 and pass the jar file to
> >>>> org.tanukisoftware.wrapper.WrapperJarApp.
> >>>>
> >>>> We have had some guys recently with the same questions and helped them
> >>>> resolving the problem:
> >>>>
> >>>> https://issues.jboss.org/browse/AS7-1547
> >>>>
> >>>> Hope this information helps you out.
> >>>>
> >>>> Please let me know if you have any further questions.
> >>>>
> >>>> Thank you,
> >>>> Christian
> >>>>
> >>>> PS: I also replied with above answer to your question on stackoverflow
> >>>> as well.
> >>>>
> >>>> On Thu, Sep 8, 2011 at 12:41 AM, qt4x11 <qt...@gm...> wrote:
> >>>> > I'm trying to use jsw 3.3.5 32 bit with JBoss AS7 on a Windows 7 64
> >>>> > bit
> >>>> > machine.  I have a hunch the reason I'm having problems is due our
> 32
> >>>> > bit
> >>>> > version, but we have been able to use the 32 bit version of jsw with
> >>>> > other
> >>>> > applications (ActiveMQ) successfully, so I thought I'd try the 32
> bit
> >>>> > version first.  If it's advisable to upgrade to the pro version we
> >>>> > will do
> >>>> > so.
> >>>> > I'm pasting my wrapper.log and wrapper.conf below.  Right now the
> >>>> > service is
> >>>> > not able to start normally.  I tried troubleshooting the
> >>>> >  UnsatisfiedLinkError: no wrapper-windows-x86-32 in
> java.library.path
> >>>> > error
> >>>> > by making sure jsw was finding my java.library.path by hard coding
> >>>> > paths for
> >>>> > JAVA_HOME and JBOSS_HOME in my conf.  The second error seems unusual
> >>>> > to me,
> >>>> > as  D:\jboss-as-7.0.0.Final/jboss-module.jar definitely exists on
> the
> >>>> > file
> >>>> > system.
> >>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | --> Wrapper Started as
> >>>> > Console
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Using tick timer.
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | server listening on port
> >>>> > 32001.
> >>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | Launching a JVM...
> >>>> > INFO   | wrapper  | 2011/09/07 08:01:33 | command: "C:\Program
> >>>> > Files\Java\jdk1.6.0_16\bin\java" -XX:MaxPermSize=256m
> >>>> > -Dorg.jboss.resolver.warning=true
> >>>> > -Dsun.rmi.dgc.client.gcInterval=3600000
> >>>> > -Dsun.rmi.dgc.server.gcInterval=3600000
> >>>> > -Djboss.modules.system.pkgs=org.jboss.byteman
> >>>> > -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
> >>>> >
> >>>> >
> -Dlogging.configuration=file:D:\jboss-as-7.0.0.Final/standalone/configuration/logging.properties
> >>>> > -Djava.library.path="D:\jboss-as-7.0.0.Final/lib" -classpath
> >>>> > "D:\jboss-as-7.0.0.Final/lib/wrapper.jar;C:\Program
> >>>> >
> >>>> >
> Files\Java\jdk1.6.0_16/lib/tools.jar;D:\jboss-as-7.0.0.Final/bin/run.jar;D:\jboss-as-7.0.0.Final/jboss-modules.jar"
> >>>> > -Dwrapper.key="ExYkelyCNrKjXXAf" -Dwrapper.port=32001
> >>>> > -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
> >>>> > -Dwrapper.debug="TRUE" -Dwrapper.pid=3200 -Dwrapper.version="3.2.3"
> >>>> > -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
> >>>> > -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp
> >>>> > D:\jboss-as-7.0.0.Final/jboss-modules.jar
> >>>> > D:\jboss-as-7.0.0.Final\modules
> >>>> > org.jboss.logmanager org.jboss.as.standalone
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM started (PID=3336)
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager class
> >>>> > initialized
> >>>> > by thread: main  Using classloader:
> >>>> > sun.misc.Launcher$AppClassLoader@11b86e7
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper (Version 3.2.3)
> >>>> > http://wrapper.tanukisoftware.org
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   Copyright 1999-2006
> Tanuki
> >>>> > Software, Inc.  All Rights Reserved.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: JVM #1
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Running a 32-bit JVM.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager:
> Registering
> >>>> > shutdown hook
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Using
> >>>> > wrapper
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Load native library.  One
> or
> >>>> > more
> >>>> > attempts may fail if platform specific libraries do not exist.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loading native library
> >>>> > failed:
> >>>> > wrapper-windows-x86-32.dll  Cause: java.lang.UnsatisfiedLinkError:
> no
> >>>> > wrapper-windows-x86-32 in java.library.path
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loaded native library:
> >>>> > wrapper.dll
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Calling native
> >>>> > initialization
> >>>> > method.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Initializing
> WrapperManager
> >>>> > native
> >>>> > library.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Executable:
> C:\Program
> >>>> > Files\Java\jdk1.6.0_16\bin\java.exe
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Windows version: 5.2.3790
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Version   :
> >>>> > 1.6.0_16-b01 Java
> >>>> > HotSpot(TM) Client VM
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java VM Vendor : Sun
> >>>> > Microsystems
> >>>> > Inc.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp: Unable
> to
> >>>> > locate
> >>>> > the class D:\jboss-as-7.0.0.Final/jboss-modules.jar:
> >>>> > java.lang.ClassNotFoundException:
> >>>> > D:\jboss-as-7.0.0.Final/jboss-modules.jar
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp Usage:
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   java
> >>>> > org.tanukisoftware.wrapper.WrapperSimpleApp {app_class}
> >>>> > [app_arguments]
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Where:
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_class:      The
> fully
> >>>> > qualified class name of the application to run.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_arguments:  The
> >>>> > arguments
> >>>> > that would normally be passed to the
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
> >>>> > application.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager.stop(1)
> >>>> > called by
> >>>> > thread: main
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Control event monitor
> thread
> >>>> > started.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Startup runner thread
> >>>> > started.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Communications runner
> thread
> >>>> > started.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Open socket to
> >>>> > wrapper...Wrapper-Connection
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
> using
> >>>> > local
> >>>> > port 31000
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
> using
> >>>> > local
> >>>> > port 31001
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
> using
> >>>> > local
> >>>> > port 31002
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind
> using
> >>>> > local
> >>>> > port 31003
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Opened Socket from 31004
> to
> >>>> > 32001
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet KEY :
> >>>> > ExYkelyCNrKjXXAf
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
> >>>> > handleSocket(Socket[addr=/127.0.0.1,port=32001,localport=31004])
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet STOP : 1
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | accepted a socket from
> >>>> > 127.0.0.1
> >>>> > on port 31004
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet KEY :
> >>>> > ExYkelyCNrKjXXAf
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Got key from JVM:
> >>>> > ExYkelyCNrKjXXAf
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet
> LOW_LOG_LEVEL
> >>>> > : 1
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PING_TIMEOUT
> :
> >>>> > 30
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PROPERTIES :
> >>>> > (Property Values)
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet STOP : 1
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM requested a shutdown.
> >>>> > (1)
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | wrapperStopProcess(1)
> >>>> > called.
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Sending stop signal to JVM
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet STOP : NULL
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
> >>>> > LOW_LOG_LEVEL :
> >>>> > 1
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager:
> LowLogLevel
> >>>> > from
> >>>> > Wrapper is 1
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
> >>>> > PING_TIMEOUT :
> >>>> > 30
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | PingTimeout from Wrapper
> is
> >>>> > 30000
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
> PROPERTIES
> >>>> > :
> >>>> > (Property Values)
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet STOP :
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Thread, main, handling the
> >>>> > shutdown process.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | shutdownJVM(1) Thread:main
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Send a packet STOPPED : 1
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | read a packet STOPPED : 1
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:34 | JVM signalled that it was
> >>>> > stopped.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closing socket.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closed socket:
> >>>> > java.net.SocketException: socket closed
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | socket read no code
> >>>> > (closed?).
> >>>> > DEBUG  | wrapperp | 2011/09/07 08:01:35 | server listening on port
> >>>> > 32002.
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | Server daemon shut down
> >>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | calling System.exit(1)
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM process exited with a
> >>>> > code of
> >>>> > 1, however the wrapper exit code was already 1.
> >>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM exited normally.
> >>>> > STATUS | wrapper  | 2011/09/07 08:01:35 | <-- Wrapper Stopped
> >>>> > My wrapper.conf is below
> >>>> > #encoding=UTF-8
> >>>> > # Configuration files must begin with a line specifying the encoding
> >>>> > #  of the the file.
> >>>> >
> #********************************************************************
> >>>> > # Wrapper License Properties (Ignored by Community Edition)
> >>>> >
> #********************************************************************
> >>>> > # Professional and Standard Editions of the Wrapper require a valid
> >>>> > #  License Key to start.  Licenses can be purchased or a trial
> license
> >>>> > #  requested on the following pages:
> >>>> > # http://wrapper.tanukisoftware.com/purchase
> >>>> > # http://wrapper.tanukisoftware.com/trial
> >>>> > # Include file problems can be debugged by removing the first '#'
> >>>> > #  from the following line:
> >>>> > ##include.debug
> >>>> > # The Wrapper will look for either of the following optional files
> for
> >>>> > a
> >>>> > #  valid License Key.  License Key properties can optionally be
> >>>> > included
> >>>> > #  directly in this configuration file.
> >>>> > #include ../conf/wrapper-license.conf
> >>>> > #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
> >>>> > # The following property will output information about which License
> >>>> > Key(s)
> >>>> > #  are being found, and can aid in resolving any licensing problems.
> >>>> > #wrapper.license.debug=TRUE
> >>>> >
> #********************************************************************
> >>>> > # Wrapper Localization
> >>>> >
> #********************************************************************
> >>>> > # Specify the locale which the Wrapper should use.  By default the
> >>>> > system
> >>>> > #  locale is used.
> >>>> > #wrapper.lang=en_US # en_US or ja_JP
> >>>> > # Specify the location of the Wrapper's language resources.  If
> these
> >>>> > are
> >>>> > #  missing, the Wrapper will default to the en_US locale.
> >>>> > wrapper.lang.folder=../lang
> >>>> >
> #********************************************************************
> >>>> > # Wrapper Java Properties
> >>>> >
> #********************************************************************
> >>>> > # Java Application
> >>>> > #  Locate the java binary on the system PATH:
> >>>> > #wrapper.java.command=java
> >>>> > #  Specify a specific java binary:
> >>>> > set.JBOSS_HOME=D:\jboss-as-7.0.0.Final
> >>>> > set.JAVA_HOME=C:\Program Files\Java\jdk1.6.0_16
> >>>> > wrapper.java.command=%JAVA_HOME%/bin/java
> >>>> > # Tell the Wrapper to log the full generated Java command line.
> >>>> > wrapper.java.command.loglevel=INFO
> >>>> > # Java Main class.  This class must implement the WrapperListener
> >>>> > interface
> >>>> > #  or guarantee that the WrapperManager class is initialized.
>  Helper
> >>>> > #  classes are provided to do this for you.  See the Integration
> >>>> > section
> >>>> > #  of the documentation for details.
> >>>> > wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
> >>>> > # Java Classpath (include wrapper.jar)  Add class path elements as
> >>>> > #  needed starting from 1
> >>>> > wrapper.java.classpath.1=%JBOSS_HOME%/lib/wrapper.jar
> >>>> > wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
> >>>> > wrapper.java.classpath.3=%JBOSS_HOME%/bin/run.jar
> >>>> > wrapper.java.classpath.4=%JBOSS_HOME%/jboss-modules.jar
> >>>> > # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> >>>> > wrapper.java.library.path.1=%JBOSS_HOME%/lib
> >>>> > # Java Bits.  On applicable platforms, tells the JVM to run in 32 or
> >>>> > 64-bit
> >>>> > mode.
> >>>> > wrapper.java.additional.auto_bits=TRUE
> >>>> > # Java Additional Parameters
> >>>> > #wrapper.java.additional.1=-server
> >>>> > wrapper.java.additional.1=-XX:MaxPermSize=256m
> >>>> > wrapper.java.additional.2=-Dorg.jboss.resolver.warning=true
> >>>> > wrapper.java.additional.3=-Dsun.rmi.dgc.client.gcInterval=3600000
> >>>> > wrapper.java.additional.4=-Dsun.rmi.dgc.server.gcInterval=3600000
> >>>> >
> >>>> >
> wrapper.java.additional.5=-Djboss.modules.system.pkgs=org.jboss.byteman
> >>>> >
> >>>> >
> wrapper.java.additional.6=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
> >>>> >
> >>>> >
> wrapper.java.additional.7=-Dlogging.configuration=file:%JBOSS_HOME%/standalone/configuration/logging.properties
> >>>> > # Initial Java Heap Size (in MB)
> >>>> > #wrapper.java.initmemory=128
> >>>> > # Maximum Java Heap Size (in MB)
> >>>> > #wrapper.java.maxmemory=512
> >>>> > # Application parameters.  Add parameters as needed starting from 1
> >>>> > wrapper.app.parameter.1=%JBOSS_HOME%/jboss-modules.jar
> >>>> > wrapper.app.parameter.2=-mp
> >>>> > wrapper.app.parameter.2=%JBOSS_HOME%\modules
> >>>> > wrapper.app.parameter.3=-logmodule
> >>>> > wrapper.app.parameter.3=org.jboss.logmanager
> >>>> > wrapper.app.parameter.4=-jaxpmodule
> >>>> > wrapper.app.parameter.4=javax.xml.jaxp-provider
> >>>> > wrapper.app.parameter.4=org.jboss.as.standalone
> >>>> > wrapper.app.parameter.9=-Djboss.home.dir=%JBOSS_HOME%
> >>>> >
> >>>> >
> #********************************************************************
> >>>> > # Wrapper Logging Properties
> >>>> >
> #********************************************************************
> >>>> > # Enables Debug output from the Wrapper.
> >>>> > wrapper.debug=TRUE
> >>>> > # Format of output for the console.  (See docs for formats)
> >>>> > wrapper.console.format=PM
> >>>> > # Log Level for console output.  (See docs for log levels)
> >>>> > wrapper.console.loglevel=INFO
> >>>> > # Log file to use for wrapper output logging.
> >>>> > wrapper.logfile=../standalone/log/wrapper.log
> >>>> > # Format of output for the log file.  (See docs for formats)
> >>>> > wrapper.logfile.format=LPTM
> >>>> > # Log Level for log file output.  (See docs for log levels)
> >>>> > wrapper.logfile.loglevel=INFO
> >>>> > # Maximum size that the log file will be allowed to grow to before
> >>>> > #  the log is rolled. Size is specified in bytes.  The default value
> >>>> > #  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
> >>>> > #  'm' (mb) suffix.  For example: 10m = 10 megabytes.
> >>>> > wrapper.logfile.maxsize=0
> >>>> > # Maximum number of rolled log files which will be allowed before
> old
> >>>> > #  files are deleted.  The default value of 0 implies no limit.
> >>>> > wrapper.logfile.maxfiles=0
> >>>> > # Log Level for sys/event log output.  (See docs for log levels)
> >>>> > wrapper.syslog.loglevel=NONE
> >>>> >
> #********************************************************************
> >>>> > # Wrapper General Properties
> >>>> >
> #********************************************************************
> >>>> > # Allow for the use of non-contiguous numbered properties
> >>>> > #wrapper.ignore_sequence_gaps=TRUE
> >>>> > # Title to use when running as a console
> >>>> > #wra...@ap...@
> >>>> >
> #********************************************************************
> >>>> > # Wrapper JVM Checks
> >>>> >
> #********************************************************************
> >>>> > # Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
> >>>> > #wrapper.check.deadlock=TRUE
> >>>> > #wrapper.check.deadlock.interval=60
> >>>> > #wrapper.check.deadlock.action=RESTART
> >>>> > #wrapper.check.deadlock.output=FULL
> >>>> > # Out Of Memory detection.
> >>>> > # (Simple match)
> >>>> > #wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
> >>>> > # (Only match text in stack traces if -XX:+PrintClassHistogram is
> >>>> > being
> >>>> > used.)
> >>>> > #wrapper.filter.trigger.1000=Exception in thread "*"
> >>>> > java.lang.OutOfMemoryError
> >>>> > #wrapper.filter.allow_wildcards.1000=TRUE
> >>>> > #wrapper.filter.action.1000=RESTART
> >>>> > #wrapper.filter.message.1000=The JVM has run out of memory.
> >>>> >
> #********************************************************************
> >>>> > # Wrapper Email Notifications. (Requires Professional Edition)
> >>>> >
> #********************************************************************
> >>>> > # Common Event Email settings.
> >>>> > #wrapper.event.default.email.debug=TRUE
> >>>> > #wrapper.event.default.email.smtp.host=<SMTP_Host>
> >>>> > #wrapper.event.default.email.smtp.port=25
> >>>> >
> >>>> >
> #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
> >>>> > Event Notification
> >>>> > #wrapper.event.default.email.sender=<Sender email>
> >>>> > #wrapper.event.default.email.recipient=<Recipient email>
> >>>> > # Configure the log attached to event emails.
> >>>> > #wrapper.event.default.email.attach_log=TRUE
> >>>> > #wrapper.event.default.email.maillog.lines=50
> >>>> > #wrapper.event.default.email.maillog.format=LPTM
> >>>> > #wrapper.event.default.email.maillog.loglevel=INFO
> >>>> > # Enable specific event emails.
> >>>> > #wrapper.event.wrapper_start.email=TRUE
> >>>> > #wrapper.event.jvm_prelaunch.email=TRUE
> >>>> > #wrapper.event.jvm_start.email=TRUE
> >>>> > #wrapper.event.jvm_started.email=TRUE
> >>>> > #wrapper.event.jvm_deadlock.email=TRUE
> >>>> > #wrapper.event.jvm_stop.email=TRUE
> >>>> > #wrapper.event.jvm_stopped.email=TRUE
> >>>> > #wrapper.event.jvm_restart.email=TRUE
> >>>> > #wrapper.event.jvm_failed_invocation.email=TRUE
> >>>> > #wrapper.event.jvm_max_failed_invocations.email=TRUE
> >>>> > #wrapper.event.jvm_kill.email=TRUE
> >>>> > #wrapper.event.jvm_killed.email=TRUE
> >>>> > #wrapper.event.jvm_unexpected_exit.email=TRUE
> >>>> > #wrapper.event.wrapper_stop.email=TRUE
> >>>> > # Specify custom mail content
> >>>> > #wrapper.event.jvm_restart.email.body=The JVM was
> restarted.\n\nPlease
> >>>> > check
> >>>> > on its status.\n
> >>>> > Anyone know what's going on?  Do these errors have to do with my 32
> >>>> > bit
> >>>> > version?  If we need to upgrade to pro we'll do so.  Thanks!
> >>>> >
> >>>> >
> >>>> >
> ------------------------------------------------------------------------------
> >>>> > Using storage to extend the benefits of virtualization and iSCSI
> >>>> > Virtualization increases hardware utilization and delivers a new
> level
> >>>> > of
> >>>> > agility. Learn what those decisions are and how to modernize your
> >>>> > storage
> >>>> > and backup environments for virtualization.
> >>>> > http://www.accelacomm.com/jaw/sfnl/114/51434361/
> >>>> > _______________________________________________
> >>>> > Wrapper-user mailing list
> >>>> > Wra...@li...
> >>>> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> Doing More with Less: The Next Generation Virtual Desktop
> >>>> What are the key obstacles that have prevented many mid-market
> >>>> businesses
> >>>> from deploying virtual desktops?   How do next-generation virtual
> >>>> desktops
> >>>> provide companies an easier-to-deploy, easier-to-manage and more
> >>>> affordable
> >>>> virtual desktop model.
> http://www.accelacomm.com/jaw/sfnl/114/51426474/
> >>>> _______________________________________________
> >>>> Wrapper-user mailing list
> >>>> Wra...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Doing More with Less: The Next Generation Virtual Desktop
> >>> What are the key obstacles that have prevented many mid-market
> businesses
> >>> from deploying virtual desktops?   How do next-generation virtual
> >>> desktops
> >>> provide companies an easier-to-deploy, easier-to-manage and more
> >>> affordable
> >>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> >>> _______________________________________________
> >>> Wrapper-user mailing list
> >>> Wra...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >>>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Why Cloud-Based Security and Archiving Make Sense
> > Osterman Research conducted this study that outlines how and why cloud
> > computing security and archiving is rapidly being adopted across the IT
> > space for its ease of implementation, lower cost, and increased
> > reliability. Learn more.
> http://www.accelacomm.com/jaw/sfnl/114/51425301/
> > _______________________________________________
> > Wrapper-user mailing list
> > Wra...@li...
> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
> >
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] JBoss AS7 problems

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

Hi,

Please see the output 1 line above the message you posted:
Load native library. One or more attempts may fail if platform
specific libraries do not exist.  This is NORMAL and is only a problem
if they all fail.

The Wrapper tries first to load the library according to the OS-arch
format we are using in the delta pack. You are running windows on a
x86 32 bit machine, so this derives to wrapper-windows-x86-32.dll
Since you are not running the delta pack, there is only a wrapper.dll
file, so in the next attempt, the wrapper tries to load wrapper.dll

This is successful as the output states:
INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
Loaded native library:

INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug: Loaded
native localization method.

INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:
Calling native initialization method.

INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug:
Initializing WrapperManager native library.

INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug: Java
Executable: C:\Program Files\Java\jdk1.6.0_16\bin\java.exe

INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperJNI Debug: Native
Library: D:\jboss-as-7.0.0.Final\lib\wrapper.dll


So there is nothing wrong with the native library.

However I see the following in your conf file:
wrapper.app.parameter.1=%JBOSS_HOME%\bin\run.jar

I think it is better to change it to:
wrapper.app.parameter.1=../jboss-modules.jar

Also in your classpath with the above mentioned,
wrapper.java.classpath.2 and wrapper.java.classpath.3 can be removed
and classpath.1&4 is only needed.

Please let me know if you have any further questions.

Thank you,
Christian


On Fri, Sep 9, 2011 at 9:50 AM, Charles <cpr...@go...> wrote:
> copy wrapper.dll to
> %JBOSS_HOME%\lib
> and set
> wrapper.java.library.path.1=%JBOSS_HOME%\lib
> in the conf file in %JBOSS_HOME%\conf
>
>
> On Fri, Sep 9, 2011 at 2:48 AM, Charles <cpr...@go...> wrote:
>>
>> copy wrapper.dll to
>> %JBOSS_HOME%\lib
>> and set
>> wrapper.java.library.path.1=%JBOSS_HOME%\lib
>> in the conf file in %JBOSS_HOME%\conf
>>
>> On Thu, Sep 8, 2011 at 6:34 PM, qt4x11 <qt...@gm...> wrote:
>>>
>>> Thanks, I've been following your advice and used method 4.  I believe I'm
>>> pretty close to making it work.  Right now I'm receiving the error message
>>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:   Unable
>>> to load native library: wrapper-windows-x86-32.dll  Cause: no
>>> wrapper-windows-x86-32 in java.library.path
>>> It seems like wrapper is not able to load the native library?  I'm not
>>> sure why this is - I've made sure that java.library.path config option
>>> points to the location of a valid wrapper.dll file.  I'm attaching my
>>> current conf file and recent logs, if you can take a look
>>>
>>> On Wed, Sep 7, 2011 at 8:38 PM, Christian Mueller
>>> <chr...@ta...> wrote:
>>>>
>>>> Hi,
>>>>
>>>> JBoss AS7 has changed in several ways how it is launching.
>>>>
>>>> You are using Integration method 1, however it seems that you are
>>>> passing in a jar file as the first parameter to
>>>> org.tanukisoftware.wrapper.WrapperSimpleApp. WrapperSimpleApp expects
>>>> the name of your main class as parameter. So you should go for
>>>> integration method 4 and pass the jar file to
>>>> org.tanukisoftware.wrapper.WrapperJarApp.
>>>>
>>>> We have had some guys recently with the same questions and helped them
>>>> resolving the problem:
>>>>
>>>> https://issues.jboss.org/browse/AS7-1547
>>>>
>>>> Hope this information helps you out.
>>>>
>>>> Please let me know if you have any further questions.
>>>>
>>>> Thank you,
>>>> Christian
>>>>
>>>> PS: I also replied with above answer to your question on stackoverflow
>>>> as well.
>>>>
>>>> On Thu, Sep 8, 2011 at 12:41 AM, qt4x11 <qt...@gm...> wrote:
>>>> > I'm trying to use jsw 3.3.5 32 bit with JBoss AS7 on a Windows 7 64
>>>> > bit
>>>> > machine.  I have a hunch the reason I'm having problems is due our 32
>>>> > bit
>>>> > version, but we have been able to use the 32 bit version of jsw with
>>>> > other
>>>> > applications (ActiveMQ) successfully, so I thought I'd try the 32 bit
>>>> > version first.  If it's advisable to upgrade to the pro version we
>>>> > will do
>>>> > so.
>>>> > I'm pasting my wrapper.log and wrapper.conf below.  Right now the
>>>> > service is
>>>> > not able to start normally.  I tried troubleshooting the
>>>> >  UnsatisfiedLinkError: no wrapper-windows-x86-32 in java.library.path
>>>> > error
>>>> > by making sure jsw was finding my java.library.path by hard coding
>>>> > paths for
>>>> > JAVA_HOME and JBOSS_HOME in my conf.  The second error seems unusual
>>>> > to me,
>>>> > as  D:\jboss-as-7.0.0.Final/jboss-module.jar definitely exists on the
>>>> > file
>>>> > system.
>>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | --> Wrapper Started as
>>>> > Console
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Using tick timer.
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | server listening on port
>>>> > 32001.
>>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | Launching a JVM...
>>>> > INFO   | wrapper  | 2011/09/07 08:01:33 | command: "C:\Program
>>>> > Files\Java\jdk1.6.0_16\bin\java" -XX:MaxPermSize=256m
>>>> > -Dorg.jboss.resolver.warning=true
>>>> > -Dsun.rmi.dgc.client.gcInterval=3600000
>>>> > -Dsun.rmi.dgc.server.gcInterval=3600000
>>>> > -Djboss.modules.system.pkgs=org.jboss.byteman
>>>> > -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
>>>> >
>>>> > -Dlogging.configuration=file:D:\jboss-as-7.0.0.Final/standalone/configuration/logging.properties
>>>> > -Djava.library.path="D:\jboss-as-7.0.0.Final/lib" -classpath
>>>> > "D:\jboss-as-7.0.0.Final/lib/wrapper.jar;C:\Program
>>>> >
>>>> > Files\Java\jdk1.6.0_16/lib/tools.jar;D:\jboss-as-7.0.0.Final/bin/run.jar;D:\jboss-as-7.0.0.Final/jboss-modules.jar"
>>>> > -Dwrapper.key="ExYkelyCNrKjXXAf" -Dwrapper.port=32001
>>>> > -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
>>>> > -Dwrapper.debug="TRUE" -Dwrapper.pid=3200 -Dwrapper.version="3.2.3"
>>>> > -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
>>>> > -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp
>>>> > D:\jboss-as-7.0.0.Final/jboss-modules.jar
>>>> > D:\jboss-as-7.0.0.Final\modules
>>>> > org.jboss.logmanager org.jboss.as.standalone
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM started (PID=3336)
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager class
>>>> > initialized
>>>> > by thread: main  Using classloader:
>>>> > sun.misc.Launcher$AppClassLoader@11b86e7
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper (Version 3.2.3)
>>>> > http://wrapper.tanukisoftware.org
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   Copyright 1999-2006 Tanuki
>>>> > Software, Inc.  All Rights Reserved.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: JVM #1
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Running a 32-bit JVM.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Registering
>>>> > shutdown hook
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Using
>>>> > wrapper
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Load native library.  One or
>>>> > more
>>>> > attempts may fail if platform specific libraries do not exist.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loading native library
>>>> > failed:
>>>> > wrapper-windows-x86-32.dll  Cause: java.lang.UnsatisfiedLinkError: no
>>>> > wrapper-windows-x86-32 in java.library.path
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loaded native library:
>>>> > wrapper.dll
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Calling native
>>>> > initialization
>>>> > method.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Initializing WrapperManager
>>>> > native
>>>> > library.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Executable: C:\Program
>>>> > Files\Java\jdk1.6.0_16\bin\java.exe
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Windows version: 5.2.3790
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Version   :
>>>> > 1.6.0_16-b01 Java
>>>> > HotSpot(TM) Client VM
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java VM Vendor : Sun
>>>> > Microsystems
>>>> > Inc.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp: Unable to
>>>> > locate
>>>> > the class D:\jboss-as-7.0.0.Final/jboss-modules.jar:
>>>> > java.lang.ClassNotFoundException:
>>>> > D:\jboss-as-7.0.0.Final/jboss-modules.jar
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp Usage:
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   java
>>>> > org.tanukisoftware.wrapper.WrapperSimpleApp {app_class}
>>>> > [app_arguments]
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Where:
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_class:      The fully
>>>> > qualified class name of the application to run.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_arguments:  The
>>>> > arguments
>>>> > that would normally be passed to the
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>>> > application.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager.stop(1)
>>>> > called by
>>>> > thread: main
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Control event monitor thread
>>>> > started.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Startup runner thread
>>>> > started.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Communications runner thread
>>>> > started.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Open socket to
>>>> > wrapper...Wrapper-Connection
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>>> > local
>>>> > port 31000
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>>> > local
>>>> > port 31001
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>>> > local
>>>> > port 31002
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>>> > local
>>>> > port 31003
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Opened Socket from 31004 to
>>>> > 32001
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet KEY :
>>>> > ExYkelyCNrKjXXAf
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>>> > handleSocket(Socket[addr=/127.0.0.1,port=32001,localport=31004])
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet STOP : 1
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | accepted a socket from
>>>> > 127.0.0.1
>>>> > on port 31004
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet KEY :
>>>> > ExYkelyCNrKjXXAf
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Got key from JVM:
>>>> > ExYkelyCNrKjXXAf
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet LOW_LOG_LEVEL
>>>> > : 1
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PING_TIMEOUT :
>>>> > 30
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PROPERTIES :
>>>> > (Property Values)
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet STOP : 1
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM requested a shutdown.
>>>> > (1)
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | wrapperStopProcess(1)
>>>> > called.
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Sending stop signal to JVM
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet STOP : NULL
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
>>>> > LOW_LOG_LEVEL :
>>>> > 1
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: LowLogLevel
>>>> > from
>>>> > Wrapper is 1
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
>>>> > PING_TIMEOUT :
>>>> > 30
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | PingTimeout from Wrapper is
>>>> > 30000
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet PROPERTIES
>>>> > :
>>>> > (Property Values)
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet STOP :
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Thread, main, handling the
>>>> > shutdown process.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | shutdownJVM(1) Thread:main
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Send a packet STOPPED : 1
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | read a packet STOPPED : 1
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:34 | JVM signalled that it was
>>>> > stopped.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closing socket.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closed socket:
>>>> > java.net.SocketException: socket closed
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | socket read no code
>>>> > (closed?).
>>>> > DEBUG  | wrapperp | 2011/09/07 08:01:35 | server listening on port
>>>> > 32002.
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | Server daemon shut down
>>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | calling System.exit(1)
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM process exited with a
>>>> > code of
>>>> > 1, however the wrapper exit code was already 1.
>>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM exited normally.
>>>> > STATUS | wrapper  | 2011/09/07 08:01:35 | <-- Wrapper Stopped
>>>> > My wrapper.conf is below
>>>> > #encoding=UTF-8
>>>> > # Configuration files must begin with a line specifying the encoding
>>>> > #  of the the file.
>>>> > #********************************************************************
>>>> > # Wrapper License Properties (Ignored by Community Edition)
>>>> > #********************************************************************
>>>> > # Professional and Standard Editions of the Wrapper require a valid
>>>> > #  License Key to start.  Licenses can be purchased or a trial license
>>>> > #  requested on the following pages:
>>>> > # http://wrapper.tanukisoftware.com/purchase
>>>> > # http://wrapper.tanukisoftware.com/trial
>>>> > # Include file problems can be debugged by removing the first '#'
>>>> > #  from the following line:
>>>> > ##include.debug
>>>> > # The Wrapper will look for either of the following optional files for
>>>> > a
>>>> > #  valid License Key.  License Key properties can optionally be
>>>> > included
>>>> > #  directly in this configuration file.
>>>> > #include ../conf/wrapper-license.conf
>>>> > #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
>>>> > # The following property will output information about which License
>>>> > Key(s)
>>>> > #  are being found, and can aid in resolving any licensing problems.
>>>> > #wrapper.license.debug=TRUE
>>>> > #********************************************************************
>>>> > # Wrapper Localization
>>>> > #********************************************************************
>>>> > # Specify the locale which the Wrapper should use.  By default the
>>>> > system
>>>> > #  locale is used.
>>>> > #wrapper.lang=en_US # en_US or ja_JP
>>>> > # Specify the location of the Wrapper's language resources.  If these
>>>> > are
>>>> > #  missing, the Wrapper will default to the en_US locale.
>>>> > wrapper.lang.folder=../lang
>>>> > #********************************************************************
>>>> > # Wrapper Java Properties
>>>> > #********************************************************************
>>>> > # Java Application
>>>> > #  Locate the java binary on the system PATH:
>>>> > #wrapper.java.command=java
>>>> > #  Specify a specific java binary:
>>>> > set.JBOSS_HOME=D:\jboss-as-7.0.0.Final
>>>> > set.JAVA_HOME=C:\Program Files\Java\jdk1.6.0_16
>>>> > wrapper.java.command=%JAVA_HOME%/bin/java
>>>> > # Tell the Wrapper to log the full generated Java command line.
>>>> > wrapper.java.command.loglevel=INFO
>>>> > # Java Main class.  This class must implement the WrapperListener
>>>> > interface
>>>> > #  or guarantee that the WrapperManager class is initialized.  Helper
>>>> > #  classes are provided to do this for you.  See the Integration
>>>> > section
>>>> > #  of the documentation for details.
>>>> > wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>>>> > # Java Classpath (include wrapper.jar)  Add class path elements as
>>>> > #  needed starting from 1
>>>> > wrapper.java.classpath.1=%JBOSS_HOME%/lib/wrapper.jar
>>>> > wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
>>>> > wrapper.java.classpath.3=%JBOSS_HOME%/bin/run.jar
>>>> > wrapper.java.classpath.4=%JBOSS_HOME%/jboss-modules.jar
>>>> > # Java Library Path (location of Wrapper.DLL or libwrapper.so)
>>>> > wrapper.java.library.path.1=%JBOSS_HOME%/lib
>>>> > # Java Bits.  On applicable platforms, tells the JVM to run in 32 or
>>>> > 64-bit
>>>> > mode.
>>>> > wrapper.java.additional.auto_bits=TRUE
>>>> > # Java Additional Parameters
>>>> > #wrapper.java.additional.1=-server
>>>> > wrapper.java.additional.1=-XX:MaxPermSize=256m
>>>> > wrapper.java.additional.2=-Dorg.jboss.resolver.warning=true
>>>> > wrapper.java.additional.3=-Dsun.rmi.dgc.client.gcInterval=3600000
>>>> > wrapper.java.additional.4=-Dsun.rmi.dgc.server.gcInterval=3600000
>>>> >
>>>> > wrapper.java.additional.5=-Djboss.modules.system.pkgs=org.jboss.byteman
>>>> >
>>>> > wrapper.java.additional.6=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
>>>> >
>>>> > wrapper.java.additional.7=-Dlogging.configuration=file:%JBOSS_HOME%/standalone/configuration/logging.properties
>>>> > # Initial Java Heap Size (in MB)
>>>> > #wrapper.java.initmemory=128
>>>> > # Maximum Java Heap Size (in MB)
>>>> > #wrapper.java.maxmemory=512
>>>> > # Application parameters.  Add parameters as needed starting from 1
>>>> > wrapper.app.parameter.1=%JBOSS_HOME%/jboss-modules.jar
>>>> > wrapper.app.parameter.2=-mp
>>>> > wrapper.app.parameter.2=%JBOSS_HOME%\modules
>>>> > wrapper.app.parameter.3=-logmodule
>>>> > wrapper.app.parameter.3=org.jboss.logmanager
>>>> > wrapper.app.parameter.4=-jaxpmodule
>>>> > wrapper.app.parameter.4=javax.xml.jaxp-provider
>>>> > wrapper.app.parameter.4=org.jboss.as.standalone
>>>> > wrapper.app.parameter.9=-Djboss.home.dir=%JBOSS_HOME%
>>>> >
>>>> > #********************************************************************
>>>> > # Wrapper Logging Properties
>>>> > #********************************************************************
>>>> > # Enables Debug output from the Wrapper.
>>>> > wrapper.debug=TRUE
>>>> > # Format of output for the console.  (See docs for formats)
>>>> > wrapper.console.format=PM
>>>> > # Log Level for console output.  (See docs for log levels)
>>>> > wrapper.console.loglevel=INFO
>>>> > # Log file to use for wrapper output logging.
>>>> > wrapper.logfile=../standalone/log/wrapper.log
>>>> > # Format of output for the log file.  (See docs for formats)
>>>> > wrapper.logfile.format=LPTM
>>>> > # Log Level for log file output.  (See docs for log levels)
>>>> > wrapper.logfile.loglevel=INFO
>>>> > # Maximum size that the log file will be allowed to grow to before
>>>> > #  the log is rolled. Size is specified in bytes.  The default value
>>>> > #  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
>>>> > #  'm' (mb) suffix.  For example: 10m = 10 megabytes.
>>>> > wrapper.logfile.maxsize=0
>>>> > # Maximum number of rolled log files which will be allowed before old
>>>> > #  files are deleted.  The default value of 0 implies no limit.
>>>> > wrapper.logfile.maxfiles=0
>>>> > # Log Level for sys/event log output.  (See docs for log levels)
>>>> > wrapper.syslog.loglevel=NONE
>>>> > #********************************************************************
>>>> > # Wrapper General Properties
>>>> > #********************************************************************
>>>> > # Allow for the use of non-contiguous numbered properties
>>>> > #wrapper.ignore_sequence_gaps=TRUE
>>>> > # Title to use when running as a console
>>>> > #wra...@ap...@
>>>> > #********************************************************************
>>>> > # Wrapper JVM Checks
>>>> > #********************************************************************
>>>> > # Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
>>>> > #wrapper.check.deadlock=TRUE
>>>> > #wrapper.check.deadlock.interval=60
>>>> > #wrapper.check.deadlock.action=RESTART
>>>> > #wrapper.check.deadlock.output=FULL
>>>> > # Out Of Memory detection.
>>>> > # (Simple match)
>>>> > #wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
>>>> > # (Only match text in stack traces if -XX:+PrintClassHistogram is
>>>> > being
>>>> > used.)
>>>> > #wrapper.filter.trigger.1000=Exception in thread "*"
>>>> > java.lang.OutOfMemoryError
>>>> > #wrapper.filter.allow_wildcards.1000=TRUE
>>>> > #wrapper.filter.action.1000=RESTART
>>>> > #wrapper.filter.message.1000=The JVM has run out of memory.
>>>> > #********************************************************************
>>>> > # Wrapper Email Notifications. (Requires Professional Edition)
>>>> > #********************************************************************
>>>> > # Common Event Email settings.
>>>> > #wrapper.event.default.email.debug=TRUE
>>>> > #wrapper.event.default.email.smtp.host=<SMTP_Host>
>>>> > #wrapper.event.default.email.smtp.port=25
>>>> >
>>>> > #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
>>>> > Event Notification
>>>> > #wrapper.event.default.email.sender=<Sender email>
>>>> > #wrapper.event.default.email.recipient=<Recipient email>
>>>> > # Configure the log attached to event emails.
>>>> > #wrapper.event.default.email.attach_log=TRUE
>>>> > #wrapper.event.default.email.maillog.lines=50
>>>> > #wrapper.event.default.email.maillog.format=LPTM
>>>> > #wrapper.event.default.email.maillog.loglevel=INFO
>>>> > # Enable specific event emails.
>>>> > #wrapper.event.wrapper_start.email=TRUE
>>>> > #wrapper.event.jvm_prelaunch.email=TRUE
>>>> > #wrapper.event.jvm_start.email=TRUE
>>>> > #wrapper.event.jvm_started.email=TRUE
>>>> > #wrapper.event.jvm_deadlock.email=TRUE
>>>> > #wrapper.event.jvm_stop.email=TRUE
>>>> > #wrapper.event.jvm_stopped.email=TRUE
>>>> > #wrapper.event.jvm_restart.email=TRUE
>>>> > #wrapper.event.jvm_failed_invocation.email=TRUE
>>>> > #wrapper.event.jvm_max_failed_invocations.email=TRUE
>>>> > #wrapper.event.jvm_kill.email=TRUE
>>>> > #wrapper.event.jvm_killed.email=TRUE
>>>> > #wrapper.event.jvm_unexpected_exit.email=TRUE
>>>> > #wrapper.event.wrapper_stop.email=TRUE
>>>> > # Specify custom mail content
>>>> > #wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease
>>>> > check
>>>> > on its status.\n
>>>> > Anyone know what's going on?  Do these errors have to do with my 32
>>>> > bit
>>>> > version?  If we need to upgrade to pro we'll do so.  Thanks!
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Using storage to extend the benefits of virtualization and iSCSI
>>>> > Virtualization increases hardware utilization and delivers a new level
>>>> > of
>>>> > agility. Learn what those decisions are and how to modernize your
>>>> > storage
>>>> > and backup environments for virtualization.
>>>> > http://www.accelacomm.com/jaw/sfnl/114/51434361/
>>>> > _______________________________________________
>>>> > Wrapper-user mailing list
>>>> > Wra...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>> >
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Doing More with Less: The Next Generation Virtual Desktop
>>>> What are the key obstacles that have prevented many mid-market
>>>> businesses
>>>> from deploying virtual desktops?   How do next-generation virtual
>>>> desktops
>>>> provide companies an easier-to-deploy, easier-to-manage and more
>>>> affordable
>>>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>>>> _______________________________________________
>>>> Wrapper-user mailing list
>>>> Wra...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Doing More with Less: The Next Generation Virtual Desktop
>>> What are the key obstacles that have prevented many mid-market businesses
>>> from deploying virtual desktops?   How do next-generation virtual
>>> desktops
>>> provide companies an easier-to-deploy, easier-to-manage and more
>>> affordable
>>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] JBoss AS7 problems

[Charles <cpr...@go...>]

copy wrapper.dll to

%JBOSS_HOME%\lib

and set

wrapper.java.library.path.1=%JBOSS_HOME%\lib

in the conf file in %JBOSS_HOME%\conf



On Fri, Sep 9, 2011 at 2:48 AM, Charles <cpr...@go...> wrote:

> copy wrapper.dll to
>
> %JBOSS_HOME%\lib
>
> and set
>
> wrapper.java.library.path.1=%JBOSS_HOME%\lib
>
> in the conf file in %JBOSS_HOME%\conf
>
>
> On Thu, Sep 8, 2011 at 6:34 PM, qt4x11 <qt...@gm...> wrote:
>
>> Thanks, I've been following your advice and used method 4.  I believe I'm
>> pretty close to making it work.  Right now I'm receiving the error message
>>
>> INFO   | jvm 1    | 2011/09/08 08:17:41 | WrapperManager Debug:   Unable
>> to load native library: wrapper-windows-x86-32.dll  Cause: no
>> wrapper-windows-x86-32 in java.library.path
>>
>> It seems like wrapper is not able to load the native library?  I'm not
>> sure why this is - I've made sure that java.library.path config option
>> points to the location of a valid wrapper.dll file.  I'm attaching my
>> current conf file and recent logs, if you can take a look
>>
>>
>> On Wed, Sep 7, 2011 at 8:38 PM, Christian Mueller <
>> chr...@ta...> wrote:
>>
>>> Hi,
>>>
>>> JBoss AS7 has changed in several ways how it is launching.
>>>
>>> You are using Integration method 1, however it seems that you are
>>> passing in a jar file as the first parameter to
>>> org.tanukisoftware.wrapper.WrapperSimpleApp. WrapperSimpleApp expects
>>> the name of your main class as parameter. So you should go for
>>> integration method 4 and pass the jar file to
>>> org.tanukisoftware.wrapper.WrapperJarApp.
>>>
>>> We have had some guys recently with the same questions and helped them
>>> resolving the problem:
>>>
>>> https://issues.jboss.org/browse/AS7-1547
>>>
>>> Hope this information helps you out.
>>>
>>> Please let me know if you have any further questions.
>>>
>>> Thank you,
>>> Christian
>>>
>>> PS: I also replied with above answer to your question on stackoverflow as
>>> well.
>>>
>>> On Thu, Sep 8, 2011 at 12:41 AM, qt4x11 <qt...@gm...> wrote:
>>> > I'm trying to use jsw 3.3.5 32 bit with JBoss AS7 on a Windows 7 64 bit
>>> > machine.  I have a hunch the reason I'm having problems is due our 32
>>> bit
>>> > version, but we have been able to use the 32 bit version of jsw with
>>> other
>>> > applications (ActiveMQ) successfully, so I thought I'd try the 32 bit
>>> > version first.  If it's advisable to upgrade to the pro version we will
>>> do
>>> > so.
>>> > I'm pasting my wrapper.log and wrapper.conf below.  Right now the
>>> service is
>>> > not able to start normally.  I tried troubleshooting the
>>> >  UnsatisfiedLinkError: no wrapper-windows-x86-32 in java.library.path
>>> error
>>> > by making sure jsw was finding my java.library.path by hard coding
>>> paths for
>>> > JAVA_HOME and JBOSS_HOME in my conf.  The second error seems unusual to
>>> me,
>>> > as  D:\jboss-as-7.0.0.Final/jboss-module.jar definitely exists on the
>>> file
>>> > system.
>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | --> Wrapper Started as
>>> Console
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Using tick timer.
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | server listening on port
>>> 32001.
>>> > STATUS | wrapper  | 2011/09/07 08:01:33 | Launching a JVM...
>>> > INFO   | wrapper  | 2011/09/07 08:01:33 | command: "C:\Program
>>> > Files\Java\jdk1.6.0_16\bin\java" -XX:MaxPermSize=256m
>>> > -Dorg.jboss.resolver.warning=true
>>> -Dsun.rmi.dgc.client.gcInterval=3600000
>>> > -Dsun.rmi.dgc.server.gcInterval=3600000
>>> > -Djboss.modules.system.pkgs=org.jboss.byteman
>>> > -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
>>> >
>>> -Dlogging.configuration=file:D:\jboss-as-7.0.0.Final/standalone/configuration/logging.properties
>>> > -Djava.library.path="D:\jboss-as-7.0.0.Final/lib" -classpath
>>> > "D:\jboss-as-7.0.0.Final/lib/wrapper.jar;C:\Program
>>> >
>>> Files\Java\jdk1.6.0_16/lib/tools.jar;D:\jboss-as-7.0.0.Final/bin/run.jar;D:\jboss-as-7.0.0.Final/jboss-modules.jar"
>>> > -Dwrapper.key="ExYkelyCNrKjXXAf" -Dwrapper.port=32001
>>> > -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
>>> > -Dwrapper.debug="TRUE" -Dwrapper.pid=3200 -Dwrapper.version="3.2.3"
>>> > -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
>>> > -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp
>>> > D:\jboss-as-7.0.0.Final/jboss-modules.jar
>>> D:\jboss-as-7.0.0.Final\modules
>>> > org.jboss.logmanager org.jboss.as.standalone
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM started (PID=3336)
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager class
>>> initialized
>>> > by thread: main  Using classloader:
>>> sun.misc.Launcher$AppClassLoader@11b86e7
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper (Version 3.2.3)
>>> > http://wrapper.tanukisoftware.org
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   Copyright 1999-2006 Tanuki
>>> > Software, Inc.  All Rights Reserved.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: JVM #1
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Running a 32-bit JVM.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Registering
>>> > shutdown hook
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Using
>>> wrapper
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Load native library.  One or
>>> more
>>> > attempts may fail if platform specific libraries do not exist.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loading native library
>>> failed:
>>> > wrapper-windows-x86-32.dll  Cause: java.lang.UnsatisfiedLinkError: no
>>> > wrapper-windows-x86-32 in java.library.path
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Loaded native library:
>>> wrapper.dll
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Calling native initialization
>>> > method.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Initializing WrapperManager
>>> native
>>> > library.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Executable: C:\Program
>>> > Files\Java\jdk1.6.0_16\bin\java.exe
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Windows version: 5.2.3790
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Version   : 1.6.0_16-b01
>>> Java
>>> > HotSpot(TM) Client VM
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Java VM Vendor : Sun
>>> Microsystems
>>> > Inc.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp: Unable to
>>> locate
>>> > the class D:\jboss-as-7.0.0.Final/jboss-modules.jar:
>>> > java.lang.ClassNotFoundException:
>>> D:\jboss-as-7.0.0.Final/jboss-modules.jar
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp Usage:
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   java
>>> > org.tanukisoftware.wrapper.WrapperSimpleApp {app_class} [app_arguments]
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Where:
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_class:      The fully
>>> > qualified class name of the application to run.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_arguments:  The
>>> arguments
>>> > that would normally be passed to the
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>> application.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager.stop(1) called
>>> by
>>> > thread: main
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Control event monitor thread
>>> > started.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Startup runner thread
>>> started.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Communications runner thread
>>> > started.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Open socket to
>>> > wrapper...Wrapper-Connection
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>> local
>>> > port 31000
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>> local
>>> > port 31001
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>> local
>>> > port 31002
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using
>>> local
>>> > port 31003
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Opened Socket from 31004 to
>>> 32001
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet KEY :
>>> > ExYkelyCNrKjXXAf
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 |
>>> > handleSocket(Socket[addr=/127.0.0.1,port=32001,localport=31004])
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet STOP : 1
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | accepted a socket from
>>> 127.0.0.1
>>> > on port 31004
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet KEY :
>>> > ExYkelyCNrKjXXAf
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Got key from JVM:
>>> ExYkelyCNrKjXXAf
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet LOW_LOG_LEVEL :
>>> 1
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PING_TIMEOUT :
>>> 30
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PROPERTIES :
>>> > (Property Values)
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet STOP : 1
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM requested a shutdown. (1)
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | wrapperStopProcess(1) called.
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:33 | Sending stop signal to JVM
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet STOP : NULL
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
>>> LOW_LOG_LEVEL :
>>> > 1
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: LowLogLevel
>>> from
>>> > Wrapper is 1
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet
>>> PING_TIMEOUT :
>>> > 30
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | PingTimeout from Wrapper is
>>> 30000
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet PROPERTIES
>>> :
>>> > (Property Values)
>>> > INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet STOP :
>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Thread, main, handling the
>>> > shutdown process.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | shutdownJVM(1) Thread:main
>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Send a packet STOPPED : 1
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | read a packet STOPPED : 1
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:34 | JVM signalled that it was
>>> stopped.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closing socket.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:34 | Closed socket:
>>> > java.net.SocketException: socket closed
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:34 | socket read no code
>>> (closed?).
>>> > DEBUG  | wrapperp | 2011/09/07 08:01:35 | server listening on port
>>> 32002.
>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | Server daemon shut down
>>> > INFO   | jvm 1    | 2011/09/07 08:01:35 | calling System.exit(1)
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM process exited with a
>>> code of
>>> > 1, however the wrapper exit code was already 1.
>>> > DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM exited normally.
>>> > STATUS | wrapper  | 2011/09/07 08:01:35 | <-- Wrapper Stopped
>>> > My wrapper.conf is below
>>> > #encoding=UTF-8
>>> > # Configuration files must begin with a line specifying the encoding
>>> > #  of the the file.
>>> > #********************************************************************
>>> > # Wrapper License Properties (Ignored by Community Edition)
>>> > #********************************************************************
>>> > # Professional and Standard Editions of the Wrapper require a valid
>>> > #  License Key to start.  Licenses can be purchased or a trial license
>>> > #  requested on the following pages:
>>> > # http://wrapper.tanukisoftware.com/purchase
>>> > # http://wrapper.tanukisoftware.com/trial
>>> > # Include file problems can be debugged by removing the first '#'
>>> > #  from the following line:
>>> > ##include.debug
>>> > # The Wrapper will look for either of the following optional files for
>>> a
>>> > #  valid License Key.  License Key properties can optionally be
>>> included
>>> > #  directly in this configuration file.
>>> > #include ../conf/wrapper-license.conf
>>> > #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
>>> > # The following property will output information about which License
>>> Key(s)
>>> > #  are being found, and can aid in resolving any licensing problems.
>>> > #wrapper.license.debug=TRUE
>>> > #********************************************************************
>>> > # Wrapper Localization
>>> > #********************************************************************
>>> > # Specify the locale which the Wrapper should use.  By default the
>>> system
>>> > #  locale is used.
>>> > #wrapper.lang=en_US # en_US or ja_JP
>>> > # Specify the location of the Wrapper's language resources.  If these
>>> are
>>> > #  missing, the Wrapper will default to the en_US locale.
>>> > wrapper.lang.folder=../lang
>>> > #********************************************************************
>>> > # Wrapper Java Properties
>>> > #********************************************************************
>>> > # Java Application
>>> > #  Locate the java binary on the system PATH:
>>> > #wrapper.java.command=java
>>> > #  Specify a specific java binary:
>>> > set.JBOSS_HOME=D:\jboss-as-7.0.0.Final
>>> > set.JAVA_HOME=C:\Program Files\Java\jdk1.6.0_16
>>> > wrapper.java.command=%JAVA_HOME%/bin/java
>>> > # Tell the Wrapper to log the full generated Java command line.
>>> > wrapper.java.command.loglevel=INFO
>>> > # Java Main class.  This class must implement the WrapperListener
>>> interface
>>> > #  or guarantee that the WrapperManager class is initialized.  Helper
>>> > #  classes are provided to do this for you.  See the Integration
>>> section
>>> > #  of the documentation for details.
>>> > wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
>>> > # Java Classpath (include wrapper.jar)  Add class path elements as
>>> > #  needed starting from 1
>>> > wrapper.java.classpath.1=%JBOSS_HOME%/lib/wrapper.jar
>>> > wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
>>> > wrapper.java.classpath.3=%JBOSS_HOME%/bin/run.jar
>>> > wrapper.java.classpath.4=%JBOSS_HOME%/jboss-modules.jar
>>> > # Java Library Path (location of Wrapper.DLL or libwrapper.so)
>>> > wrapper.java.library.path.1=%JBOSS_HOME%/lib
>>> > # Java Bits.  On applicable platforms, tells the JVM to run in 32 or
>>> 64-bit
>>> > mode.
>>> > wrapper.java.additional.auto_bits=TRUE
>>> > # Java Additional Parameters
>>> > #wrapper.java.additional.1=-server
>>> > wrapper.java.additional.1=-XX:MaxPermSize=256m
>>> > wrapper.java.additional.2=-Dorg.jboss.resolver.warning=true
>>> > wrapper.java.additional.3=-Dsun.rmi.dgc.client.gcInterval=3600000
>>> > wrapper.java.additional.4=-Dsun.rmi.dgc.server.gcInterval=3600000
>>> > wrapper.java.additional.5=-Djboss.modules.system.pkgs=org.jboss.byteman
>>> >
>>> wrapper.java.additional.6=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
>>> >
>>> wrapper.java.additional.7=-Dlogging.configuration=file:%JBOSS_HOME%/standalone/configuration/logging.properties
>>> > # Initial Java Heap Size (in MB)
>>> > #wrapper.java.initmemory=128
>>> > # Maximum Java Heap Size (in MB)
>>> > #wrapper.java.maxmemory=512
>>> > # Application parameters.  Add parameters as needed starting from 1
>>> > wrapper.app.parameter.1=%JBOSS_HOME%/jboss-modules.jar
>>> > wrapper.app.parameter.2=-mp
>>> > wrapper.app.parameter.2=%JBOSS_HOME%\modules
>>> > wrapper.app.parameter.3=-logmodule
>>> > wrapper.app.parameter.3=org.jboss.logmanager
>>> > wrapper.app.parameter.4=-jaxpmodule
>>> > wrapper.app.parameter.4=javax.xml.jaxp-provider
>>> > wrapper.app.parameter.4=org.jboss.as.standalone
>>> > wrapper.app.parameter.9=-Djboss.home.dir=%JBOSS_HOME%
>>> >
>>> > #********************************************************************
>>> > # Wrapper Logging Properties
>>> > #********************************************************************
>>> > # Enables Debug output from the Wrapper.
>>> > wrapper.debug=TRUE
>>> > # Format of output for the console.  (See docs for formats)
>>> > wrapper.console.format=PM
>>> > # Log Level for console output.  (See docs for log levels)
>>> > wrapper.console.loglevel=INFO
>>> > # Log file to use for wrapper output logging.
>>> > wrapper.logfile=../standalone/log/wrapper.log
>>> > # Format of output for the log file.  (See docs for formats)
>>> > wrapper.logfile.format=LPTM
>>> > # Log Level for log file output.  (See docs for log levels)
>>> > wrapper.logfile.loglevel=INFO
>>> > # Maximum size that the log file will be allowed to grow to before
>>> > #  the log is rolled. Size is specified in bytes.  The default value
>>> > #  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
>>> > #  'm' (mb) suffix.  For example: 10m = 10 megabytes.
>>> > wrapper.logfile.maxsize=0
>>> > # Maximum number of rolled log files which will be allowed before old
>>> > #  files are deleted.  The default value of 0 implies no limit.
>>> > wrapper.logfile.maxfiles=0
>>> > # Log Level for sys/event log output.  (See docs for log levels)
>>> > wrapper.syslog.loglevel=NONE
>>> > #********************************************************************
>>> > # Wrapper General Properties
>>> > #********************************************************************
>>> > # Allow for the use of non-contiguous numbered properties
>>> > #wrapper.ignore_sequence_gaps=TRUE
>>> > # Title to use when running as a console
>>> > #wra...@ap...@
>>> > #********************************************************************
>>> > # Wrapper JVM Checks
>>> > #********************************************************************
>>> > # Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
>>> > #wrapper.check.deadlock=TRUE
>>> > #wrapper.check.deadlock.interval=60
>>> > #wrapper.check.deadlock.action=RESTART
>>> > #wrapper.check.deadlock.output=FULL
>>> > # Out Of Memory detection.
>>> > # (Simple match)
>>> > #wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
>>> > # (Only match text in stack traces if -XX:+PrintClassHistogram is being
>>> > used.)
>>> > #wrapper.filter.trigger.1000=Exception in thread "*"
>>> > java.lang.OutOfMemoryError
>>> > #wrapper.filter.allow_wildcards.1000=TRUE
>>> > #wrapper.filter.action.1000=RESTART
>>> > #wrapper.filter.message.1000=The JVM has run out of memory.
>>> > #********************************************************************
>>> > # Wrapper Email Notifications. (Requires Professional Edition)
>>> > #********************************************************************
>>> > # Common Event Email settings.
>>> > #wrapper.event.default.email.debug=TRUE
>>> > #wrapper.event.default.email.smtp.host=<SMTP_Host>
>>> > #wrapper.event.default.email.smtp.port=25
>>> >
>>> #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
>>> > Event Notification
>>> > #wrapper.event.default.email.sender=<Sender email>
>>> > #wrapper.event.default.email.recipient=<Recipient email>
>>> > # Configure the log attached to event emails.
>>> > #wrapper.event.default.email.attach_log=TRUE
>>> > #wrapper.event.default.email.maillog.lines=50
>>> > #wrapper.event.default.email.maillog.format=LPTM
>>> > #wrapper.event.default.email.maillog.loglevel=INFO
>>> > # Enable specific event emails.
>>> > #wrapper.event.wrapper_start.email=TRUE
>>> > #wrapper.event.jvm_prelaunch.email=TRUE
>>> > #wrapper.event.jvm_start.email=TRUE
>>> > #wrapper.event.jvm_started.email=TRUE
>>> > #wrapper.event.jvm_deadlock.email=TRUE
>>> > #wrapper.event.jvm_stop.email=TRUE
>>> > #wrapper.event.jvm_stopped.email=TRUE
>>> > #wrapper.event.jvm_restart.email=TRUE
>>> > #wrapper.event.jvm_failed_invocation.email=TRUE
>>> > #wrapper.event.jvm_max_failed_invocations.email=TRUE
>>> > #wrapper.event.jvm_kill.email=TRUE
>>> > #wrapper.event.jvm_killed.email=TRUE
>>> > #wrapper.event.jvm_unexpected_exit.email=TRUE
>>> > #wrapper.event.wrapper_stop.email=TRUE
>>> > # Specify custom mail content
>>> > #wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease
>>> check
>>> > on its status.\n
>>> > Anyone know what's going on?  Do these errors have to do with my 32 bit
>>> > version?  If we need to upgrade to pro we'll do so.  Thanks!
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Using storage to extend the benefits of virtualization and iSCSI
>>> > Virtualization increases hardware utilization and delivers a new level
>>> of
>>> > agility. Learn what those decisions are and how to modernize your
>>> storage
>>> > and backup environments for virtualization.
>>> > http://www.accelacomm.com/jaw/sfnl/114/51434361/
>>> > _______________________________________________
>>> > Wrapper-user mailing list
>>> > Wra...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>> >
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Doing More with Less: The Next Generation Virtual Desktop
>>> What are the key obstacles that have prevented many mid-market businesses
>>> from deploying virtual desktops?   How do next-generation virtual
>>> desktops
>>> provide companies an easier-to-deploy, easier-to-manage and more
>>> affordable
>>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Doing More with Less: The Next Generation Virtual Desktop
>> What are the key obstacles that have prevented many mid-market businesses
>> from deploying virtual desktops?   How do next-generation virtual desktops
>> provide companies an easier-to-deploy, easier-to-manage and more
>> affordable
>> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>

Re: [Wrapper-user] JBoss AS7 problems

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

Hi,

JBoss AS7 has changed in several ways how it is launching.

You are using Integration method 1, however it seems that you are
passing in a jar file as the first parameter to
org.tanukisoftware.wrapper.WrapperSimpleApp. WrapperSimpleApp expects
the name of your main class as parameter. So you should go for
integration method 4 and pass the jar file to
org.tanukisoftware.wrapper.WrapperJarApp.

We have had some guys recently with the same questions and helped them
resolving the problem:

https://issues.jboss.org/browse/AS7-1547

Hope this information helps you out.

Please let me know if you have any further questions.

Thank you,
Christian

PS: I also replied with above answer to your question on stackoverflow as well.

On Thu, Sep 8, 2011 at 12:41 AM, qt4x11 <qt...@gm...> wrote:
> I'm trying to use jsw 3.3.5 32 bit with JBoss AS7 on a Windows 7 64 bit
> machine.  I have a hunch the reason I'm having problems is due our 32 bit
> version, but we have been able to use the 32 bit version of jsw with other
> applications (ActiveMQ) successfully, so I thought I'd try the 32 bit
> version first.  If it's advisable to upgrade to the pro version we will do
> so.
> I'm pasting my wrapper.log and wrapper.conf below.  Right now the service is
> not able to start normally.  I tried troubleshooting the
>  UnsatisfiedLinkError: no wrapper-windows-x86-32 in java.library.path error
> by making sure jsw was finding my java.library.path by hard coding paths for
> JAVA_HOME and JBOSS_HOME in my conf.  The second error seems unusual to me,
> as  D:\jboss-as-7.0.0.Final/jboss-module.jar definitely exists on the file
> system.
> STATUS | wrapper  | 2011/09/07 08:01:33 | --> Wrapper Started as Console
> DEBUG  | wrapper  | 2011/09/07 08:01:33 | Using tick timer.
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | server listening on port 32001.
> STATUS | wrapper  | 2011/09/07 08:01:33 | Launching a JVM...
> INFO   | wrapper  | 2011/09/07 08:01:33 | command: "C:\Program
> Files\Java\jdk1.6.0_16\bin\java" -XX:MaxPermSize=256m
> -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
> -Dsun.rmi.dgc.server.gcInterval=3600000
> -Djboss.modules.system.pkgs=org.jboss.byteman
> -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
> -Dlogging.configuration=file:D:\jboss-as-7.0.0.Final/standalone/configuration/logging.properties
> -Djava.library.path="D:\jboss-as-7.0.0.Final/lib" -classpath
> "D:\jboss-as-7.0.0.Final/lib/wrapper.jar;C:\Program
> Files\Java\jdk1.6.0_16/lib/tools.jar;D:\jboss-as-7.0.0.Final/bin/run.jar;D:\jboss-as-7.0.0.Final/jboss-modules.jar"
> -Dwrapper.key="ExYkelyCNrKjXXAf" -Dwrapper.port=32001
> -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
> -Dwrapper.debug="TRUE" -Dwrapper.pid=3200 -Dwrapper.version="3.2.3"
> -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
> -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp
> D:\jboss-as-7.0.0.Final/jboss-modules.jar D:\jboss-as-7.0.0.Final\modules
> org.jboss.logmanager org.jboss.as.standalone
> DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM started (PID=3336)
> INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager class initialized
> by thread: main  Using classloader: sun.misc.Launcher$AppClassLoader@11b86e7
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper (Version 3.2.3)
> http://wrapper.tanukisoftware.org
> INFO   | jvm 1    | 2011/09/07 08:01:33 |   Copyright 1999-2006 Tanuki
> Software, Inc.  All Rights Reserved.
> INFO   | jvm 1    | 2011/09/07 08:01:33 |
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: JVM #1
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Running a 32-bit JVM.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Registering
> shutdown hook
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Using wrapper
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Load native library.  One or more
> attempts may fail if platform specific libraries do not exist.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Loading native library failed:
> wrapper-windows-x86-32.dll  Cause: java.lang.UnsatisfiedLinkError: no
> wrapper-windows-x86-32 in java.library.path
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Loaded native library: wrapper.dll
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Calling native initialization
> method.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Initializing WrapperManager native
> library.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Executable: C:\Program
> Files\Java\jdk1.6.0_16\bin\java.exe
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Windows version: 5.2.3790
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Version   : 1.6.0_16-b01 Java
> HotSpot(TM) Client VM
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Java VM Vendor : Sun Microsystems
> Inc.
> INFO   | jvm 1    | 2011/09/07 08:01:33 |
> INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp: Unable to locate
> the class D:\jboss-as-7.0.0.Final/jboss-modules.jar:
> java.lang.ClassNotFoundException: D:\jboss-as-7.0.0.Final/jboss-modules.jar
> INFO   | jvm 1    | 2011/09/07 08:01:33 |
> INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp Usage:
> INFO   | jvm 1    | 2011/09/07 08:01:33 |   java
> org.tanukisoftware.wrapper.WrapperSimpleApp {app_class} [app_arguments]
> INFO   | jvm 1    | 2011/09/07 08:01:33 |
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Where:
> INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_class:      The fully
> qualified class name of the application to run.
> INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_arguments:  The arguments
> that would normally be passed to the
> INFO   | jvm 1    | 2011/09/07 08:01:33 |                   application.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager.stop(1) called by
> thread: main
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Control event monitor thread
> started.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Startup runner thread started.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Communications runner thread
> started.
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Open socket to
> wrapper...Wrapper-Connection
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
> port 31000
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
> port 31001
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
> port 31002
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
> port 31003
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Opened Socket from 31004 to 32001
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet KEY :
> ExYkelyCNrKjXXAf
> INFO   | jvm 1    | 2011/09/07 08:01:33 |
> handleSocket(Socket[addr=/127.0.0.1,port=32001,localport=31004])
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet STOP : 1
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | accepted a socket from 127.0.0.1
> on port 31004
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet KEY :
> ExYkelyCNrKjXXAf
> DEBUG  | wrapper  | 2011/09/07 08:01:33 | Got key from JVM: ExYkelyCNrKjXXAf
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet LOW_LOG_LEVEL : 1
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PING_TIMEOUT : 30
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PROPERTIES :
> (Property Values)
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet STOP : 1
> DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM requested a shutdown. (1)
> DEBUG  | wrapper  | 2011/09/07 08:01:33 | wrapperStopProcess(1) called.
> DEBUG  | wrapper  | 2011/09/07 08:01:33 | Sending stop signal to JVM
> DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet STOP : NULL
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet LOW_LOG_LEVEL :
> 1
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: LowLogLevel from
> Wrapper is 1
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet PING_TIMEOUT :
> 30
> INFO   | jvm 1    | 2011/09/07 08:01:33 | PingTimeout from Wrapper is 30000
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet PROPERTIES :
> (Property Values)
> INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet STOP :
> INFO   | jvm 1    | 2011/09/07 08:01:34 | Thread, main, handling the
> shutdown process.
> INFO   | jvm 1    | 2011/09/07 08:01:34 | shutdownJVM(1) Thread:main
> INFO   | jvm 1    | 2011/09/07 08:01:34 | Send a packet STOPPED : 1
> DEBUG  | wrapperp | 2011/09/07 08:01:34 | read a packet STOPPED : 1
> DEBUG  | wrapper  | 2011/09/07 08:01:34 | JVM signalled that it was stopped.
> INFO   | jvm 1    | 2011/09/07 08:01:34 | Closing socket.
> INFO   | jvm 1    | 2011/09/07 08:01:34 | Closed socket:
> java.net.SocketException: socket closed
> DEBUG  | wrapperp | 2011/09/07 08:01:34 | socket read no code (closed?).
> DEBUG  | wrapperp | 2011/09/07 08:01:35 | server listening on port 32002.
> INFO   | jvm 1    | 2011/09/07 08:01:35 | Server daemon shut down
> INFO   | jvm 1    | 2011/09/07 08:01:35 | calling System.exit(1)
> DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM process exited with a code of
> 1, however the wrapper exit code was already 1.
> DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM exited normally.
> STATUS | wrapper  | 2011/09/07 08:01:35 | <-- Wrapper Stopped
> My wrapper.conf is below
> #encoding=UTF-8
> # Configuration files must begin with a line specifying the encoding
> #  of the the file.
> #********************************************************************
> # Wrapper License Properties (Ignored by Community Edition)
> #********************************************************************
> # Professional and Standard Editions of the Wrapper require a valid
> #  License Key to start.  Licenses can be purchased or a trial license
> #  requested on the following pages:
> # http://wrapper.tanukisoftware.com/purchase
> # http://wrapper.tanukisoftware.com/trial
> # Include file problems can be debugged by removing the first '#'
> #  from the following line:
> ##include.debug
> # The Wrapper will look for either of the following optional files for a
> #  valid License Key.  License Key properties can optionally be included
> #  directly in this configuration file.
> #include ../conf/wrapper-license.conf
> #include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf
> # The following property will output information about which License Key(s)
> #  are being found, and can aid in resolving any licensing problems.
> #wrapper.license.debug=TRUE
> #********************************************************************
> # Wrapper Localization
> #********************************************************************
> # Specify the locale which the Wrapper should use.  By default the system
> #  locale is used.
> #wrapper.lang=en_US # en_US or ja_JP
> # Specify the location of the Wrapper's language resources.  If these are
> #  missing, the Wrapper will default to the en_US locale.
> wrapper.lang.folder=../lang
> #********************************************************************
> # Wrapper Java Properties
> #********************************************************************
> # Java Application
> #  Locate the java binary on the system PATH:
> #wrapper.java.command=java
> #  Specify a specific java binary:
> set.JBOSS_HOME=D:\jboss-as-7.0.0.Final
> set.JAVA_HOME=C:\Program Files\Java\jdk1.6.0_16
> wrapper.java.command=%JAVA_HOME%/bin/java
> # Tell the Wrapper to log the full generated Java command line.
> wrapper.java.command.loglevel=INFO
> # Java Main class.  This class must implement the WrapperListener interface
> #  or guarantee that the WrapperManager class is initialized.  Helper
> #  classes are provided to do this for you.  See the Integration section
> #  of the documentation for details.
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
> # Java Classpath (include wrapper.jar)  Add class path elements as
> #  needed starting from 1
> wrapper.java.classpath.1=%JBOSS_HOME%/lib/wrapper.jar
> wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
> wrapper.java.classpath.3=%JBOSS_HOME%/bin/run.jar
> wrapper.java.classpath.4=%JBOSS_HOME%/jboss-modules.jar
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=%JBOSS_HOME%/lib
> # Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit
> mode.
> wrapper.java.additional.auto_bits=TRUE
> # Java Additional Parameters
> #wrapper.java.additional.1=-server
> wrapper.java.additional.1=-XX:MaxPermSize=256m
> wrapper.java.additional.2=-Dorg.jboss.resolver.warning=true
> wrapper.java.additional.3=-Dsun.rmi.dgc.client.gcInterval=3600000
> wrapper.java.additional.4=-Dsun.rmi.dgc.server.gcInterval=3600000
> wrapper.java.additional.5=-Djboss.modules.system.pkgs=org.jboss.byteman
> wrapper.java.additional.6=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
> wrapper.java.additional.7=-Dlogging.configuration=file:%JBOSS_HOME%/standalone/configuration/logging.properties
> # Initial Java Heap Size (in MB)
> #wrapper.java.initmemory=128
> # Maximum Java Heap Size (in MB)
> #wrapper.java.maxmemory=512
> # Application parameters.  Add parameters as needed starting from 1
> wrapper.app.parameter.1=%JBOSS_HOME%/jboss-modules.jar
> wrapper.app.parameter.2=-mp
> wrapper.app.parameter.2=%JBOSS_HOME%\modules
> wrapper.app.parameter.3=-logmodule
> wrapper.app.parameter.3=org.jboss.logmanager
> wrapper.app.parameter.4=-jaxpmodule
> wrapper.app.parameter.4=javax.xml.jaxp-provider
> wrapper.app.parameter.4=org.jboss.as.standalone
> wrapper.app.parameter.9=-Djboss.home.dir=%JBOSS_HOME%
>
> #********************************************************************
> # Wrapper Logging Properties
> #********************************************************************
> # Enables Debug output from the Wrapper.
> wrapper.debug=TRUE
> # Format of output for the console.  (See docs for formats)
> wrapper.console.format=PM
> # Log Level for console output.  (See docs for log levels)
> wrapper.console.loglevel=INFO
> # Log file to use for wrapper output logging.
> wrapper.logfile=../standalone/log/wrapper.log
> # Format of output for the log file.  (See docs for formats)
> wrapper.logfile.format=LPTM
> # Log Level for log file output.  (See docs for log levels)
> wrapper.logfile.loglevel=INFO
> # Maximum size that the log file will be allowed to grow to before
> #  the log is rolled. Size is specified in bytes.  The default value
> #  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
> #  'm' (mb) suffix.  For example: 10m = 10 megabytes.
> wrapper.logfile.maxsize=0
> # Maximum number of rolled log files which will be allowed before old
> #  files are deleted.  The default value of 0 implies no limit.
> wrapper.logfile.maxfiles=0
> # Log Level for sys/event log output.  (See docs for log levels)
> wrapper.syslog.loglevel=NONE
> #********************************************************************
> # Wrapper General Properties
> #********************************************************************
> # Allow for the use of non-contiguous numbered properties
> #wrapper.ignore_sequence_gaps=TRUE
> # Title to use when running as a console
> #wra...@ap...@
> #********************************************************************
> # Wrapper JVM Checks
> #********************************************************************
> # Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
> #wrapper.check.deadlock=TRUE
> #wrapper.check.deadlock.interval=60
> #wrapper.check.deadlock.action=RESTART
> #wrapper.check.deadlock.output=FULL
> # Out Of Memory detection.
> # (Simple match)
> #wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
> # (Only match text in stack traces if -XX:+PrintClassHistogram is being
> used.)
> #wrapper.filter.trigger.1000=Exception in thread "*"
> java.lang.OutOfMemoryError
> #wrapper.filter.allow_wildcards.1000=TRUE
> #wrapper.filter.action.1000=RESTART
> #wrapper.filter.message.1000=The JVM has run out of memory.
> #********************************************************************
> # Wrapper Email Notifications. (Requires Professional Edition)
> #********************************************************************
> # Common Event Email settings.
> #wrapper.event.default.email.debug=TRUE
> #wrapper.event.default.email.smtp.host=<SMTP_Host>
> #wrapper.event.default.email.smtp.port=25
> #wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
> Event Notification
> #wrapper.event.default.email.sender=<Sender email>
> #wrapper.event.default.email.recipient=<Recipient email>
> # Configure the log attached to event emails.
> #wrapper.event.default.email.attach_log=TRUE
> #wrapper.event.default.email.maillog.lines=50
> #wrapper.event.default.email.maillog.format=LPTM
> #wrapper.event.default.email.maillog.loglevel=INFO
> # Enable specific event emails.
> #wrapper.event.wrapper_start.email=TRUE
> #wrapper.event.jvm_prelaunch.email=TRUE
> #wrapper.event.jvm_start.email=TRUE
> #wrapper.event.jvm_started.email=TRUE
> #wrapper.event.jvm_deadlock.email=TRUE
> #wrapper.event.jvm_stop.email=TRUE
> #wrapper.event.jvm_stopped.email=TRUE
> #wrapper.event.jvm_restart.email=TRUE
> #wrapper.event.jvm_failed_invocation.email=TRUE
> #wrapper.event.jvm_max_failed_invocations.email=TRUE
> #wrapper.event.jvm_kill.email=TRUE
> #wrapper.event.jvm_killed.email=TRUE
> #wrapper.event.jvm_unexpected_exit.email=TRUE
> #wrapper.event.wrapper_stop.email=TRUE
> # Specify custom mail content
> #wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease check
> on its status.\n
> Anyone know what's going on?  Do these errors have to do with my 32 bit
> version?  If we need to upgrade to pro we'll do so.  Thanks!
>
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

[Wrapper-user] JBoss AS7 problems

[qt4x11 <qt...@gm...>]

I'm trying to use jsw 3.3.5 32 bit with JBoss AS7 on a Windows 7 64 bit
machine.  I have a hunch the reason I'm having problems is due our 32 bit
version, but we have been able to use the 32 bit version of jsw with other
applications (ActiveMQ) successfully, so I thought I'd try the 32 bit
version first.  If it's advisable to upgrade to the pro version we will do
so.

I'm pasting my wrapper.log and wrapper.conf below.  Right now the service is
not able to start normally.  I tried troubleshooting the
 UnsatisfiedLinkError: no wrapper-windows-x86-32 in java.library.path error
by making sure jsw was finding my java.library.path by hard coding paths for
JAVA_HOME and JBOSS_HOME in my conf.  The second error seems unusual to me,
as  D:\jboss-as-7.0.0.Final/jboss-module.jar definitely exists on the file
system.

STATUS | wrapper  | 2011/09/07 08:01:33 | --> Wrapper Started as Console
DEBUG  | wrapper  | 2011/09/07 08:01:33 | Using tick timer.
DEBUG  | wrapperp | 2011/09/07 08:01:33 | server listening on port 32001.
STATUS | wrapper  | 2011/09/07 08:01:33 | Launching a JVM...
INFO   | wrapper  | 2011/09/07 08:01:33 | command: "C:\Program
Files\Java\jdk1.6.0_16\bin\java" -XX:MaxPermSize=256m
-Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-Djboss.modules.system.pkgs=org.jboss.byteman
-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
-Dlogging.configuration=file:D:\jboss-as-7.0.0.Final/standalone/configuration/logging.properties
-Djava.library.path="D:\jboss-as-7.0.0.Final/lib" -classpath
"D:\jboss-as-7.0.0.Final/lib/wrapper.jar;C:\Program
Files\Java\jdk1.6.0_16/lib/tools.jar;D:\jboss-as-7.0.0.Final/bin/run.jar;D:\jboss-as-7.0.0.Final/jboss-modules.jar"
-Dwrapper.key="ExYkelyCNrKjXXAf" -Dwrapper.port=32001
-Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
-Dwrapper.debug="TRUE" -Dwrapper.pid=3200 -Dwrapper.version="3.2.3"
-Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
-Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp
D:\jboss-as-7.0.0.Final/jboss-modules.jar D:\jboss-as-7.0.0.Final\modules
org.jboss.logmanager org.jboss.as.standalone
DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM started (PID=3336)
INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager class initialized
by thread: main  Using classloader: sun.misc.Launcher$AppClassLoader@11b86e7
INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper (Version 3.2.3)
http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2011/09/07 08:01:33 |   Copyright 1999-2006 Tanuki
Software, Inc.  All Rights Reserved.
INFO   | jvm 1    | 2011/09/07 08:01:33 |
INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: JVM #1
INFO   | jvm 1    | 2011/09/07 08:01:33 | Running a 32-bit JVM.
INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Registering
shutdown hook
INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: Using wrapper
INFO   | jvm 1    | 2011/09/07 08:01:33 | Load native library.  One or more
attempts may fail if platform specific libraries do not exist.
INFO   | jvm 1    | 2011/09/07 08:01:33 | Loading native library failed:
wrapper-windows-x86-32.dll  Cause: java.lang.UnsatisfiedLinkError: no
wrapper-windows-x86-32 in java.library.path
INFO   | jvm 1    | 2011/09/07 08:01:33 | Loaded native library: wrapper.dll
INFO   | jvm 1    | 2011/09/07 08:01:33 | Calling native initialization
method.
INFO   | jvm 1    | 2011/09/07 08:01:33 | Initializing WrapperManager native
library.
INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Executable: C:\Program
Files\Java\jdk1.6.0_16\bin\java.exe
INFO   | jvm 1    | 2011/09/07 08:01:33 | Windows version: 5.2.3790
INFO   | jvm 1    | 2011/09/07 08:01:33 | Java Version   : 1.6.0_16-b01 Java
HotSpot(TM) Client VM
INFO   | jvm 1    | 2011/09/07 08:01:33 | Java VM Vendor : Sun Microsystems
Inc.
INFO   | jvm 1    | 2011/09/07 08:01:33 |
INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp: Unable to locate
the class D:\jboss-as-7.0.0.Final/jboss-modules.jar:
java.lang.ClassNotFoundException: D:\jboss-as-7.0.0.Final/jboss-modules.jar
INFO   | jvm 1    | 2011/09/07 08:01:33 |
INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperSimpleApp Usage:
INFO   | jvm 1    | 2011/09/07 08:01:33 |   java
org.tanukisoftware.wrapper.WrapperSimpleApp {app_class} [app_arguments]
INFO   | jvm 1    | 2011/09/07 08:01:33 |
INFO   | jvm 1    | 2011/09/07 08:01:33 | Where:
INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_class:      The fully
qualified class name of the application to run.
INFO   | jvm 1    | 2011/09/07 08:01:33 |   app_arguments:  The arguments
that would normally be passed to the
INFO   | jvm 1    | 2011/09/07 08:01:33 |                   application.
INFO   | jvm 1    | 2011/09/07 08:01:33 | WrapperManager.stop(1) called by
thread: main
INFO   | jvm 1    | 2011/09/07 08:01:33 | Control event monitor thread
started.
INFO   | jvm 1    | 2011/09/07 08:01:33 | Startup runner thread started.
INFO   | jvm 1    | 2011/09/07 08:01:33 | Communications runner thread
started.
INFO   | jvm 1    | 2011/09/07 08:01:33 | Open socket to
wrapper...Wrapper-Connection
INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
port 31000
INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
port 31001
INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
port 31002
INFO   | jvm 1    | 2011/09/07 08:01:33 | Failed attempt to bind using local
port 31003
INFO   | jvm 1    | 2011/09/07 08:01:33 | Opened Socket from 31004 to 32001
INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet KEY :
ExYkelyCNrKjXXAf
INFO   | jvm 1    | 2011/09/07 08:01:33 | handleSocket(Socket[addr=/
127.0.0.1,port=32001,localport=31004])
INFO   | jvm 1    | 2011/09/07 08:01:33 | Send a packet STOP : 1
DEBUG  | wrapperp | 2011/09/07 08:01:33 | accepted a socket from 127.0.0.1
on port 31004
DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet KEY :
ExYkelyCNrKjXXAf
DEBUG  | wrapper  | 2011/09/07 08:01:33 | Got key from JVM: ExYkelyCNrKjXXAf
DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet LOW_LOG_LEVEL : 1
DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PING_TIMEOUT : 30
DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet PROPERTIES :
(Property Values)
DEBUG  | wrapperp | 2011/09/07 08:01:33 | read a packet STOP : 1
DEBUG  | wrapper  | 2011/09/07 08:01:33 | JVM requested a shutdown. (1)
DEBUG  | wrapper  | 2011/09/07 08:01:33 | wrapperStopProcess(1) called.
DEBUG  | wrapper  | 2011/09/07 08:01:33 | Sending stop signal to JVM
DEBUG  | wrapperp | 2011/09/07 08:01:33 | send a packet STOP : NULL
INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet LOW_LOG_LEVEL :
1
INFO   | jvm 1    | 2011/09/07 08:01:33 | Wrapper Manager: LowLogLevel from
Wrapper is 1
INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet PING_TIMEOUT :
30
INFO   | jvm 1    | 2011/09/07 08:01:33 | PingTimeout from Wrapper is 30000
INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet PROPERTIES :
(Property Values)
INFO   | jvm 1    | 2011/09/07 08:01:33 | Received a packet STOP :
INFO   | jvm 1    | 2011/09/07 08:01:34 | Thread, main, handling the
shutdown process.
INFO   | jvm 1    | 2011/09/07 08:01:34 | shutdownJVM(1) Thread:main
INFO   | jvm 1    | 2011/09/07 08:01:34 | Send a packet STOPPED : 1
DEBUG  | wrapperp | 2011/09/07 08:01:34 | read a packet STOPPED : 1
DEBUG  | wrapper  | 2011/09/07 08:01:34 | JVM signalled that it was stopped.
INFO   | jvm 1    | 2011/09/07 08:01:34 | Closing socket.
INFO   | jvm 1    | 2011/09/07 08:01:34 | Closed socket:
java.net.SocketException: socket closed
DEBUG  | wrapperp | 2011/09/07 08:01:34 | socket read no code (closed?).
DEBUG  | wrapperp | 2011/09/07 08:01:35 | server listening on port 32002.
INFO   | jvm 1    | 2011/09/07 08:01:35 | Server daemon shut down
INFO   | jvm 1    | 2011/09/07 08:01:35 | calling System.exit(1)
DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM process exited with a code of
1, however the wrapper exit code was already 1.
DEBUG  | wrapper  | 2011/09/07 08:01:35 | JVM exited normally.
STATUS | wrapper  | 2011/09/07 08:01:35 | <-- Wrapper Stopped

My wrapper.conf is below

#encoding=UTF-8
# Configuration files must begin with a line specifying the encoding
#  of the the file.

#********************************************************************
# Wrapper License Properties (Ignored by Community Edition)
#********************************************************************
# Professional and Standard Editions of the Wrapper require a valid
#  License Key to start.  Licenses can be purchased or a trial license
#  requested on the following pages:
# http://wrapper.tanukisoftware.com/purchase
# http://wrapper.tanukisoftware.com/trial

# Include file problems can be debugged by removing the first '#'
#  from the following line:
##include.debug

# The Wrapper will look for either of the following optional files for a
#  valid License Key.  License Key properties can optionally be included
#  directly in this configuration file.
#include ../conf/wrapper-license.conf
#include ../conf/wrapper-license-%WRAPPER_HOST_NAME%.conf

# The following property will output information about which License Key(s)
#  are being found, and can aid in resolving any licensing problems.
#wrapper.license.debug=TRUE

#********************************************************************
# Wrapper Localization
#********************************************************************
# Specify the locale which the Wrapper should use.  By default the system
#  locale is used.
#wrapper.lang=en_US # en_US or ja_JP

# Specify the location of the Wrapper's language resources.  If these are
#  missing, the Wrapper will default to the en_US locale.
wrapper.lang.folder=../lang

#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
#  Locate the java binary on the system PATH:
#wrapper.java.command=java
#  Specify a specific java binary:

set.JBOSS_HOME=D:\jboss-as-7.0.0.Final
set.JAVA_HOME=C:\Program Files\Java\jdk1.6.0_16
wrapper.java.command=%JAVA_HOME%/bin/java

# Tell the Wrapper to log the full generated Java command line.
wrapper.java.command.loglevel=INFO

# Java Main class.  This class must implement the WrapperListener interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=%JBOSS_HOME%/lib/wrapper.jar
wrapper.java.classpath.2=%JAVA_HOME%/lib/tools.jar
wrapper.java.classpath.3=%JBOSS_HOME%/bin/run.jar
wrapper.java.classpath.4=%JBOSS_HOME%/jboss-modules.jar

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

# Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit
mode.
wrapper.java.additional.auto_bits=TRUE

# Java Additional Parameters
#wrapper.java.additional.1=-server
wrapper.java.additional.1=-XX:MaxPermSize=256m
wrapper.java.additional.2=-Dorg.jboss.resolver.warning=true
wrapper.java.additional.3=-Dsun.rmi.dgc.client.gcInterval=3600000
wrapper.java.additional.4=-Dsun.rmi.dgc.server.gcInterval=3600000
wrapper.java.additional.5=-Djboss.modules.system.pkgs=org.jboss.byteman
wrapper.java.additional.6=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=false
wrapper.java.additional.7=-Dlogging.configuration=file:%JBOSS_HOME%/standalone/configuration/logging.properties

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

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

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=%JBOSS_HOME%/jboss-modules.jar
wrapper.app.parameter.2=-mp
wrapper.app.parameter.2=%JBOSS_HOME%\modules
wrapper.app.parameter.3=-logmodule
wrapper.app.parameter.3=org.jboss.logmanager
wrapper.app.parameter.4=-jaxpmodule
wrapper.app.parameter.4=javax.xml.jaxp-provider
wrapper.app.parameter.4=org.jboss.as.standalone
wrapper.app.parameter.9=-Djboss.home.dir=%JBOSS_HOME%


#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Enables Debug output from the Wrapper.
wrapper.debug=TRUE

# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=../standalone/log/wrapper.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0

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

#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
#wrapper.ignore_sequence_gaps=TRUE

# Title to use when running as a console
#wra...@ap...@

#********************************************************************
# Wrapper JVM Checks
#********************************************************************
# Detect DeadLocked Threads in the JVM. (Requires Standard Edition)
#wrapper.check.deadlock=TRUE
#wrapper.check.deadlock.interval=60
#wrapper.check.deadlock.action=RESTART
#wrapper.check.deadlock.output=FULL

# Out Of Memory detection.
# (Simple match)
#wrapper.filter.trigger.1000=java.lang.OutOfMemoryError
# (Only match text in stack traces if -XX:+PrintClassHistogram is being
used.)
#wrapper.filter.trigger.1000=Exception in thread "*"
java.lang.OutOfMemoryError
#wrapper.filter.allow_wildcards.1000=TRUE
#wrapper.filter.action.1000=RESTART
#wrapper.filter.message.1000=The JVM has run out of memory.

#********************************************************************
# Wrapper Email Notifications. (Requires Professional Edition)
#********************************************************************
# Common Event Email settings.
#wrapper.event.default.email.debug=TRUE
#wrapper.event.default.email.smtp.host=<SMTP_Host>
#wrapper.event.default.email.smtp.port=25
#wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%]
Event Notification
#wrapper.event.default.email.sender=<Sender email>
#wrapper.event.default.email.recipient=<Recipient email>

# Configure the log attached to event emails.
#wrapper.event.default.email.attach_log=TRUE
#wrapper.event.default.email.maillog.lines=50
#wrapper.event.default.email.maillog.format=LPTM
#wrapper.event.default.email.maillog.loglevel=INFO

# Enable specific event emails.
#wrapper.event.wrapper_start.email=TRUE
#wrapper.event.jvm_prelaunch.email=TRUE
#wrapper.event.jvm_start.email=TRUE
#wrapper.event.jvm_started.email=TRUE
#wrapper.event.jvm_deadlock.email=TRUE
#wrapper.event.jvm_stop.email=TRUE
#wrapper.event.jvm_stopped.email=TRUE
#wrapper.event.jvm_restart.email=TRUE
#wrapper.event.jvm_failed_invocation.email=TRUE
#wrapper.event.jvm_max_failed_invocations.email=TRUE
#wrapper.event.jvm_kill.email=TRUE
#wrapper.event.jvm_killed.email=TRUE
#wrapper.event.jvm_unexpected_exit.email=TRUE
#wrapper.event.wrapper_stop.email=TRUE

# Specify custom mail content
#wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease check
on its status.\n

Anyone know what's going on?  Do these errors have to do with my 32 bit
version?  If we need to upgrade to pro we'll do so.  Thanks!

Re: [Wrapper-user] Fwd: problems connecting to Xlib

[Klemens L. <kle...@gm...>]

H Roberto,

thx for your advice. I am not sure how to run this commands in the
"user session who is having the problem" because only "root" is used.
I start the Bamboo Remote Agent app as root using "./bamboo-agent.sh
start". Then both, the wrapper process and the started bamboo agent
java process are running as root. since root is able to access the
display, it should work. also, when i use  "./bamboo-agent.sh console"
so the wrapper is not in daemon mode, this two created processes run
as root too and here the connection to the display works.

br klemensl

2011/9/7 Roberto Espinoza <rob...@ta...>:
> Hello Klemens,
> It may be a problem with not having the right permissions to open the
> display ":10.0".
> You need to run the following command with the user who is the owner or have
> permisions for display ":10.0"
> Then run
> xauth list ":10.0"
> It should output something like
> yourhost/unix:10 MIT-MAGIC-COOKIE-1 <some-id-number-here>
> Once that is done, then in the user session who is having the problem to
> open the ":10.0" display, run this
> touch /your/home/folder/.Xauthority
> xauth add <copy paste the yourhost/unix:10 line in here>
> export DISPLAY=":10.0"
>
> After this, if you try to run firefox, it should be able to connect to the
> display and open firefox in that desktop.
>
> Let me know if this works for you.
>
>
> Cheers,
> Roberto
> On Tue, Sep 6, 2011 at 10:41 PM, Klemens Loschy <kle...@gm...> wrote:
>>
>> Hi,
>>
>> set > env.txt show "DISPLAY=:10.0". Is there anything else I look after?
>>
>> 2011/9/6 Leif Mortenson <lei...@ta...>:
>> > Klemens
>> > If you can't upgrade, then try adding the following line to your shell
>> > script just before the Wrapper is launched:
>> >
>> > set > env.txt
>> >
>> > This will store the current environment into a file.
>> >
>> > I am sure the problem is the DISPLAY variable though.
>> >
>> > Cheers,
>> > Leif
>> >
>> > On Tue, Sep 6, 2011 at 9:47 PM, Klemens Loschy <kle...@gm...>
>> > wrote:
>> >> Hi,
>> >>
>> >> unfortunately the update won't happen in near future. Things are bit
>> >> complicated when you are trying to change a peace of software... Seems
>> >> that 3.2.3 is installed.
>> >>
>> >> Sorry, br klemensl
>> >>
>> >> 2011/9/6 Leif Mortenson <lei...@ta...>:
>> >>> Klemens,
>> >>> Which version of the Wrapper are you using?  The
>> >>> wrapper.environment.dump property was added in version 3.5.0.  If you
>> >>> are using an older version, please upgrade to 3.5.11.  That won't fix
>> >>> your problem but it will let you investigate the issue.
>> >>>
>> >>> Cheers,
>> >>> Leif
>> >>>
>> >>> On Tue, Sep 6, 2011 at 8:20 PM, Klemens Loschy <kle...@gm...>
>> >>> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> thank you very much for the quick and helpful reply.
>> >>>>
>> >>>> The app is started on system startup. i have stopped the wrapper with
>> >>>> ./myapp stop and started the it again with ./myapp start -> same
>> >>>> problem. when i start the bamboo remote agent via ./myapp console,
>> >>>> everything works fine. prompting the env variable $DISPLAY in the
>> >>>> shell shows me ":10.0", that should work. so only when the wrapper is
>> >>>> started in daemonized mode, i have this display issues. unfortunately
>> >>>> i am not able to dump the environment by adding the
>> >>>> wrapper.environment.dump=TRUE attribute.
>> >>>>
>> >>>> thx, br klemensl
>> >>>>
>> >>>> 2011/9/6 Leif Mortenson <lei...@ta...>:
>> >>>>> Klemens,
>> >>>>> This sounds like a display problem.  Are you running the Wrapper as
>> >>>>> "./myapp console" or "./myapp start", or is it being stared on
>> >>>>> system
>> >>>>> startup?
>> >>>>>
>> >>>>> Most X Windows applications work by looking for a DISPLAY
>> >>>>> environment
>> >>>>> variable.  If that is not being found then the process will not be
>> >>>>> able to display its GUI.
>> >>>>>
>> >>>>> Try adding the following to your wrapper.conf so you get the current
>> >>>>> environment dumped to the log file.  This should help debug the
>> >>>>> problem.
>> >>>>>
>> >>>>> http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
>> >>>>> wrapper.environment.dump=TRUE
>> >>>>>
>> >>>>> Please let me know how this works for you.
>> >>>>>
>> >>>>> Cheers,
>> >>>>> Leif
>> >>>>>
>> >>>>> On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...>
>> >>>>> wrote:
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>> we are using the service wrapper to start a bamboo remote agent (VM
>> >>>>>> running a RHELS 5.6). if the agent is started using the the service
>> >>>>>> wrapper, our selenium tests do not work because the browser
>> >>>>>> (firefox)
>> >>>>>> can not be opened:
>> >>>>>> Xlib: connection to ":10.0" refused by server
>> >>>>>> Xlib: Client is not authorized to connect to Server
>> >>>>>> Error: cannot open display: :10
>> >>>>>>
>> >>>>>> When the remote agent is started without the service wrapper,
>> >>>>>> everything works as expected. Always root is used to start the
>> >>>>>> remote
>> >>>>>> agent.
>> >>>>>>
>> >>>>>> Can anyone support me by solving this issue?
>> >>>>>>
>> >>>>>> thank you in advance, br klemensl
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Special Offer -- Download ArcSight Logger for FREE!
>> > Finally, a world-class log management solution at an even better
>> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> > download Logger. Secure your free ArcSight Logger TODAY!
>> > http://p.sf.net/sfu/arcsisghtdev2dev
>> > _______________________________________________
>> > Wrapper-user mailing list
>> > Wra...@li...
>> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer -- Download ArcSight Logger for FREE!
>> Finally, a world-class log management solution at an even better
>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>> download Logger. Secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsisghtdev2dev
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
>
> --
> Roberto Espinoza
> Tanuki Software, Ltd.
> 6-16-7-1001 Nishi-Kasai, Edogawa-ku
> Tokyo 134-0088 Japan
> Tel/Fax: +81-3-3878-3211
> http://www.tanukisoftware.com
> rob...@ta...
>
> ------------------------------------------------------------------------------
> Using storage to extend the benefits of virtualization and iSCSI
> Virtualization increases hardware utilization and delivers a new level of
> agility. Learn what those decisions are and how to modernize your storage
> and backup environments for virtualization.
> http://www.accelacomm.com/jaw/sfnl/114/51434361/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Fwd: problems connecting to Xlib

[Roberto E. <rob...@ta...>]

Hello Klemens,

It may be a problem with not having the right permissions to open the
display ":10.0".

You need to run the following command with the user who is the owner or have
permisions for display ":10.0"

Then run

xauth list ":10.0"

It should output something like

yourhost/unix:10 MIT-MAGIC-COOKIE-1 <some-id-number-here>

Once that is done, then in the user session who is having the problem to
open the ":10.0" display, run this

touch /your/home/folder/.Xauthority
xauth add <copy paste the yourhost/unix:10 line in here>
export DISPLAY=":10.0"


After this, if you try to run firefox, it should be able to connect to the
display and open firefox in that desktop.


Let me know if this works for you.



Cheers,
Roberto

On Tue, Sep 6, 2011 at 10:41 PM, Klemens Loschy <kle...@gm...> wrote:

> Hi,
>
> set > env.txt show "DISPLAY=:10.0". Is there anything else I look after?
>
> 2011/9/6 Leif Mortenson <lei...@ta...>:
> > Klemens
> > If you can't upgrade, then try adding the following line to your shell
> > script just before the Wrapper is launched:
> >
> > set > env.txt
> >
> > This will store the current environment into a file.
> >
> > I am sure the problem is the DISPLAY variable though.
> >
> > Cheers,
> > Leif
> >
> > On Tue, Sep 6, 2011 at 9:47 PM, Klemens Loschy <kle...@gm...>
> wrote:
> >> Hi,
> >>
> >> unfortunately the update won't happen in near future. Things are bit
> >> complicated when you are trying to change a peace of software... Seems
> >> that 3.2.3 is installed.
> >>
> >> Sorry, br klemensl
> >>
> >> 2011/9/6 Leif Mortenson <lei...@ta...>:
> >>> Klemens,
> >>> Which version of the Wrapper are you using?  The
> >>> wrapper.environment.dump property was added in version 3.5.0.  If you
> >>> are using an older version, please upgrade to 3.5.11.  That won't fix
> >>> your problem but it will let you investigate the issue.
> >>>
> >>> Cheers,
> >>> Leif
> >>>
> >>> On Tue, Sep 6, 2011 at 8:20 PM, Klemens Loschy <kle...@gm...>
> wrote:
> >>>> Hi,
> >>>>
> >>>> thank you very much for the quick and helpful reply.
> >>>>
> >>>> The app is started on system startup. i have stopped the wrapper with
> >>>> ./myapp stop and started the it again with ./myapp start -> same
> >>>> problem. when i start the bamboo remote agent via ./myapp console,
> >>>> everything works fine. prompting the env variable $DISPLAY in the
> >>>> shell shows me ":10.0", that should work. so only when the wrapper is
> >>>> started in daemonized mode, i have this display issues. unfortunately
> >>>> i am not able to dump the environment by adding the
> >>>> wrapper.environment.dump=TRUE attribute.
> >>>>
> >>>> thx, br klemensl
> >>>>
> >>>> 2011/9/6 Leif Mortenson <lei...@ta...>:
> >>>>> Klemens,
> >>>>> This sounds like a display problem.  Are you running the Wrapper as
> >>>>> "./myapp console" or "./myapp start", or is it being stared on system
> >>>>> startup?
> >>>>>
> >>>>> Most X Windows applications work by looking for a DISPLAY environment
> >>>>> variable.  If that is not being found then the process will not be
> >>>>> able to display its GUI.
> >>>>>
> >>>>> Try adding the following to your wrapper.conf so you get the current
> >>>>> environment dumped to the log file.  This should help debug the
> >>>>> problem.
> >>>>>
> http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
> >>>>> wrapper.environment.dump=TRUE
> >>>>>
> >>>>> Please let me know how this works for you.
> >>>>>
> >>>>> Cheers,
> >>>>> Leif
> >>>>>
> >>>>> On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...>
> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> we are using the service wrapper to start a bamboo remote agent (VM
> >>>>>> running a RHELS 5.6). if the agent is started using the the service
> >>>>>> wrapper, our selenium tests do not work because the browser
> (firefox)
> >>>>>> can not be opened:
> >>>>>> Xlib: connection to ":10.0" refused by server
> >>>>>> Xlib: Client is not authorized to connect to Server
> >>>>>> Error: cannot open display: :10
> >>>>>>
> >>>>>> When the remote agent is started without the service wrapper,
> >>>>>> everything works as expected. Always root is used to start the
> remote
> >>>>>> agent.
> >>>>>>
> >>>>>> Can anyone support me by solving this issue?
> >>>>>>
> >>>>>> thank you in advance, br klemensl
> >
> >
> ------------------------------------------------------------------------------
> > Special Offer -- Download ArcSight Logger for FREE!
> > Finally, a world-class log management solution at an even better
> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > download Logger. Secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsisghtdev2dev
> > _______________________________________________
> > Wrapper-user mailing list
> > Wra...@li...
> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>



-- 
Roberto Espinoza
Tanuki Software, Ltd.
6-16-7-1001 Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel/Fax: +81-3-3878-3211
http://www.tanukisoftware.com
rob...@ta...

Re: [Wrapper-user] Fwd: problems connecting to Xlib

[Klemens L. <kle...@gm...>]

Hi,

set > env.txt show "DISPLAY=:10.0". Is there anything else I look after?

2011/9/6 Leif Mortenson <lei...@ta...>:
> Klemens
> If you can't upgrade, then try adding the following line to your shell
> script just before the Wrapper is launched:
>
> set > env.txt
>
> This will store the current environment into a file.
>
> I am sure the problem is the DISPLAY variable though.
>
> Cheers,
> Leif
>
> On Tue, Sep 6, 2011 at 9:47 PM, Klemens Loschy <kle...@gm...> wrote:
>> Hi,
>>
>> unfortunately the update won't happen in near future. Things are bit
>> complicated when you are trying to change a peace of software... Seems
>> that 3.2.3 is installed.
>>
>> Sorry, br klemensl
>>
>> 2011/9/6 Leif Mortenson <lei...@ta...>:
>>> Klemens,
>>> Which version of the Wrapper are you using?  The
>>> wrapper.environment.dump property was added in version 3.5.0.  If you
>>> are using an older version, please upgrade to 3.5.11.  That won't fix
>>> your problem but it will let you investigate the issue.
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Tue, Sep 6, 2011 at 8:20 PM, Klemens Loschy <kle...@gm...> wrote:
>>>> Hi,
>>>>
>>>> thank you very much for the quick and helpful reply.
>>>>
>>>> The app is started on system startup. i have stopped the wrapper with
>>>> ./myapp stop and started the it again with ./myapp start -> same
>>>> problem. when i start the bamboo remote agent via ./myapp console,
>>>> everything works fine. prompting the env variable $DISPLAY in the
>>>> shell shows me ":10.0", that should work. so only when the wrapper is
>>>> started in daemonized mode, i have this display issues. unfortunately
>>>> i am not able to dump the environment by adding the
>>>> wrapper.environment.dump=TRUE attribute.
>>>>
>>>> thx, br klemensl
>>>>
>>>> 2011/9/6 Leif Mortenson <lei...@ta...>:
>>>>> Klemens,
>>>>> This sounds like a display problem.  Are you running the Wrapper as
>>>>> "./myapp console" or "./myapp start", or is it being stared on system
>>>>> startup?
>>>>>
>>>>> Most X Windows applications work by looking for a DISPLAY environment
>>>>> variable.  If that is not being found then the process will not be
>>>>> able to display its GUI.
>>>>>
>>>>> Try adding the following to your wrapper.conf so you get the current
>>>>> environment dumped to the log file.  This should help debug the
>>>>> problem.
>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
>>>>> wrapper.environment.dump=TRUE
>>>>>
>>>>> Please let me know how this works for you.
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>>>
>>>>> On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> we are using the service wrapper to start a bamboo remote agent (VM
>>>>>> running a RHELS 5.6). if the agent is started using the the service
>>>>>> wrapper, our selenium tests do not work because the browser (firefox)
>>>>>> can not be opened:
>>>>>> Xlib: connection to ":10.0" refused by server
>>>>>> Xlib: Client is not authorized to connect to Server
>>>>>> Error: cannot open display: :10
>>>>>>
>>>>>> When the remote agent is started without the service wrapper,
>>>>>> everything works as expected. Always root is used to start the remote
>>>>>> agent.
>>>>>>
>>>>>> Can anyone support me by solving this issue?
>>>>>>
>>>>>> thank you in advance, br klemensl
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Fwd: problems connecting to Xlib

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

Klemens
If you can't upgrade, then try adding the following line to your shell
script just before the Wrapper is launched:

set > env.txt

This will store the current environment into a file.

I am sure the problem is the DISPLAY variable though.

Cheers,
Leif

On Tue, Sep 6, 2011 at 9:47 PM, Klemens Loschy <kle...@gm...> wrote:
> Hi,
>
> unfortunately the update won't happen in near future. Things are bit
> complicated when you are trying to change a peace of software... Seems
> that 3.2.3 is installed.
>
> Sorry, br klemensl
>
> 2011/9/6 Leif Mortenson <lei...@ta...>:
>> Klemens,
>> Which version of the Wrapper are you using?  The
>> wrapper.environment.dump property was added in version 3.5.0.  If you
>> are using an older version, please upgrade to 3.5.11.  That won't fix
>> your problem but it will let you investigate the issue.
>>
>> Cheers,
>> Leif
>>
>> On Tue, Sep 6, 2011 at 8:20 PM, Klemens Loschy <kle...@gm...> wrote:
>>> Hi,
>>>
>>> thank you very much for the quick and helpful reply.
>>>
>>> The app is started on system startup. i have stopped the wrapper with
>>> ./myapp stop and started the it again with ./myapp start -> same
>>> problem. when i start the bamboo remote agent via ./myapp console,
>>> everything works fine. prompting the env variable $DISPLAY in the
>>> shell shows me ":10.0", that should work. so only when the wrapper is
>>> started in daemonized mode, i have this display issues. unfortunately
>>> i am not able to dump the environment by adding the
>>> wrapper.environment.dump=TRUE attribute.
>>>
>>> thx, br klemensl
>>>
>>> 2011/9/6 Leif Mortenson <lei...@ta...>:
>>>> Klemens,
>>>> This sounds like a display problem.  Are you running the Wrapper as
>>>> "./myapp console" or "./myapp start", or is it being stared on system
>>>> startup?
>>>>
>>>> Most X Windows applications work by looking for a DISPLAY environment
>>>> variable.  If that is not being found then the process will not be
>>>> able to display its GUI.
>>>>
>>>> Try adding the following to your wrapper.conf so you get the current
>>>> environment dumped to the log file.  This should help debug the
>>>> problem.
>>>> http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
>>>> wrapper.environment.dump=TRUE
>>>>
>>>> Please let me know how this works for you.
>>>>
>>>> Cheers,
>>>> Leif
>>>>
>>>> On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...> wrote:
>>>>> Hi,
>>>>>
>>>>> we are using the service wrapper to start a bamboo remote agent (VM
>>>>> running a RHELS 5.6). if the agent is started using the the service
>>>>> wrapper, our selenium tests do not work because the browser (firefox)
>>>>> can not be opened:
>>>>> Xlib: connection to ":10.0" refused by server
>>>>> Xlib: Client is not authorized to connect to Server
>>>>> Error: cannot open display: :10
>>>>>
>>>>> When the remote agent is started without the service wrapper,
>>>>> everything works as expected. Always root is used to start the remote
>>>>> agent.
>>>>>
>>>>> Can anyone support me by solving this issue?
>>>>>
>>>>> thank you in advance, br klemensl

Re: [Wrapper-user] Fwd: problems connecting to Xlib

[Klemens L. <kle...@gm...>]

Hi,

unfortunately the update won't happen in near future. Things are bit
complicated when you are trying to change a peace of software... Seems
that 3.2.3 is installed.

Sorry, br klemensl

2011/9/6 Leif Mortenson <lei...@ta...>:
> Klemens,
> Which version of the Wrapper are you using?  The
> wrapper.environment.dump property was added in version 3.5.0.  If you
> are using an older version, please upgrade to 3.5.11.  That won't fix
> your problem but it will let you investigate the issue.
>
> Cheers,
> Leif
>
> On Tue, Sep 6, 2011 at 8:20 PM, Klemens Loschy <kle...@gm...> wrote:
>> Hi,
>>
>> thank you very much for the quick and helpful reply.
>>
>> The app is started on system startup. i have stopped the wrapper with
>> ./myapp stop and started the it again with ./myapp start -> same
>> problem. when i start the bamboo remote agent via ./myapp console,
>> everything works fine. prompting the env variable $DISPLAY in the
>> shell shows me ":10.0", that should work. so only when the wrapper is
>> started in daemonized mode, i have this display issues. unfortunately
>> i am not able to dump the environment by adding the
>> wrapper.environment.dump=TRUE attribute.
>>
>> thx, br klemensl
>>
>> 2011/9/6 Leif Mortenson <lei...@ta...>:
>>> Klemens,
>>> This sounds like a display problem.  Are you running the Wrapper as
>>> "./myapp console" or "./myapp start", or is it being stared on system
>>> startup?
>>>
>>> Most X Windows applications work by looking for a DISPLAY environment
>>> variable.  If that is not being found then the process will not be
>>> able to display its GUI.
>>>
>>> Try adding the following to your wrapper.conf so you get the current
>>> environment dumped to the log file.  This should help debug the
>>> problem.
>>> http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
>>> wrapper.environment.dump=TRUE
>>>
>>> Please let me know how this works for you.
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...> wrote:
>>>> Hi,
>>>>
>>>> we are using the service wrapper to start a bamboo remote agent (VM
>>>> running a RHELS 5.6). if the agent is started using the the service
>>>> wrapper, our selenium tests do not work because the browser (firefox)
>>>> can not be opened:
>>>> Xlib: connection to ":10.0" refused by server
>>>> Xlib: Client is not authorized to connect to Server
>>>> Error: cannot open display: :10
>>>>
>>>> When the remote agent is started without the service wrapper,
>>>> everything works as expected. Always root is used to start the remote
>>>> agent.
>>>>
>>>> Can anyone support me by solving this issue?
>>>>
>>>> thank you in advance, br klemensl
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Fwd: problems connecting to Xlib

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

Klemens,
Which version of the Wrapper are you using?  The
wrapper.environment.dump property was added in version 3.5.0.  If you
are using an older version, please upgrade to 3.5.11.  That won't fix
your problem but it will let you investigate the issue.

Cheers,
Leif

On Tue, Sep 6, 2011 at 8:20 PM, Klemens Loschy <kle...@gm...> wrote:
> Hi,
>
> thank you very much for the quick and helpful reply.
>
> The app is started on system startup. i have stopped the wrapper with
> ./myapp stop and started the it again with ./myapp start -> same
> problem. when i start the bamboo remote agent via ./myapp console,
> everything works fine. prompting the env variable $DISPLAY in the
> shell shows me ":10.0", that should work. so only when the wrapper is
> started in daemonized mode, i have this display issues. unfortunately
> i am not able to dump the environment by adding the
> wrapper.environment.dump=TRUE attribute.
>
> thx, br klemensl
>
> 2011/9/6 Leif Mortenson <lei...@ta...>:
>> Klemens,
>> This sounds like a display problem.  Are you running the Wrapper as
>> "./myapp console" or "./myapp start", or is it being stared on system
>> startup?
>>
>> Most X Windows applications work by looking for a DISPLAY environment
>> variable.  If that is not being found then the process will not be
>> able to display its GUI.
>>
>> Try adding the following to your wrapper.conf so you get the current
>> environment dumped to the log file.  This should help debug the
>> problem.
>> http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
>> wrapper.environment.dump=TRUE
>>
>> Please let me know how this works for you.
>>
>> Cheers,
>> Leif
>>
>> On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...> wrote:
>>> Hi,
>>>
>>> we are using the service wrapper to start a bamboo remote agent (VM
>>> running a RHELS 5.6). if the agent is started using the the service
>>> wrapper, our selenium tests do not work because the browser (firefox)
>>> can not be opened:
>>> Xlib: connection to ":10.0" refused by server
>>> Xlib: Client is not authorized to connect to Server
>>> Error: cannot open display: :10
>>>
>>> When the remote agent is started without the service wrapper,
>>> everything works as expected. Always root is used to start the remote
>>> agent.
>>>
>>> Can anyone support me by solving this issue?
>>>
>>> thank you in advance, br klemensl

Re: [Wrapper-user] Fwd: problems connecting to Xlib

[Klemens L. <kle...@gm...>]

Hi,

thank you very much for the quick and helpful reply.

The app is started on system startup. i have stopped the wrapper with
./myapp stop and started the it again with ./myapp start -> same
problem. when i start the bamboo remote agent via ./myapp console,
everything works fine. prompting the env variable $DISPLAY in the
shell shows me ":10.0", that should work. so only when the wrapper is
started in daemonized mode, i have this display issues. unfortunately
i am not able to dump the environment by adding the
wrapper.environment.dump=TRUE attribute.

thx, br klemensl

2011/9/6 Leif Mortenson <lei...@ta...>:
> Klemens,
> This sounds like a display problem.  Are you running the Wrapper as
> "./myapp console" or "./myapp start", or is it being stared on system
> startup?
>
> Most X Windows applications work by looking for a DISPLAY environment
> variable.  If that is not being found then the process will not be
> able to display its GUI.
>
> Try adding the following to your wrapper.conf so you get the current
> environment dumped to the log file.  This should help debug the
> problem.
> http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
> wrapper.environment.dump=TRUE
>
> Please let me know how this works for you.
>
> Cheers,
> Leif
>
> On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...> wrote:
>> Hi,
>>
>> we are using the service wrapper to start a bamboo remote agent (VM
>> running a RHELS 5.6). if the agent is started using the the service
>> wrapper, our selenium tests do not work because the browser (firefox)
>> can not be opened:
>> Xlib: connection to ":10.0" refused by server
>> Xlib: Client is not authorized to connect to Server
>> Error: cannot open display: :10
>>
>> When the remote agent is started without the service wrapper,
>> everything works as expected. Always root is used to start the remote
>> agent.
>>
>> Can anyone support me by solving this issue?
>>
>> thank you in advance, br klemensl
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Fwd: problems connecting to Xlib

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

Klemens,
This sounds like a display problem.  Are you running the Wrapper as
"./myapp console" or "./myapp start", or is it being stared on system
startup?

Most X Windows applications work by looking for a DISPLAY environment
variable.  If that is not being found then the process will not be
able to display its GUI.

Try adding the following to your wrapper.conf so you get the current
environment dumped to the log file.  This should help debug the
problem.
http://wrapper.tanukisoftware.com/doc/english/prop-environment-dump.html
wrapper.environment.dump=TRUE

Please let me know how this works for you.

Cheers,
Leif

On Tue, Sep 6, 2011 at 5:54 PM, Klemens Loschy <kle...@gm...> wrote:
> Hi,
>
> we are using the service wrapper to start a bamboo remote agent (VM
> running a RHELS 5.6). if the agent is started using the the service
> wrapper, our selenium tests do not work because the browser (firefox)
> can not be opened:
> Xlib: connection to ":10.0" refused by server
> Xlib: Client is not authorized to connect to Server
> Error: cannot open display: :10
>
> When the remote agent is started without the service wrapper,
> everything works as expected. Always root is used to start the remote
> agent.
>
> Can anyone support me by solving this issue?
>
> thank you in advance, br klemensl

[Wrapper-user] Fwd: problems connecting to Xlib

[Klemens L. <kle...@gm...>]

Hi,

we are using the service wrapper to start a bamboo remote agent (VM
running a RHELS 5.6). if the agent is started using the the service
wrapper, our selenium tests do not work because the browser (firefox)
can not be opened:
Xlib: connection to ":10.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: cannot open display: :10

When the remote agent is started without the service wrapper,
everything works as expected. Always root is used to start the remote
agent.

Can anyone support me by solving this issue?

thank you in advance, br klemensl

Re: [Wrapper-user] pid file becomes missing

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

Gary,
The Wrapper will produce the pid file on startup but then it doesn't
do anything with it other than to delete it when the Wrapper process
terminates.

It is possible for other processes to delete the file on UNIX.   This
is going to be a problem common to all applications.    To protect
against this, it is possible and advised to set up file permissions in
such a way that only processes with access can delete the file.   You
can control the permissions of the PID file and other files using
wrapper.pidfile.umask or more general wrapper.umask properties:
http://wrapper.tanukisoftware.com/doc/english/prop-umask.html

Unfortunately, I am not able to say what is deleting the file other
than to say that I am sure the Wrapper process is not what is doing
it.

Are you also using the 3.5.7 version of the shell script?  The
following issues were fixed in 3.5.7.  The second could be the cause
of your problem?

Fixed in 3.5.7:
* "Fix a problem in the shell script that was preventing the script
from starting the Wrapper correctly if a file or directory existed in
the current working directory which was one character in length. This
was only a problem when the delta-pack naming of the Wrapper was used.
This was easy to reproduce on AIX systems on system restart because a
"u" directory exists in the root directory by default. This had been a
problem since 3.4.0 when it was introduced as a fix to a Solaris
problem. The root cause was a missing set of quotes in the tr
command."
* "Fix a problem in the shell script that was preventing the script
from finding the running Wrapper process when it was started when the
working directory was in the same directory as the Wrapper binary, but
queried later from another location. It would also fail if it was
started from another location, but then queried from the location of
the Wrapper. This was introduced in 3.5.6 when the script stopped
changing the working directory in the script."

Cheers,
Leif


On Tue, Aug 30, 2011 at 8:50 AM, Chaur (Gary) Wu <gw...@vm...> wrote:
> Hi Christian,
>
> Thank you for the reply. The version I'm using is profession edition 64-bit 3.5.7. The OS I'm using is SUSE Linux version 2.6.32.43-0.4-default.
>
> No, I'm referring to wrapper.pidfile, not wrapper.java.pidfile. The wrapper.pid file sometimes becomes missing when the wrapper process is still running. I don't know the steps to take to reproduce the issue. I only saw that happen a few times on some developers' and testers' machines.
>
> Any ideas/suggestions?
>
> Thanks,
> Gary
>
>
>
> -----Original Message-----
> From: Christian Mueller [mailto:chr...@ta...]
> Sent: Sunday, August 28, 2011 6:32 PM
> To: wra...@li...
> Subject: Re: [Wrapper-user] pid file becomes missing
>
> Gary,
>
> what version of the Wrapper are you using? Also what platform are you running?
>
> I think you are referring to the wrapper.java.pidfile, so this file
> gets deleted by the Wrapper everytime the Wrapper detects that the
> Java Process has been terminated. Once the application has been
> restarted, the Wrapper will create a new file for the new pid (same
> filename though).
> At what times have you seen the PID file being missing?
>
>
> Thank you,
> Christian
>
> On Sun, Aug 28, 2011 at 4:56 PM, Chaur (Gary) Wu <gw...@vm...> wrote:
>> Hi,
>>
>>
>>
>> I use Tanuki wrapper to wrap a Tomcat app. I notice that sometimes the PID
>> file will become missing while the wrapper process is still running. Since I
>> have scripts that read the process id from the PID file, the scripts don't
>> work properly because of the missing PID file. I tried to find out what
>> would cause the PID file to become missing but couldn't find any clue. Any
>> idea/suggestion?
>>
>>
>>
>> Thanks,
>>
>> Chaur

Re: [Wrapper-user] pid file becomes missing

[Chaur (G. W. <gw...@vm...>]

Hi Christian,

Thank you for the reply. The version I'm using is profession edition 64-bit 3.5.7. The OS I'm using is SUSE Linux version 2.6.32.43-0.4-default. 

No, I'm referring to wrapper.pidfile, not wrapper.java.pidfile. The wrapper.pid file sometimes becomes missing when the wrapper process is still running. I don't know the steps to take to reproduce the issue. I only saw that happen a few times on some developers' and testers' machines. 

Any ideas/suggestions?

Thanks,
Gary



-----Original Message-----
From: Christian Mueller [mailto:chr...@ta...] 
Sent: Sunday, August 28, 2011 6:32 PM
To: wra...@li...
Subject: Re: [Wrapper-user] pid file becomes missing

Gary,

what version of the Wrapper are you using? Also what platform are you running?

I think you are referring to the wrapper.java.pidfile, so this file
gets deleted by the Wrapper everytime the Wrapper detects that the
Java Process has been terminated. Once the application has been
restarted, the Wrapper will create a new file for the new pid (same
filename though).
At what times have you seen the PID file being missing?


Thank you,
Christian

On Sun, Aug 28, 2011 at 4:56 PM, Chaur (Gary) Wu <gw...@vm...> wrote:
> Hi,
>
>
>
> I use Tanuki wrapper to wrap a Tomcat app. I notice that sometimes the PID
> file will become missing while the wrapper process is still running. Since I
> have scripts that read the process id from the PID file, the scripts don't
> work properly because of the missing PID file. I tried to find out what
> would cause the PID file to become missing but couldn't find any clue. Any
> idea/suggestion?
>
>
>
> Thanks,
>
> Chaur
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Additional parameters to Java Service Wrapper

[Francesco S. <f.s...@ci...>]

Hi Lief.
I try to explain my situation.

I have an amount of j2ee instance configured with JSW: java parameters 
and application parameters are defined into JSW (one wrapper.conf file).

Some parameters, however, are specifics for instance and it's possible 
that not all instances needs for additional parameters.

For example, suppose that in production environment just a single 
instance has an of out of memory problem (is just an example). In this 
situation I would like to "debug" my instance, so I need to specify a 
debug port just for this instance.

In this example I need to define a property just for an instance and 
just for a _limited time_.

If I am able to add multiple parameters with one property, I can specify 
this property always and use it when I need it (look at the example 
explained in first email).

In this case, additional parameters are defined into an external file (a 
configuration file for instance) and not into wrapper.conf file. The 
latter one contains just the property 
"wrapper.java.additional.XX=%ADDITIONAL%".

Your suggestion to use an "include" file is a good solution (thanks 
again) but for me is too hard to manage than a single parameter. For 
example, I don't know how many parameters I might need.

Moreover, in a (semi) automated infrastructure is difficult to define 
how many discontinious "X" values to use for any instance.

What do you think about?
I hope this scenario is more or less clear.

Thanks a lot.
Francesco.




Il 26/08/2011 16:59, Leif Mortenson ha scritto:
> Francesco,
> The way the properties are broken up is currently by design to give
> you the most control over them.  We don't have any plans to change
> that at the moment, but we are always open to ways to improve the
> Wrapper.  If you could describe what you are trying to do, we can
> consider a solution or suggest a way of doing it using the current
> functionality.
>
> Cheers,
> Leif
>

Re: [Wrapper-user] Shutdown gracefully

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

Jimmy,
Great.  That is what I was going to suggest.   I would suggest not
making that any longer than you really need as that is minimum time
that the Wrapper will wait before it gives up and kills the JVM if it
fails to shutdown for any reason.   If it is too long it can cause
delays getting your application back up and running after a long
restart.

Where possible, it is a good idea to try to modify your application to
make its shutdown more responsive.  That is not always possible
however.

Anyway, glad you got it working.  Please let me know if we can be of
further assistance.

Cheers,
Leif

On Sat, Aug 27, 2011 at 11:55 PM, Jimmy Chang(Gmail)
<cha...@gm...> wrote:
> Hi all,
>
> I added the parameter and solved the problem.
>
> wrapper.jvm_exit.timeout=300
>
> Thanks.
>
>
>> Here's the complete logs.
>>
>> DEBUG | wrapperp | 2011/08/27 21:46:05 | read a packet PING : ping
>> DEBUG | wrapper | 2011/08/27 21:46:07 | Signal trapped. Details:
>> DEBUG | wrapper | 2011/08/27 21:46:07 | signal number=2 (SIGINT),
>> source="kill, sigsend or raise"
>> DEBUG | wrapper | 2011/08/27 21:46:07 | signal generated by PID: 7206
>> (Session PID: 6824), UID: 0 (root)
>> STATUS | wrapper | 2011/08/27 21:46:07 | INT trapped. Shutting down.
>> DEBUG | wrapper | 2011/08/27 21:46:07 | wrapperStopProcess(0, TRUE)
>> called.
>> DEBUG | wrapper | 2011/08/27 21:46:07 | Sending stop signal to JVM
>> DEBUG | wrapperp | 2011/08/27 21:46:07 | send a packet STOP : NULL
>> DEBUG | wrapperp | 2011/08/27 21:46:07 | read a packet STOPPED : 0
>> DEBUG | wrapper | 2011/08/27 21:46:07 | JVM signaled that it was stopped.
>> DEBUG | wrapperp | 2011/08/27 21:46:07 | socket read no code (closed?).
>> DEBUG | wrapperp | 2011/08/27 21:46:07 | closing backend socket.
>> ERROR | wrapper | 2011/08/27 21:46:26 | Shutdown failed: Timed out
>> waiting for the JVM to terminate.
>> ERROR | wrapper | 2011/08/27 21:46:26 | JVM did not exit on request,
>> terminated
>> DEBUG | wrapper | 2011/08/27 21:46:26 | Signal trapped. Details:
>> DEBUG | wrapper | 2011/08/27 21:46:26 | signal number=17 (SIGCHLD),
>> source="unknown"
>> DEBUG | wrapper | 2011/08/27 21:46:26 | Received SIGCHLD, checking JVM
>> process status.
>> STATUS | wrapper | 2011/08/27 21:46:26 | <-- Wrapper Stopped