Re: [Wrapper-user] Wrapper stopped after startup

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

Elias,
1) So you are specifying the Java to run in your wrapper.conf file so
we are sure that it is always using the correct JVM?
Just to rule out a particular problem in my mind, could you please set
the wrapper.java.command.loglevel=INFO property in your wrapper.conf
file and then post the generated command line when you run as a
service?  I want to make 100% sure that you are running the correct
JVM.

In your original post, your command line was this:
---
"C:\WINNT\system32\java.exe" -Djava.library.path="../lib" -classpath
"../bin/AXConnectorServer.jar;../lib/wrappertest.jar;../lib/wrapper.jar"
-Dwrapper.key="fREO9IxlyMDSknzk" -Dwrapper.port=32000
-Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
-Dwrapper.debug="TRUE" -Dwrapper.pid=4020 -Dwrapper.version="3.3.3"
-Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE"
-Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1
com.gvs.AXConnectorServer.AXConnectorServiceWin32
---
Notice that the java being run is not the same as when you run in a
console.  If this is still the case then this is most likely the cause
of your problems.

If your java command is specified as follows then it will searched for
on the PATH.  This is not very reliable.
wrapper.java.command=java
The PATH when run as a service will most likely be quite different.

I strongly suggest using one of the following:
wrapper.java.command=%JAVA_HOME%/bin/java

This second option is most likely even better because it appears that
your application includes its own JRE.  The path is relative to the
location of the wrapper.exe:
wrapper.java.command=../jre/bin/java

2) Please post your wrapper.conf file as a an attachment.

Cheers,
Leif

On Tue, Mar 24, 2009 at 1:50 AM, ejml <eli...@gm...> wrote:
>
> Sorry Leif,
>
> False Alarm, it still fails when it's configured like service.
>
> Greetings!!.
>
> ejml wrote:
>>
>> Hello Leif,
>>
>> My answers:
>>
>> 1) I have run the service in console mode with the command: wrapper.exe -c
>> ../conf/wrapper.conf and it works fine.
>>
>> 2) The command that I use to run the application when it works is:
>>
>> "C:\Archivos de programa\Java\jre1.5.0_12\bin\java"
>> -Djava.library.path="../lib" -classpath
>> "../bin/AXConnectorServer.jar;../lib/wrappertest.jar;../lib/wrapper.jar;C:/Archivos
>> de programa/jetty-6.1.3/lib/servlet-api-2.5-6.1.3.jar;C:/Archivos de
>> programa/jacob-1.14/jacob.jar;C:/Archivos de
>> programa/jetty-6.1.3/lib/jetty-6.1.3.jar;C:/Archivos de
>> programa/jetty-6.1.3/lib/jetty-util-6.1.3.jar;C:/Archivos de
>> programa/spring-framework-2.5.1/dist/spring.jar;C:/Archivos de
>> programa/spring-framework-2.5.1/dist/modules/spring-context.jar;C:/Archivos
>> de programa/spring-framework-2.5.1/dist/spring-test.jar;C:/Archivos de
>> programa/spring-framework-2.5.1/lib/jakarta-commons/commons-logging.jar"
>> com.gvs.AXConnectorServer.AXConnectorServiceWin32
>>
>> This is the same effect that I execute: wrapper.exe -c
>> ../conf/wrapper.conf
>>
>> 3) I don't find win32com.dll, I have searched in sun and RXTX and the new
>> versions not contain win32com.dll.
>>
>> Thanks and greetings!!.
>>
>> Leif Mortenson-2 wrote:
>>>
>>> Elias,
>>> Can you answer a few questions?
>>>
>>> 1) You have said that it fails when run as a service, but that it
>>> works from the command line.   Have you tried running under the
>>> Wrapper in console mode?  Ie by running as follows: wrapper.exe -c
>>> ..¥conf¥wrapper.conf
>>> What happens?
>>>
>>> 2) Please post the java command line you are using when it works, and
>>> the one generated by the Wrapper.  You can get the command line
>>> generated by the Wrapper by running in debug mode or by setting
>>> wrapper.java.command.loglevel=INFO
>>>
>>> 2) Have you seen the FAQ entry on this subject?
>>> http://wrapper.tanukisoftware.org/doc/english/faq.html#4
>>> The win32com.dll needs to be on your java library path.  By default,
>>> Java searches the PATH, but when running under the Wrapper, this is
>>> disabled because a library path is specified.  It is necessary to add
>>> the location of win32com.dll to your library path in the wrapper.conf
>>> file.
>>>
>>> Cheers,
>>> Leif
>>>
>>> 2009/3/20 Elías Manchón López <eli...@gm...>:
>>>> Hi Leif,
>>>>
>>>> The problem was the creation of instance of the class wrap by
>>>> WrapperListener. Now I haven't problem with the start of Service. But
>>>> it's
>>>> not work yet. I think that the problem is very difficult of resolve.
>>>> Although my level of English not is very good, I will try to explain the
>>>> better possible for if you can help me.
>>>>
>>>> My application is made with Spring Framework. This application use Jetty
>>>> embedded to publish it through 8080 port and use the remote feature of
>>>> Spring to the web server can do request to it. This application is
>>>> communicated with my ERP throught COM+ and translate the request of web
>>>> server to my ERP using JACOB
>>>> (http://sourceforge.net/projects/jacob-project/).
>>>>
>>>> When I use Java Service Wrapper, I can see that I have problems with the
>>>> Initialization of COM Object, and I get NullPointer to object
>>>> instantiated
>>>> with JACOB. I thought that problem was by permission on the COM of
>>>> Microsoft, but I checked this issue and there isn't problems. As well
>>>> as, If
>>>> I run my application throught command line, with the same command that
>>>> Java
>>>> Service Wrapper and using the same jar packet, the curious is that it
>>>> works
>>>> fine.
>>>>
>>>> I don't know to think, I don't know if it is problem of COM+ or If it is
>>>> problem of Java Service Wrapper?. Could you give me some indication?.
>>>>
>>>> Thanks again!!.
>>>> 2009/3/18 Leif Mortenson <lei...@ta...>
>>>>>
>>>>> Elias,
>>>>> What does the content of your WrapperListener.start method look like?
>>>>>
>>>>> If you create a new thread, it will be non-daemon unless you
>>>>> specifically call the thread.setDaemon(true) method.  If you are using
>>>>> existing class to start your application then it will be more
>>>>> difficult to check.   One solution is to add a wait for 1 second at
>>>>> the end of your start method then call
>>>>> WrapperManager.requestThreadDump().  That will let you see all of your
>>>>> threads as well as see easily which have their daemon flag set.
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>
>>> (snip)