Menu
▾
▴
Re: [Wrapper-user] Wrapper stopped after startup
|
From: Leif M. <lei...@ta...> - 2009-03-24 16:30:11
|
Elias, When running as a service, by default, the Wrapper will run as the SYSTEM user. That is one thing that is different. I agree that it is likely a permission problem now that we have verified that the same JVM is being run. One other possibility is the PATH. Try echoing your PATH in a command prompt, then go to your wrapper.conf and add a setting like the following: set.PATH=<your full path> Then run your service to see what happens. Another thing to try is configuring your service to run as the same user you are when you are logged in. Remember that you need to uninstall and then reinstall the service after making this change. See this page on how to set the account to run as: http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-account.html The account will also need to be set up to be able to run services. This is described on the account page as well. I wish I understood the problem a bit more, but I have never used the COM API myself in the past. I spent some time Googling on this tonight but have not found any other clues as to what the problem might be. Could you post the full stack trace you are seeing? That might help. Cheers, Leif On Wed, Mar 25, 2009 at 12:38 AM, ejml <eli...@gm...> wrote: > > wrapper.exe -c ../conf/wrapper.conf works fine. > wrapper.exe -i ../conf/wrapper.conf: > 1) It installs the service > 2) It runs without problem > 3) When I do the first request my COM Api return null. Here is the problem. > > I think that it's problem with the permission. > > > ejml wrote: >> >> The problem is that the service not is capable to access at COM and the >> same programa execution throught console is capable. When It runs in >> console mode, I suppose that it uses the user credentials logged. When it >> runs in service mode what is the credentials that it assumes... the >> service account?. >> >> Thanks again! >> >> >> ejml wrote: >>> >>> Leif, >>> I have the same wrapper.java.command that there is configured in >>> wrapper.conf, but it doesn't work like service yet. The only thing is... >>> Could some problem with the service installer?. I used the example bat >>> files. >>> >>> Leif Mortenson-2 wrote: >>>> >>>> Elias, >>>> I do not see any problems with your wrapper.conf file. Did the change >>>> to your wrapper.java.command value solve the problem for you? >>>> >>>> Cheers, >>>> Leif >>>> >>>> On Tue, Mar 24, 2009 at 10:08 PM, ejml <eli...@gm...> wrote: >>>>> >>>>> Hi Leif, >>>>> >>>>> I setted the wrapper.java.command to avoid problems with my path. I >>>>> send you >>>>> my wrapper.conf. >>>>> >>>>> Greetings!! >>>>> >>>>> http://www.nabble.com/file/p22680034/wrapper.conf wrapper.conf >>>>> Leif Mortenson-3 wrote: >>>>>> >>>>>> 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) |
