|
From: ejml <eli...@gm...> - 2009-03-24 15:39:01
|
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) >>> >>> ------------------------------------------------------------------------------ >>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>> development >>> software that enables intelligent coding and step-through debugging. >>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>> _______________________________________________ >>> Wrapper-user mailing list >>> Wra...@li... >>> https://lists.sourceforge.net/lists/listinfo/wrapper-user >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Wrapper-stopped-after-startup-tp22554782p22683145.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |