Menu
▾
▴
wrapper-user — User issues for Wrapper. (Support questions, etc.)
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(16) |
Dec
(29) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(38) |
Feb
(51) |
Mar
(51) |
Apr
(115) |
May
(82) |
Jun
(30) |
Jul
(50) |
Aug
(68) |
Sep
(57) |
Oct
(160) |
Nov
(80) |
Dec
(78) |
| 2004 |
Jan
(71) |
Feb
(75) |
Mar
(108) |
Apr
(87) |
May
(79) |
Jun
(70) |
Jul
(69) |
Aug
(39) |
Sep
(52) |
Oct
(47) |
Nov
(50) |
Dec
(32) |
| 2005 |
Jan
(22) |
Feb
(122) |
Mar
(46) |
Apr
(76) |
May
(31) |
Jun
(51) |
Jul
(61) |
Aug
(70) |
Sep
(37) |
Oct
(46) |
Nov
(57) |
Dec
(83) |
| 2006 |
Jan
(55) |
Feb
(81) |
Mar
(51) |
Apr
(67) |
May
(77) |
Jun
(43) |
Jul
(106) |
Aug
(64) |
Sep
(47) |
Oct
(64) |
Nov
(60) |
Dec
(12) |
| 2007 |
Jan
(50) |
Feb
(93) |
Mar
(49) |
Apr
(56) |
May
(40) |
Jun
(63) |
Jul
(40) |
Aug
(47) |
Sep
(54) |
Oct
(37) |
Nov
(54) |
Dec
(37) |
| 2008 |
Jan
(35) |
Feb
(39) |
Mar
(26) |
Apr
(14) |
May
(23) |
Jun
(51) |
Jul
(43) |
Aug
(26) |
Sep
(29) |
Oct
(31) |
Nov
(24) |
Dec
(16) |
| 2009 |
Jan
(21) |
Feb
(30) |
Mar
(74) |
Apr
(26) |
May
(26) |
Jun
(43) |
Jul
(23) |
Aug
(23) |
Sep
(15) |
Oct
(27) |
Nov
(37) |
Dec
(10) |
| 2010 |
Jan
(16) |
Feb
(28) |
Mar
(16) |
Apr
(45) |
May
(8) |
Jun
(68) |
Jul
(45) |
Aug
(44) |
Sep
(51) |
Oct
(7) |
Nov
(20) |
Dec
(21) |
| 2011 |
Jan
(14) |
Feb
(17) |
Mar
(7) |
Apr
(7) |
May
(48) |
Jun
(23) |
Jul
(5) |
Aug
(33) |
Sep
(22) |
Oct
(14) |
Nov
(14) |
Dec
(5) |
| 2012 |
Jan
|
Feb
(10) |
Mar
(12) |
Apr
(51) |
May
(10) |
Jun
(8) |
Jul
(14) |
Aug
(22) |
Sep
(9) |
Oct
(24) |
Nov
(14) |
Dec
(13) |
| 2013 |
Jan
(12) |
Feb
(4) |
Mar
(14) |
Apr
(19) |
May
(2) |
Jun
(5) |
Jul
(13) |
Aug
(10) |
Sep
(4) |
Oct
(11) |
Nov
(13) |
Dec
(2) |
| 2014 |
Jan
(3) |
Feb
(14) |
Mar
(5) |
Apr
(10) |
May
(10) |
Jun
(11) |
Jul
(10) |
Aug
(3) |
Sep
(13) |
Oct
(22) |
Nov
(14) |
Dec
(32) |
| 2015 |
Jan
(8) |
Feb
(2) |
Mar
(17) |
Apr
(1) |
May
(24) |
Jun
|
Jul
(4) |
Aug
|
Sep
(9) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2016 |
Jan
(8) |
Feb
(6) |
Mar
(6) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(7) |
Aug
(6) |
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
| 2017 |
Jan
(9) |
Feb
(8) |
Mar
(6) |
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
(10) |
Sep
(8) |
Oct
|
Nov
(6) |
Dec
|
| 2018 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
(2) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(9) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2019 |
Jan
(9) |
Feb
|
Mar
|
Apr
(10) |
May
(3) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2021 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas S. <Tho...@ra...> - 2009-04-03 13:20:35
|
Hi; Is there a way to increase the allocated time to stop the JBoss service before the service control manager kills the process? Thanks: Tom Thomas Silveria Senior Software Engineer, Athena MDA Raytheon Integrated Defense Systems 1.401.842.5191 office 444.5191 tie line 1.401.842.5265 fax Tho...@Ra... 1847 West Main RD Constitution, C11, 3-1-C031 Portsmouth, RI 02871-1087, USA |
|
From: Leif M. <lei...@ta...> - 2009-04-02 08:16:21
|
Holger, I have implemented a new property, wrapper.disable_restarts.automatic which will do what you want. This will be included in the upcoming 3.3.4 release which we are planing on releasing over the next week or two. Cheers, Leif On Mon, Mar 30, 2009 at 7:14 PM, Isenberg, Holger <ise...@e-...> wrote: >> Holger, >> Does this property work for you? >> http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html > > Almost. Automatic restarts are disabled sucessfully, but now our java based service cannot restart itself with configuration entry wrapper.on_exit.100=RESTART: > > on_exit trigger matched. Restarting the JVM. (Exit code: 100) > JVM Restarts disabled. Shutting down. > > A restart via wrapper.commandfile does not work either. > > As the wrapper itselfs can differentiate between normal exit codes, VM crashes and cpu/timer timeouts another property like "wrapper.disable_automatic_restarts" would be better. |
|
From: Isenberg, H. <ise...@e-...> - 2009-03-30 10:14:47
|
> Holger, > Does this property work for you? > http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html Almost. Automatic restarts are disabled sucessfully, but now our java based service cannot restart itself with configuration entry wrapper.on_exit.100=RESTART: on_exit trigger matched. Restarting the JVM. (Exit code: 100) JVM Restarts disabled. Shutting down. A restart via wrapper.commandfile does not work either. As the wrapper itselfs can differentiate between normal exit codes, VM crashes and cpu/timer timeouts another property like "wrapper.disable_automatic_restarts" would be better. |
|
From: Leif M. <le...@ta...> - 2009-03-30 08:20:19
|
Michael, Done. Let me know if there is anything we can help with in the future. Sincerely, Leif Mortenson Tanuki Software, Ltd. 2009/3/27 Michael McFarland <Mic...@ja...>: > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > -- Leif Mortenson Representative Director Tanuki Software, Ltd. 6-16-7-1001 Nishi-Kasai, Edogawa-ku Tokyo 134-0088 Japan Tel/Fax: +81-3-3878-0415 http://www.tanukisoftware.com lei...@ta... |
|
From: Mork0075 <mor...@go...> - 2009-03-27 18:33:59
|
Hi, i'am trying to setup a continuous integration server with Java Service Wrapper, as the part for starting and stopping my sample application. Ther's no actual need to install the nightly version of the application as a service, its ok to run it in console mode, which is also supported by the Java Service Wrapper. My problem is, that i after doing my automated tests against the application, i cant stop the application by the Service Wrapper. The wrapper.exe -p command only works if the application is installed as a service (which is not the case). A human user would type Ctrl+C in the console window, how can a script to this? Thanks a lot Mork |
|
From: Leif M. <le...@ta...> - 2009-03-27 10:21:40
|
Zeynep, It is never a waste of time. I am glad you got things working. Let me know if there is anything else we can help out with. Cheers, Leif On Fri, Mar 27, 2009 at 5:44 PM, Gunal, Zeynep <zey...@tr...> wrote: > Thank you for your reply. Our test team applied your sugegstions, and > they reported no improvements. Only then when I looked into the log > files I was given to send you I realized that I lied in my first e-mail, > because although I thought the java heap size was increased, it was > actually not done. > The service is running as expected and there is no performance issue. > I apologize for wasting your time. > Regards, > Zeynep > > > -----Original Message----- > From: Leif Mortenson [mailto:lei...@ta...] > Sent: 24 March 2009 18:30 > To: wra...@li... > Subject: Re: [Wrapper-user] Wrapper service performance question > > Gunal, > Could you try setting the wrapper.java.command.loglevel=INFO property > so the generated java command will be output to your logs. Then run > the Wrapper in console mode and as a service to make sure that the > correct JVM is being run. > > A common problem is to not add the correct JVM onto the PATH of the > system user. This results in the default java that ships with Windows > being run. > > The Wrapper itself does not do anything which would affect the > performance of the Java process. One way to prove this is to copy the > above java command line into a batch file, remove the -Dwrapper.key > system property, then run the batch file manually outside of the > Wrapper. If you still see the slowdowns there then the problem can > be narrowed down to the parameters being passed to the JVM. > > Attach your wrapper.conf as well as the generated java commands above > and I might be able to help out more. > > Cheers, > Leif > > 2009/3/25 Gunal, Zeynep <zey...@tr...>: >> Hi, >> >> >> >> We have noticed that it is taking longer for the service to process > the same >> input than when the application is run from the command prompt. >> >> >> >> For instance, processing a 39MB file from the command line took 4 >> milliseconds but it took 12 minutes to process the same file with the >> service. >> >> >> >> Also, the service seems to slowdown as more data is processed, for > example >> the number of records processed go from 204 in the first minute to > 12/min >> after 57 minutes! >> >> >> >> We increased the java heap size, we disabled the console logging > level, this >> behaviour did not change. >> >> >> >> Did anybody have a similar experience? Any suggestions? We are feeling >> hopeless! >> >> >> >> Thanks. |
|
From: Michael M. <Mic...@ja...> - 2009-03-27 10:07:33
|
|
From: Gunal, Z. <zey...@tr...> - 2009-03-27 08:44:13
|
Thank you for your reply. Our test team applied your sugegstions, and they reported no improvements. Only then when I looked into the log files I was given to send you I realized that I lied in my first e-mail, because although I thought the java heap size was increased, it was actually not done. The service is running as expected and there is no performance issue. I apologize for wasting your time. Regards, Zeynep -----Original Message----- From: Leif Mortenson [mailto:lei...@ta...] Sent: 24 March 2009 18:30 To: wra...@li... Subject: Re: [Wrapper-user] Wrapper service performance question Gunal, Could you try setting the wrapper.java.command.loglevel=INFO property so the generated java command will be output to your logs. Then run the Wrapper in console mode and as a service to make sure that the correct JVM is being run. A common problem is to not add the correct JVM onto the PATH of the system user. This results in the default java that ships with Windows being run. The Wrapper itself does not do anything which would affect the performance of the Java process. One way to prove this is to copy the above java command line into a batch file, remove the -Dwrapper.key system property, then run the batch file manually outside of the Wrapper. If you still see the slowdowns there then the problem can be narrowed down to the parameters being passed to the JVM. Attach your wrapper.conf as well as the generated java commands above and I might be able to help out more. Cheers, Leif 2009/3/25 Gunal, Zeynep <zey...@tr...>: > Hi, > > > > We have noticed that it is taking longer for the service to process the same > input than when the application is run from the command prompt. > > > > For instance, processing a 39MB file from the command line took 4 > milliseconds but it took 12 minutes to process the same file with the > service. > > > > Also, the service seems to slowdown as more data is processed, for example > the number of records processed go from 204 in the first minute to 12/min > after 57 minutes! > > > > We increased the java heap size, we disabled the console logging level, this > behaviour did not change. > > > > Did anybody have a similar experience? Any suggestions? We are feeling > hopeless! > > > > Thanks. ------------------------------------------------------------------------ ------ 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 |
|
From: Erik D. <eri...@fj...> - 2009-03-27 08:25:35
|
fyi; We did not find the cause of the problem, so we reinstalled the environment as a test. The problem have disappeared. :/ -- Best regards, Erik Drolshammer |
|
From: Molde N. O. <nil...@ed...> - 2009-03-27 08:16:29
|
Hi Thanks for prompt reply. You got me there, I had managed to NOT put libwrapper.a into the AIX 5.3 environment. Embarrassed cheers, Nils Ottar :-) -----Original Message----- From: Leif Mortenson [mailto:le...@ta...] Sent: 26. mars 2009 19:26 To: wra...@li... Subject: Re: [Wrapper-user] AIX fails to run wrapper. Privileges problem? Molde, I need to get the minimum required OS versions up on the site. Sorry about the trouble. It looks like this is being caused because the WrapperManager.nativeInit(boolean) method is not being found. Could you please double check that you have the correct version of the libwrapper.so file? I will restest this on our test server tomorrow. Cheers, Leif 2009/3/26 Molde Nils Ottar <nil...@ed...>: > Hi > > After unsuccessfully running the latest community wrapper under AIX 5.1, I > tried to run under AIX 5.3. It seems that the initial link problem with AIX > libraries is resolved, but another error occurs. Any suggestions? > > Here is the environment : > >>uname -a > AIX aap-nbdrft-was04 3 5 000CE6C2D900 > >>/usr/java5/jre/bin/java -version > java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pap32dev-20071008 > (SR6)) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20071007 > (JIT enabled) > J9VM - 20071004_14218_bHdSMR > JIT - 20070820_1846ifx1_r8 > GC - 200708_10) > JCL - 20071008 > > Here is output from wrapper when trying to run my application : > > wrapper | --> Wrapper Started as Console > wrapper | Java Service Wrapper Community Edition 3.3.3 > wrapper | Copyright (C) 1999-2009 Tanuki Software, Ltd. All Rights > Reserved. > wrapper | http://wrapper.tanukisoftware.org > wrapper | > wrapper | Launching a JVM... > jvm 1 | WrapperManager: Initializing... > jvm 1 | Exception in thread "main" java.lang.UnsatisfiedLinkError: > org/tanukisoftware/wrapper/WrapperManager.nativeInit(Z)V > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.initializeNativeLibrary(WrapperManager.java:1254) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.privilegedClassInit(WrapperManager.java:666) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.access$000(WrapperManager.java:91) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager$1.run(WrapperManager.java:392) > jvm 1 | at > java.security.AccessController.doPrivileged(AccessController.java:197) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.<clinit>(WrapperManager.java:389) > jvm 1 | at java.lang.J9VMInternals.initializeImpl(Native Method) > jvm 1 | at > java.lang.J9VMInternals.initialize(J9VMInternals.java:194) > jvm 1 | at java.lang.Class.forNameImpl(Native Method) > jvm 1 | at java.lang.Class.forName(Class.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.class$(WrapperSimpleApp.java:74) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.<init>(WrapperSimpleApp.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.main(WrapperSimpleApp.java:483) > jvm 1 | Exception in thread "Wrapper-Shutdown-Hook" > java.lang.NoClassDefFoundError: org.tanukisoftware.wrapper.WrapperManager > (initialization failure) > jvm 1 | at > java.lang.J9VMInternals.initialize(J9VMInternals.java:132) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager$2.run(WrapperManager.java:522) > jvm 1 | Caused by: java.lang.UnsatisfiedLinkError: > org/tanukisoftware/wrapper/WrapperManager.nativeInit(Z)V > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.initializeNativeLibrary(WrapperManager.java:1254) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.privilegedClassInit(WrapperManager.java:666) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.access$000(WrapperManager.java:91) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager$1.run(WrapperManager.java:392) > jvm 1 | at > java.security.AccessController.doPrivileged(AccessController.java:197) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.<clinit>(WrapperManager.java:389) > jvm 1 | at java.lang.J9VMInternals.initializeImpl(Native Method) > jvm 1 | at > java.lang.J9VMInternals.initialize(J9VMInternals.java:194) > jvm 1 | at java.lang.Class.forNameImpl(Native Method) > jvm 1 | at java.lang.Class.forName(Class.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.class$(WrapperSimpleApp.java:74) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.<init>(WrapperSimpleApp.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.main(WrapperSimpleApp.java:483) > wrapper | JVM exited while loading the application. > > Regards > Nils Ottar Molde ------------------------------------------------------------------------------ _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Leif M. <lei...@ta...> - 2009-03-26 18:28:55
|
Ian, The wrapper.jar file is build once on a 32-bit windows machine using Java 1.3 for the best compatibility. That same jar is then included in the various releases. So no there are no differences. You can use the same wrapper.jar everyplace. If you need to support multiple platforms. Take a look at the delta pack. The files are all named to make this an easy task. Cheers, Leif 2009/3/27 <IKo...@ax...>: > Hello, > > I am wondering if there is a difference in the wrapper.jar files released > with the 32bit and 64bit wrapper releases. Obviously the wrapper executable > and library are different, but can a the wrapper.jar file released with a > 32bit Windows/Solaris release work with their 64bit wrapper executable and > library counterparts? Also is there a difference between the community and > standard versions of the wrapper.jar released? > > > > Thanks, > > Ian Koelliker > |
|
From: Leif M. <le...@ta...> - 2009-03-26 18:26:05
|
Molde, I need to get the minimum required OS versions up on the site. Sorry about the trouble. It looks like this is being caused because the WrapperManager.nativeInit(boolean) method is not being found. Could you please double check that you have the correct version of the libwrapper.so file? I will restest this on our test server tomorrow. Cheers, Leif 2009/3/26 Molde Nils Ottar <nil...@ed...>: > Hi > > After unsuccessfully running the latest community wrapper under AIX 5.1, I > tried to run under AIX 5.3. It seems that the initial link problem with AIX > libraries is resolved, but another error occurs. Any suggestions? > > Here is the environment : > >>uname -a > AIX aap-nbdrft-was04 3 5 000CE6C2D900 > >>/usr/java5/jre/bin/java -version > java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pap32dev-20071008 > (SR6)) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20071007 > (JIT enabled) > J9VM - 20071004_14218_bHdSMR > JIT - 20070820_1846ifx1_r8 > GC - 200708_10) > JCL - 20071008 > > Here is output from wrapper when trying to run my application : > > wrapper | --> Wrapper Started as Console > wrapper | Java Service Wrapper Community Edition 3.3.3 > wrapper | Copyright (C) 1999-2009 Tanuki Software, Ltd. All Rights > Reserved. > wrapper | http://wrapper.tanukisoftware.org > wrapper | > wrapper | Launching a JVM... > jvm 1 | WrapperManager: Initializing... > jvm 1 | Exception in thread "main" java.lang.UnsatisfiedLinkError: > org/tanukisoftware/wrapper/WrapperManager.nativeInit(Z)V > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.initializeNativeLibrary(WrapperManager.java:1254) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.privilegedClassInit(WrapperManager.java:666) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.access$000(WrapperManager.java:91) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager$1.run(WrapperManager.java:392) > jvm 1 | at > java.security.AccessController.doPrivileged(AccessController.java:197) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.<clinit>(WrapperManager.java:389) > jvm 1 | at java.lang.J9VMInternals.initializeImpl(Native Method) > jvm 1 | at > java.lang.J9VMInternals.initialize(J9VMInternals.java:194) > jvm 1 | at java.lang.Class.forNameImpl(Native Method) > jvm 1 | at java.lang.Class.forName(Class.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.class$(WrapperSimpleApp.java:74) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.<init>(WrapperSimpleApp.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.main(WrapperSimpleApp.java:483) > jvm 1 | Exception in thread "Wrapper-Shutdown-Hook" > java.lang.NoClassDefFoundError: org.tanukisoftware.wrapper.WrapperManager > (initialization failure) > jvm 1 | at > java.lang.J9VMInternals.initialize(J9VMInternals.java:132) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager$2.run(WrapperManager.java:522) > jvm 1 | Caused by: java.lang.UnsatisfiedLinkError: > org/tanukisoftware/wrapper/WrapperManager.nativeInit(Z)V > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.initializeNativeLibrary(WrapperManager.java:1254) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.privilegedClassInit(WrapperManager.java:666) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.access$000(WrapperManager.java:91) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager$1.run(WrapperManager.java:392) > jvm 1 | at > java.security.AccessController.doPrivileged(AccessController.java:197) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperManager.<clinit>(WrapperManager.java:389) > jvm 1 | at java.lang.J9VMInternals.initializeImpl(Native Method) > jvm 1 | at > java.lang.J9VMInternals.initialize(J9VMInternals.java:194) > jvm 1 | at java.lang.Class.forNameImpl(Native Method) > jvm 1 | at java.lang.Class.forName(Class.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.class$(WrapperSimpleApp.java:74) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.<init>(WrapperSimpleApp.java:130) > jvm 1 | at > org.tanukisoftware.wrapper.WrapperSimpleApp.main(WrapperSimpleApp.java:483) > wrapper | JVM exited while loading the application. > > Regards > Nils Ottar Molde |
|
From: <IKo...@ax...> - 2009-03-26 18:18:11
|
Hello, I am wondering if there is a difference in the wrapper.jar files released with the 32bit and 64bit wrapper releases. Obviously the wrapper executable and library are different, but can a the wrapper.jar file released with a 32bit Windows/Solaris release work with their 64bit wrapper executable and library counterparts? Also is there a difference between the community and standard versions of the wrapper.jar released? Thanks, Ian Koelliker |
|
From: Leif M. <le...@ta...> - 2009-03-26 18:03:05
|
Holger, Does this property work for you? http://wrapper.tanukisoftware.org/doc/english/prop-disable-restarts.html Cheers, Leif On Wed, Mar 25, 2009 at 11:19 PM, Isenberg, Holger <ise...@e-...> wrote: > When using external process monitoring tools (like Solaris SMF), you like to have manuel control over restart of the Java-VM process. For this, it would be nice to set wrapper.max_failed_invocations to 0, if this parameter is used for restarting. wrapper.on_exit.default=SHUTDOWN is already set. > > Needed is a configuration setting which prevents a restart in this case for example, when the Java-VM is terminated by a kill -9 PID: > > STATUS | wrapper | 2009/03/25 15:04:45 | JVM received a signal SIGKILL (9). > STATUS | wrapper | 2009/03/25 15:04:45 | JVM process is gone. > ERROR | wrapper | 2009/03/25 15:04:45 | JVM exited unexpectedly. > STATUS | wrapper | 2009/03/25 15:04:50 | Reloading Wrapper configuration... > INFO | wrapper | 2009/03/25 15:04:50 | Command[0] : java > > Is this possible with any current parameter setting? If not, would it be possible to include it in a future release? |
|
From: Molde N. O. <nil...@ed...> - 2009-03-25 15:25:53
|
Hi After unsuccessfully running the latest community wrapper under AIX 5.1, I tried to run under AIX 5.3. It seems that the initial link problem with AIX libraries is resolved, but another error occurs. Any suggestions? Here is the environment : >uname -a AIX aap-nbdrft-was04 3 5 000CE6C2D900 >/usr/java5/jre/bin/java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pap32dev-20071008 (SR6)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20071007 (JIT enabled) J9VM - 20071004_14218_bHdSMR JIT - 20070820_1846ifx1_r8 GC - 200708_10) JCL - 20071008 Here is output from wrapper when trying to run my application : wrapper | --> Wrapper Started as Console wrapper | Java Service Wrapper Community Edition 3.3.3 wrapper | Copyright (C) 1999-2009 Tanuki Software, Ltd. All Rights Reserved. wrapper | http://wrapper.tanukisoftware.org wrapper | wrapper | Launching a JVM... jvm 1 | WrapperManager: Initializing... jvm 1 | Exception in thread "main" java.lang.UnsatisfiedLinkError: org/tanukisoftware/wrapper/WrapperManager.nativeInit(Z)V jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.initializeNativeLibrary(WrapperManager.java:1254) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.privilegedClassInit(WrapperManager.java:666) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.access$000(WrapperManager.java:91) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager$1.run(WrapperManager.java:392) jvm 1 | at java.security.AccessController.doPrivileged(AccessController.java:197) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.<clinit>(WrapperManager.java:389) jvm 1 | at java.lang.J9VMInternals.initializeImpl(Native Method) jvm 1 | at java.lang.J9VMInternals.initialize(J9VMInternals.java:194) jvm 1 | at java.lang.Class.forNameImpl(Native Method) jvm 1 | at java.lang.Class.forName(Class.java:130) jvm 1 | at org.tanukisoftware.wrapper.WrapperSimpleApp.class$(WrapperSimpleApp.java:74) jvm 1 | at org.tanukisoftware.wrapper.WrapperSimpleApp.<init>(WrapperSimpleApp.java:130) jvm 1 | at org.tanukisoftware.wrapper.WrapperSimpleApp.main(WrapperSimpleApp.java:483) jvm 1 | Exception in thread "Wrapper-Shutdown-Hook" java.lang.NoClassDefFoundError: org.tanukisoftware.wrapper.WrapperManager (initialization failure) jvm 1 | at java.lang.J9VMInternals.initialize(J9VMInternals.java:132) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager$2.run(WrapperManager.java:522) jvm 1 | Caused by: java.lang.UnsatisfiedLinkError: org/tanukisoftware/wrapper/WrapperManager.nativeInit(Z)V jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.initializeNativeLibrary(WrapperManager.java:1254) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.privilegedClassInit(WrapperManager.java:666) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.access$000(WrapperManager.java:91) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager$1.run(WrapperManager.java:392) jvm 1 | at java.security.AccessController.doPrivileged(AccessController.java:197) jvm 1 | at org.tanukisoftware.wrapper.WrapperManager.<clinit>(WrapperManager.java:389) jvm 1 | at java.lang.J9VMInternals.initializeImpl(Native Method) jvm 1 | at java.lang.J9VMInternals.initialize(J9VMInternals.java:194) jvm 1 | at java.lang.Class.forNameImpl(Native Method) jvm 1 | at java.lang.Class.forName(Class.java:130) jvm 1 | at org.tanukisoftware.wrapper.WrapperSimpleApp.class$(WrapperSimpleApp.java:74) jvm 1 | at org.tanukisoftware.wrapper.WrapperSimpleApp.<init>(WrapperSimpleApp.java:130) jvm 1 | at org.tanukisoftware.wrapper.WrapperSimpleApp.main(WrapperSimpleApp.java:483) wrapper | JVM exited while loading the application. Regards Nils Ottar Molde |
|
From: Isenberg, H. <ise...@e-...> - 2009-03-25 14:19:23
|
When using external process monitoring tools (like Solaris SMF), you like to have manuel control over restart of the Java-VM process. For this, it would be nice to set wrapper.max_failed_invocations to 0, if this parameter is used for restarting. wrapper.on_exit.default=SHUTDOWN is already set. Needed is a configuration setting which prevents a restart in this case for example, when the Java-VM is terminated by a kill -9 PID: STATUS | wrapper | 2009/03/25 15:04:45 | JVM received a signal SIGKILL (9). STATUS | wrapper | 2009/03/25 15:04:45 | JVM process is gone. ERROR | wrapper | 2009/03/25 15:04:45 | JVM exited unexpectedly. STATUS | wrapper | 2009/03/25 15:04:50 | Reloading Wrapper configuration... INFO | wrapper | 2009/03/25 15:04:50 | Command[0] : java Is this possible with any current parameter setting? If not, would it be possible to include it in a future release? |
|
From: Molde N. O. <nil...@ed...> - 2009-03-25 12:45:26
|
Hi
I'm trying to install the latest community wrapper under AIX.
>uname -a
gives
AIX cbtp006k 1 5 0045C4FA4C00
And trying to start the wrapper gives :
exec(): 0509-036 Cannot load program /fs/export/et4682/PHEX/startup/./wrapper because of the following errors:
0509-130 Symbol resolution failed for wrapper because:
0509-136 Symbol __fd_select (number 47) is not exported from
dependent module /usr/lib/libc.a(shr.o).
0509-136 Symbol __fd_getdtablesize (number 66) is not exported from
dependent module /usr/lib/libc.a(shr.o).
0509-136 Symbol __strtollmax (number 86) is not exported from
dependent module /usr/lib/libc.a(shr.o).
0509-192 Examine .loader section symbols with the
'dump -Tv' command.
I'm suspecting that this version of the AIX OS is not supported, but can You confirm this? And if so, which is the oldest AIX OS You support, alternatively, is an older version of the wrapper able to run on my current AIX OS?
Regards
Nils Ottar Molde
|
|
From: Leif M. <lei...@ta...> - 2009-03-24 18:01:16
|
Gunal, Could you try setting the wrapper.java.command.loglevel=INFO property so the generated java command will be output to your logs. Then run the Wrapper in console mode and as a service to make sure that the correct JVM is being run. A common problem is to not add the correct JVM onto the PATH of the system user. This results in the default java that ships with Windows being run. The Wrapper itself does not do anything which would affect the performance of the Java process. One way to prove this is to copy the above java command line into a batch file, remove the -Dwrapper.key system property, then run the batch file manually outside of the Wrapper. If you still see the slowdowns there then the problem can be narrowed down to the parameters being passed to the JVM. Attach your wrapper.conf as well as the generated java commands above and I might be able to help out more. Cheers, Leif 2009/3/25 Gunal, Zeynep <zey...@tr...>: > Hi, > > > > We have noticed that it is taking longer for the service to process the same > input than when the application is run from the command prompt. > > > > For instance, processing a 39MB file from the command line took 4 > milliseconds but it took 12 minutes to process the same file with the > service. > > > > Also, the service seems to slowdown as more data is processed, for example > the number of records processed go from 204 in the first minute to 12/min > after 57 minutes! > > > > We increased the java heap size, we disabled the console logging level, this > behaviour did not change. > > > > Did anybody have a similar experience? Any suggestions? We are feeling > hopeless! > > > > Thanks. |
|
From: Gunal, Z. <zey...@tr...> - 2009-03-24 16:56:08
|
Hi, We have noticed that it is taking longer for the service to process the same input than when the application is run from the command prompt. For instance, processing a 39MB file from the command line took 4 milliseconds but it took 12 minutes to process the same file with the service. Also, the service seems to slowdown as more data is processed, for example the number of records processed go from 204 in the first minute to 12/min after 57 minutes! We increased the java heap size, we disabled the console logging level, this behaviour did not change. Did anybody have a similar experience? Any suggestions? We are feeling hopeless! Thanks. |
|
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) |
|
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. |
|
From: ejml <eli...@gm...> - 2009-03-24 15:12:59
|
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-tp22554782p22682593.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: ejml <eli...@gm...> - 2009-03-24 14:39:38
|
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-tp22554782p22681851.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
|
From: Leif M. <le...@ta...> - 2009-03-24 13:58:13
|
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) |
|
From: ejml <eli...@gm...> - 2009-03-24 13:08:56
|
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-tp22554782p22680034.html Sent from the Java Service Wrapper mailing list archive at Nabble.com. |
165 messages has been excluded from this view by a project administrator.
