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

[Wrapper-user] Problem with getting a service up

[naso t. <tp...@ya...>]

Hi all,

Thanks a lot for releasing this s/w in public.
I'm trying to load a freeware server Multiserver which
is basically a Java ServerSocket that listens to port
9999 for XML docs from a Flash server.

However, although the TestWrapper example is loading
OK and I can run My app from command line, I'm having
some problems loading the Multiserver.
When I try to start the Multiserver, the wrapper makes
5 retries and then times out with the message "JVM
didn't respond".

I have been trying to get some debug info but I can't
find out any more information. 

Did any of you guys have the same problem or now a way
to monitor the discussion with the JVM? If I use
-verbose param for the jvm I don't really see anything
useful.

Thanks in advance for any answers guys!!

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

RE: [Wrapper-user] wrapping catalina

[David R. <dre...@mo...>]

"What version of the Wrapper are you using?  From the reference to
Silver=20
Egg, it is
probably fairly old.  I transferred the license back to my own private=20
domain several
months ago."

Whoops, I missed that! I am using the latest version of Wrapper, but
have been following the project for a long time and missed the change of
license.

"Newer versions have added the wrapper.jvm_exit.timeout
property to control the amount of time to allow the JVM to exit after
the
WrapperManager has called System.exit().  This interval can take a few=20
minutes
if the user code has implemented any shutdown hooks which do not return
immediately."

Yes, apparently it is the shutdown hook in Tomcat that is causing the
"net stop" command to give up so quickly. Changing the "wait for all non
daemon threads to complete before exiting the JVM" flag in the
org.tanukisoftware.wrapper.WrapperStartStopApp class to false solved the
problem.=20

"Take a look at the 3 integration methods,  If you need fine control
over
exactly when the WrapperManager returns that the application has
actually
started then you are going to need to use method 3 and implement your
own class than implements WrapperListener.

Please post the solution you come up with as it may be useful to other
users."

No problem.

Regards,

David Resnick
MobileSpear Inc.

-----Original Message-----
From: Leif Mortenson [mailto:le...@ta...]=20
Sent: Monday, April 28, 2003 07:50
To: wra...@li...
Subject: Re: [Wrapper-user] wrapping catalina

David Resnick wrote:

>1. When shutting down a wrapper service using "net stop XXX" from the
>command line, the command gives up ("service cannot be stopped") before
>the wrapper.shutdown.timeout time has been reached. Is this a problem
>with the net command? Does anyone know of a solution to this?
>
What version of the Wrapper are you using?  From the reference to Silver

Egg, it is
probably fairly old.  I transferred the license back to my own private=20
domain several
months ago.

Newer versions have added the wrapper.jvm_exit.timeout
property to control the amount of time to allow the JVM to exit after
the
WrapperManager has called System.exit().  This interval can take a few=20
minutes
if the user code has implemented any shutdown hooks which do not return
immediately.

Take a look at the following URL for further details:
http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html

Also, I would suggest reviewing the integration methods as one of the=20
examples
is for integrating with Tomcat.  It might have some new info not=20
available in the
version you were using.
http://wrapper.tanukisoftware.org/doc/english/integrate.html

>2. I have wrapped tomcat which includes a number of web applications.
As
>far as I'm concerned, tomcat is not started until these web
applications
>have completed their initialization. The problem is that tomcat doesn't
>work that way, and instead signals that it is started as soon as it can
>start the various web apps. Does someone have a way of making the
>wrapper service start operation continue until a number of web apps
have
>initialized first?
>
Take a look at the 3 integration methods,  If you need fine control over
exactly when the WrapperManager returns that the application has
actually
started then you are going to need to use method 3 and implement your
own class than implements WrapperListener.

Please post the solution you come up with as it may be useful to other
users.

Cheers,
Leif




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Preventing Close on UI part of service

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

Bill,
    The Window in the task bar is being displayed by the Java process so I
don't think there is anything that I can do about it from the Wrapper.

    As a workaround though, have you tried playing around with adding a
WindowListener to your frame.  If you simply do nothing in the
windowClosing method you should be able to prevent the user from
closing the window.  As far as iconifying and maximizing the window.
It doesn't look like you can prevent the user from doing so, but there
are events that are fired that you can react to.   If they iconify the 
window
simply restore it.  Same with maximizing the window.   For the position,
you may need to have a thread which checks the position of the window
every 100ms or so and resets the position if it has changed.

    All a bit hackish, but it should work for you.  The only other idea 
would
be to have a native DLL lookup the window handle using its exact name
and then modify its attributes from the Windows API.  That sounds more
messy though...

Post back with the results of whatever you end up doing.

Cheers,
Leif

Bill Littman wrote:

>My project is an NT Service which uses Wrapper. It includes a JFrame
>which holds a display that monitors the status of the application, so
>there are no input controls on the JFrame. I perform a
>setUndecorated(true) on the JFrame to remove the entire title bar, so
>the user cannot move, resize, minimize, maximize, and most importantly,
>close the JFrame.
>
>Wrapper has allowed me to do a beautiful thing. When the computer is on
>but not logged in, the service runs fine. When the user logs in, up pops
>the JFrame monitor. Log in, log out, the application behaves
>beautifully. There is only one problem (okay, there are other problems,
>but not with anything to do with Wrapper!).
>
>The JFrame also deposits the usual task button on the task bar. If I
>right click on this button, I can close the JFrame (and minimize,
>maximize, and so forth). Is there any way to do either one of two
>things:
>1. Disable the right click menu for the task button (I would be happy if
>just the close were not enabled). Or,
>2. Allow the JFrame to come up without an associated task bar button.
>
>Thanks in advance for any help.
>

Re: [Wrapper-user] wrapping catalina

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

David Resnick wrote:

>1. When shutting down a wrapper service using "net stop XXX" from the
>command line, the command gives up ("service cannot be stopped") before
>the wrapper.shutdown.timeout time has been reached. Is this a problem
>with the net command? Does anyone know of a solution to this?
>
What version of the Wrapper are you using?  From the reference to Silver 
Egg, it is
probably fairly old.  I transferred the license back to my own private 
domain several
months ago.

Newer versions have added the wrapper.jvm_exit.timeout
property to control the amount of time to allow the JVM to exit after the
WrapperManager has called System.exit().  This interval can take a few 
minutes
if the user code has implemented any shutdown hooks which do not return
immediately.

Take a look at the following URL for further details:
http://wrapper.tanukisoftware.org/doc/english/prop-jvm-exit-timeout.html

Also, I would suggest reviewing the integration methods as one of the 
examples
is for integrating with Tomcat.  It might have some new info not 
available in the
version you were using.
http://wrapper.tanukisoftware.org/doc/english/integrate.html

>2. I have wrapped tomcat which includes a number of web applications. As
>far as I'm concerned, tomcat is not started until these web applications
>have completed their initialization. The problem is that tomcat doesn't
>work that way, and instead signals that it is started as soon as it can
>start the various web apps. Does someone have a way of making the
>wrapper service start operation continue until a number of web apps have
>initialized first?
>
Take a look at the 3 integration methods,  If you need fine control over
exactly when the WrapperManager returns that the application has actually
started then you are going to need to use method 3 and implement your
own class than implements WrapperListener.

Please post the solution you come up with as it may be useful to other
users.

Cheers,
Leif

[Wrapper-user] wrapping catalina

[David R. <dre...@mo...>]

Hi Leif and fellow Wrappers,

I would first of all like to thank Leif Mortenson and Silver Egg
software for developing such an excellent program and for making it
available to the general public. Keep up the good work!

I recently started using wrapper (on W2K) and have encountered 2 issues:

1. When shutting down a wrapper service using "net stop XXX" from the
command line, the command gives up ("service cannot be stopped") before
the wrapper.shutdown.timeout time has been reached. Is this a problem
with the net command? Does anyone know of a solution to this?

2. I have wrapped tomcat which includes a number of web applications. As
far as I'm concerned, tomcat is not started until these web applications
have completed their initialization. The problem is that tomcat doesn't
work that way, and instead signals that it is started as soon as it can
start the various web apps. Does someone have a way of making the
wrapper service start operation continue until a number of web apps have
initialized first?

Thanks,

David Resnick
MobileSpear Inc.

[Wrapper-user] Preventing Close on UI part of service

[Bill L. <bli...@to...>]

My project is an NT Service which uses Wrapper. It includes a JFrame
which holds a display that monitors the status of the application, so
there are no input controls on the JFrame. I perform a
setUndecorated(true) on the JFrame to remove the entire title bar, so
the user cannot move, resize, minimize, maximize, and most importantly,
close the JFrame.

Wrapper has allowed me to do a beautiful thing. When the computer is on
but not logged in, the service runs fine. When the user logs in, up pops
the JFrame monitor. Log in, log out, the application behaves
beautifully. There is only one problem (okay, there are other problems,
but not with anything to do with Wrapper!).

The JFrame also deposits the usual task button on the task bar. If I
right click on this button, I can close the JFrame (and minimize,
maximize, and so forth). Is there any way to do either one of two
things:
1. Disable the right click menu for the task button (I would be happy if
just the close were not enabled). Or,
2. Allow the JFrame to come up without an associated task bar button.

Thanks in advance for any help.

-Bill Littman
 Lead Software Engineer
 TomoTherapy, Inc.
 1240 Deming Way
 Madison, WI  53717
 Direct Phone: 608 824-2815
 Phone: 608 824-2800
 Fax: 608 824-2996
 Web address: http://www.tomotherapy.com
 Email: bli...@to...

Re: [Wrapper-user] Wrapper and Catalina ( interact with desktop option)

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

The interactive option is used to allow the service to display a GUI. It 
does
not display the console.   If you want to view the console output download
a tail program and then tail the wrapper.log file.  If you do a google 
search
for "Windows tail", there are several out there.

Hope this helps,
Cheers,
Leif


Jean-Marc Taillant wrote:

>I would like to use Java Wrapper to start/stop my catalina 4.1.24 with NT
>Service. All seems ok, my server i succeed in starting/stopping my server
>through NT service console. Now I would like to be able to launch a DOS
>console to see CATALINA logs. I take the standard options for starting
>CATALINA. I set the interactive option to true but when I start the Service
>no console is displayed!
>  
>

[Wrapper-user] RE: questions

[Jindong Li <Jin...@so...>]

Haven't figured out how to reply directly from the archive but anyway thanks
for all the comments...

I tried Leif's suggestions,

First I tried to run the rmiregistry, my two RMI servers and Tomcat as
separate services, that's 4 services together, and it seems to work fine,
the log off is no longer an issue since the wrappers shield the log-off
event nicely...:-)

Then I tried the second suggestion, to instead of starting up the other 3
JVM's directly, using the Wrapper in the console mode to spawn the other 3
JVM's, log off event still seems to kill those other 3 JVM's though...:-(

Also, with the second approach one of the my servlets is throwing some
strange "connection closed" exceptions which I have no idea why it's
happening...

Any way it seems to me that wrap each JVM within a wrapper is probably the
way to go...

The WrapperStartStopApp.java is a nice one, specially the option to kill the
JVM right after it returns is good, as with Tomcat 4.1.18, since it shuts
down gracefully now meaning that it'll wait until all threads finish,
normally takes a long time to shut down, but that option takes care of this
problem rather nicely...

Another question I have...is that, say if I have a service takes really a
long time to start and it's using WrapperStartStopApp.java, will it be able
to start normally?

I know if we go through the GUI approach, we'll get a "not responded in a
timely fashion" screen even though the service will eventually start, but if
we use "net start" then there shouldn't be any problems, since
WrapperStartStopApp.java always waits extra 2 sec after the main method
returns?

Am I right?

Thanks a lot...

Jindong.

		 -----Original Message-----
		From: 	Jindong Li  
		Sent:	Tuesday, April 22, 2003 3:26 PM
		To:	'wra...@li...'
		Subject:	RE: questions

		One more thing I noticed, if I log off the system with the
service running, those 3 JVM's that started by my java application which is
wrapped by the service wrapper are killed, reason I know this is happening
is that, one JVM is used to start TOMCAT, once I logged off, I was not able
to talk to the WebServer on port 8080 anymore.

		If I then log on again, the service status is still showing
running but really it is just the wrapper that's running, all JVM's started
by the service seem to be no longer running...

		Is this because how the windows log off process works?

		Anybody else tried log off, if so after logging off, is the
application still running as expected?

		Thanks,

		Jindong.

				 -----Original Message-----
				From: 	Jindong Li  
				Sent:	Friday, April 04, 2003 3:04 PM
				To:	'wra...@li...'
				Subject:	RE: questions

				Thanks for your prompt reply...

				My application just starts up another 3
JVM's where RMI servers running in 2 of them and Tomcat running in the 3rd
one...so from the point of the JVM where this application is launched, I
suppose there's no non-daemon threads running?

				Here're the log files I got after turned on
debug for the wrapper...interesting thing is that when I stop the service
from command line using "net stop", sometime it is successful sometimes it
isn't...the first one is the one that I was able to stop the service from
command line, the second one however, I got the "could not be stopped"
message.

				It seems to me that in both cases, wrapper
is working just fine...

				 << File: wrapper.log.stopped >>  << File:
wrapper.log.notbestopped >> 

				Any comment would be appreciated...

				Thanks,

				Jindong.

				 -----Original Message-----
				From: 	Jindong Li  
				Sent:	Wednesday, April 02, 2003 11:06 AM
				To:	'wra...@li...';
'wra...@li...'
				Subject:	questions

				Hi there,

				I'm currently exploring the possibility of
using Java Service Wrapper to run our Java application as an NT service
(Windows 2000 professional), everything is going well so far...you guys did
a great job!!

				I do have couple of questions:

*	The WrapperManager detects if there's any non-daemon threads other
than the current thread and system thread running after the application is
launched, in my case since all my threads are daemon threads, I had to start
another thread in my listener code to run indefinitely until it receives the
stop control from the service panel...otherwise, the service will be stopped
right after it was started, any other way to get around that ?

*	When I use the command line command "net start/stop" to start / stop
the service I installed using wrapper.exe, starting is always successful
without any issue but stopping, on the other hand,  I often get "... service
could not be stopped." even though the service has been stopped indeed...any
idea?  This problem does not appear to exist if stopping from the GUI.

				Thanks and really appreciate your help...

				Jindong.

 
###############################################################
This message has been scanned for viruses and other contents.
###############################################################

[Wrapper-user] Wrapper and Catalina ( interact with desktop option)

[Jean-Marc T. <tai...@bs...>]

Hi,

I would like to use Java Wrapper to start/stop my catalina 4.1.24 with NT
Service. All seems ok, my server i succeed in starting/stopping my server
through NT service console. Now I would like to be able to launch a DOS
console to see CATALINA logs. I take the standard options for starting
CATALINA. I set the interactive option to true but when I start the Service
no console is displayed!

Any idea,

Regards,

Jean-Marc

RE: [Wrapper-user] Getting

[Bill L. <bli...@to...>]

Hi Leif-

That was it! FYI, I added this line to my config file:
  wrapper.java.library.path.2=3DC:\Progra~1\SQLLIB\bin
and the program ran fine.

Thanks again for the help, thanks for the cool product, and sorry for
the incomplete subject line!

-Bill


> -----Original Message-----
> From: Leif Mortenson [mailto:le...@ta...]=20
> Sent: Thursday, April 24, 2003 10:12 AM
> To: wra...@li...
> Subject: Re: [Wrapper-user] Getting
>=20
>=20
> Bill,
>     Does the DB2 driver have a native library that it is loading?  I=20
> noticed that
> in your batch file you are not specifying a library path.  This means=20
> that the
> JVM will be using its default library path.
>=20
>     In the case of the Wrapper, you are specifying a library path of=20
> "../lib".
> Most likely that is where your Wrapper.DLL file is located.  =20
> If you want to
> run the exact same command in your batch file as is used by=20
> the wrapper,
> you should copy the exact command from the Wrapper debug output into
> a batch file and then remove the -Dwrapper.key property.
>   =20
>     Give that a try.  I bet you will find that you get the=20
> same failure.=20
>  If so,
> figure out where the DB2 native libraries are located and add them to
> the library path.  My guess is that that will fix things for=20
> you.  (I am=20
> going
> off of memory about the DB2 driver having a native component.  Let
> me know if I am wrong.)
>     You can see any native calls by adding the -verbose:jni=20
> argument to
> the JVM when you launch it.  It doesn't tell you where the DLLs are
> located however.
>=20
> Cheers,
> Leif
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>=20

Re: [Wrapper-user] Getting

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

Bill,
    Does the DB2 driver have a native library that it is loading?  I 
noticed that
in your batch file you are not specifying a library path.  This means 
that the
JVM will be using its default library path.

    In the case of the Wrapper, you are specifying a library path of 
"../lib".
Most likely that is where your Wrapper.DLL file is located.   If you want to
run the exact same command in your batch file as is used by the wrapper,
you should copy the exact command from the Wrapper debug output into
a batch file and then remove the -Dwrapper.key property.
   
    Give that a try.  I bet you will find that you get the same failure. 
 If so,
figure out where the DB2 native libraries are located and add them to
the library path.  My guess is that that will fix things for you.  (I am 
going
off of memory about the DB2 driver having a native component.  Let
me know if I am wrong.)
    You can see any native calls by adding the -verbose:jni argument to
the JVM when you launch it.  It doesn't tell you where the DLLs are
located however.

Cheers,
Leif

[Wrapper-user] Getting

[Bill L. <bli...@to...>]

I am trying to turn my application into a service. First, I got it
running under the NoWrapper script and it runs fine. Next, I tried
running from the command file that uses wrapper and I am running into
problems.

When I try to run my application under Wrapper, I am getting a "No
suitable driver" when attempting to access the database. I have the same
JAR (actually an IBM ZIP file) for the DB2 driver in both situations.
Below appears the log from the run with Wrapper, the wrapper.conf file I
am using, my NoWrapper script, and my NoWrapper script pulled apart for
easy reading.

___________________________________________

Here are snippets from the log:

STATUS | wrapper  | 2003/04/24 08:52:39 | --> Wrapper Started as Console
DEBUG  | wrapperp | 2003/04/24 08:52:40 | server listening on port 1777.
STATUS | wrapper  | 2003/04/24 08:52:41 | Launching a JVM...
DEBUG  | wrapper  | 2003/04/24 08:52:41 | command:
"C:\j2sdk1.4.1_02\bin\java.exe" -Dsun.java2d.noddraw=3Dtrue
-Dtomo.nameserver.name=3DTW0010 -Dtomo.nameserver.port=3D53562
-Dtomo.database.name=3Dtestdb
-Djdbc.drivers=3DCOM.ibm.db2.jdbc.app.DB2Driver -Xms400m -Xmx500m
-Djava.library.path=3D"../lib" -classpath
"../lib/wrapper.jar;C:\tomo\ds;C:\tomo\ds\autoCorba.jar;C:\tomo\ds\corba
Server.jar;C:\tomo\ds\OpenORB\avalon-framework.jar;C:\tomo\ds\OpenORB\lo
gkit.jar;C:\tomo\ds\OpenORB\xerces.jar;C:\tomo\ds\OpenORB\openorb_ots-1.
3.0.jar;C:\tomo\ds\OpenORB\openorb_ins-1.3.0.jar;C:\tomo\ds\OpenORB\open
orb-1.3.0.jar;C:\tomo\ds\OpenORB\openorb_pss-1.3.0.jar;C:\tomo\ds\OpenOR
B\openorb_tools-1.3.0.jar;C:\tomo\ds\edi\jdt\jdt.jar;C:\tomo\ds\edi\jdt;
C:\Progra~1\SQLLIB\java\db2java.zip" -Dwrapper.key=3D"LtXzgHVasbC1DTwn"
-Dwrapper.port=3D1777 -Dwrapper.debug=3D"TRUE" =
-Dwrapper.cpu.timeout=3D"10"
-Dwrapper.jvmid=3D1 org.tanukisoftware.wrapper.WrapperSimpleApp
com.tomotherapy.tomo.corba.dsmanager.DSManager
DEBUG  | wrapper  | 2003/04/24 08:52:41 | Java Virtual Machine started
(PID=3D536)
INFO   | jvm 1    | 2003/04/24 08:52:41 | Wrapper Manager: JVM #1
INFO   | jvm 1    | 2003/04/24 08:52:41 | Wrapper Manager: Registering
shutdown hook
INFO   | jvm 1    | 2003/04/24 08:52:41 | Wrapper Manager: Using wrapper
INFO   | jvm 1    | 2003/04/24 08:52:41 | Calling native initialization
method.
INFO   | jvm 1    | 2003/04/24 08:52:41 | Initializing WrapperManager
native library.
INFO   | jvm 1    | 2003/04/24 08:52:41 | Java Executable:
C:\j2sdk1.4.1_02\bin\java.exe
INFO   | jvm 1    | 2003/04/24 08:52:41 | Java Version   : 1.4.1_02-b06
Java HotSpot(TM) Client VM
INFO   | jvm 1    | 2003/04/24 08:52:41 | Java VM Vendor : Sun
Microsystems Inc.
INFO   | jvm 1    | 2003/04/24 08:52:41 |=20
INFO   | jvm 1    | 2003/04/24 08:52:41 | Wrapper (Version 3.0.2)
INFO   | jvm 1    | 2003/04/24 08:52:41 |=20
INFO   | jvm 1    | 2003/04/24 08:52:41 | Open socket to wrapper...
INFO   | jvm 1    | 2003/04/24 08:52:41 | Opened Socket
INFO   | jvm 1    | 2003/04/24 08:52:41 | Send a packet 110 :
LtXzgHVasbC1DTwn
INFO   | jvm 1    | 2003/04/24 08:52:41 |
handleSocket(Socket[addr=3D/127.0.0.1,port=3D1777,localport=3D4465])
DEBUG  | wrapperp | 2003/04/24 08:52:41 | accepted a socket from
127.0.0.1 on port 4465
DEBUG  | wrapperp | 2003/04/24 08:52:41 | read a packet 110 :
LtXzgHVasbC1DTwn
DEBUG  | wrapper  | 2003/04/24 08:52:41 | Got key from JVM:
LtXzgHVasbC1DTwn
DEBUG  | wrapperp | 2003/04/24 08:52:41 | send a packet 112 : 1
DEBUG  | wrapperp | 2003/04/24 08:52:41 | send a packet 113 : 30
DEBUG  | wrapper  | 2003/04/24 08:52:41 | Start Application.
DEBUG  | wrapperp | 2003/04/24 08:52:41 | send a packet 100 : start
<snip>
DEBUG  | wrapperp | 2003/04/24 08:52:46 | send a packet 103 : ping
INFO   | jvm 1    | 2003/04/24 08:52:46 | Received a packet 103 : ping
INFO   | jvm 1    | 2003/04/24 08:52:46 | Send a packet 103 : ok
DEBUG  | wrapperp | 2003/04/24 08:52:46 | read a packet 103 : ok
DEBUG  | wrapper  | 2003/04/24 08:52:46 | Got ping response from JVM
<snip>
INFO   | jvm 1    | 2003/04/24 08:52:56 | CORBA Server SQLException,
performing [Could not get database connection.], SQLMessage =3D [No
suitable driver]  No suitable driver
<snip>

______________________________________________________


And here is my wrapper.conf file:
#********************************************************************
# Wrapper Properties
#********************************************************************

# Java Application
wrapper.java.command=3DC:\j2sdk1.4.1_02\bin\java.exe

# Java Main class
wrapper.java.mainclass=3Dorg.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=3D../lib/wrapper.jar
wrapper.java.classpath.2=3DC:\tomo\ds
wrapper.java.classpath.3=3DC:\tomo\ds\autoCorba.jar
wrapper.java.classpath.4=3DC:\tomo\ds\corbaServer.jar
wrapper.java.classpath.5=3DC:\tomo\ds\OpenORB\avalon-framework.jar
wrapper.java.classpath.6=3DC:\tomo\ds\OpenORB\logkit.jar
wrapper.java.classpath.7=3DC:\tomo\ds\OpenORB\xerces.jar
wrapper.java.classpath.8=3DC:\tomo\ds\OpenORB\openorb_ots-1.3.0.jar
wrapper.java.classpath.9=3DC:\tomo\ds\OpenORB\openorb_ins-1.3.0.jar
wrapper.java.classpath.10=3DC:\tomo\ds\OpenORB\openorb-1.3.0.jar
wrapper.java.classpath.11=3DC:\tomo\ds\OpenORB\openorb_pss-1.3.0.jar=20
wrapper.java.classpath.12=3DC:\tomo\ds\OpenORB\openorb_tools-1.3.0.jar
wrapper.java.classpath.13=3DC:\tomo\ds\edi\jdt\jdt.jar
wrapper.java.classpath.14=3DC:\tomo\ds\edi\jdt
wrapper.java.classpath.15=3DC:\Progra~1\SQLLIB\java\db2java.zip

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

# Java Additional Parameters
wrapper.java.additional.1=3D-Dsun.java2d.noddraw=3Dtrue
wrapper.java.additional.2=3D-Dtomo.nameserver.name=3DTW0010
wrapper.java.additional.3=3D-Dtomo.nameserver.port=3D53562
wrapper.java.additional.4=3D-Dtomo.database.name=3Dtestdb
wrapper.java.additional.5=3D-Djdbc.drivers=3DCOM.ibm.db2.jdbc.app.DB2Driv=
er

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

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

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=3Dcom.tomotherapy.tomo.corba.dsmanager.DSManager

# Port which the native wrapper code will attempt to connect to
wrapper.port=3D1777

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Format of output for the console.  (See docs for formats)
wrapper.console.format=3DPM

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

# Log file to use for wrapper output logging.
wrapper.logfile=3D../logs/wrapper.log

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

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

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

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

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

#********************************************************************
# Wrapper NT Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.ntservice.name=3DDSCorbaServer

# Display name of the service
wrapper.ntservice.displayname=3DTomoTherapy DataServer CORBA Server

# Description of the service
wrapper.ntservice.description=3DTomoTherapy DataServer CORBA Server

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=3D

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=3DAUTO_START

# Priority at which the service is run.  NORMAL, LOW, HIGH, or
#  REALTIME
wrapper.ntservice.process_priority=3DHIGH

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=3Dtrue

__________________________________________________________


Here is the NoWrapper script:

rem
rem This script lets you run your application without the wrapper.
Useful for testing.
rem

C:\j2sdk1.4.1_02\bin\java.exe -Xms400m -Xmx500m
-Dsun.java2d.noddraw=3Dtrue -Dtomo.nameserver.name=3DTW0010
-Dtomo.nameserver.port=3D53562  -Dtomo.database.name=3Dtestdb -classpath
C:\tomo\ds;C:\HiArt_2.0\source\buildDebug\java\autoCorba.jar;C:\HiArt_2.
0\source\buildDebug\java\corbaServer.jar;C:\OpenORB1.3.0\debugJARs\avalo
n-fram
ework.jar;C:\OpenORB1.3.0\debugJARs\logkit.jar;C:\OpenORB1.3.0\debugJARs
\xerces.jar;C:\OpenORB1.3.0\debugJARs\openorb_ots-1.3.0.jar;C:\OpenORB1.
3.0\de
bugJARs\openorb_ins-1.3.0.jar;C:\OpenORB1.3.0\debugJARs\openorb-1.3.0.ja
r;C:\OpenORB1.3.0\debugJARs\openorb_pss-1.3.0.jar;C:\OpenORB1.3.0\debugJ
ARs\op
enorb_tools-1.3.0.jar;C:\HiArt_2.0\source\code\java\libs\SoftLink\jdt.ja
r;C:\HiArt_2.0\source\code\java\libs\SoftLink;C:\Progra~1\SQLLIB\java\db
2java. zip; com.tomotherapy.tomo.corba.dsmanager.DSManager

__________________________________________________________


And here is the NoWrapper script pulled apart for easy reading:

C:\j2sdk1.4.1_02\bin\java.exe=20

-Xms400m=20
-Xmx500m=20

-Dsun.java2d.noddraw=3Dtrue=20
-Dtomo.nameserver.name=3DTW0010=20
-Dtomo.nameserver.port=3D53562=20
-Dtomo.database.name=3Dtestdb=20

-classpath C:\tomo\ds
C:\HiArt_2.0\source\buildDebug\java\autoCorba.jar
C:\HiArt_2.0\source\buildDebug\java\corbaServer.jar
C:\OpenORB1.3.0\debugJARs\avalon-framework.jar
C:\OpenORB1.3.0\debugJARs\logkit.jar
C:\OpenORB1.3.0\debugJARs\xerces.jar
C:\OpenORB1.3.0\debugJARs\openorb_ots-1.3.0.jar
C:\OpenORB1.3.0\debugJARs\openorb_ins-1.3.0.jar
C:\OpenORB1.3.0\debugJARs\openorb-1.3.0.jar
C:\OpenORB1.3.0\debugJARs\openorb_pss-1.3.0.jar
C:\OpenORB1.3.0\debugJARs\openorb_tools-1.3.0.jar
C:\HiArt_2.0\source\code\java\libs\SoftLink\jdt.jar
C:\HiArt_2.0\source\code\java\libs\SoftLink
C:\Progra~1\SQLLIB\java\db2java.zip

com.tomotherapy.tomo.corba.dsmanager.DSManager

__________________________________________________________


Many thanks in advance for any assistance.

-Bill Littman
 Lead Software Engineer
 TomoTherapy, Inc.
 1240 Deming Way
 Madison, WI  53717
 Direct Phone: 608 824-2815
 Phone: 608 824-2800
 Fax: 608 824-2996
 Web address: http://www.tomotherapy.com
 Email: bli...@to...

Re: Casting malloc() results (was Re: [Wrapper-user] Mac OS X - Segmentation Fault)

[<da...@ix...>]

In article <3EA...@tr...>,
Joseph Knapka  <wra...@li...> wrote:
>Could you possibly provide a reference for this rule? I have always
>cast the results of malloc(), based on the advice contained in
>K&R 2nd ed. pg. 142 (K&R2 claims to cover ANSI C), but (obviously)
>I haven't done much C programming recently :-)  Other sources I've
>looked at say that it's not *necessary* to cast malloc's result,
>but that it doesn't hurt. So I'm just wondering about your statement
>above, which seems to be made with great conviction :-) Does the
>ISO C standard recommend against casting?

Errata for The C Programming Language, Second Edition
http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html

   142: The remark about casting the return value of malloc ("the proper
   method is to declare ... then explicitly coerce") needs to be
   rewritten. The example is correct and works, but the advice is 
   debatable in the context of the 1988-1989 ANSI/ISO standards. It's not
   necessary (given that coercion of void * to ALMOSTANYTYPE * is
   automatic), and possibly harmful if malloc, or a proxy for it, fails
   to be declared as returning void *. The explicit cast can cover up an
   unintended error. On the other hand, pre-ANSI, the cast was necessary,
   and it is in C++ also.

   167: [the return value of malloc or calloc] "must be cast into the
   appropriate type" is incorrect as stated. See the remarks just above
   for p. 142.


Not to mention, just about any thread on comp.lang.c.  :->

mrc

-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] Wrapper not restarting JVM after NullPointerException

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

Andy,
    The Wrapper is never going to be able work around every problem
with a user application.   The problems that you are talking about are
bugs in your application.  The filters are designed to help in cases
where the user does not have complete control over an application's
source.

If you are having a problem with code throwing uncaught exceptions,
then catch them at the thread's root.   I usually set up daemon threads
as follows:

public run()
{
    while ( !m_shutdown )
    {
        try
        {
            // Real code goes here.
        }
        catch ( Throwable t )
        {
            System.out.println( "Unexpected error in xxx daemon:" );
            t.printStackTrace();

            // May want to wait a few seconds to avoid thrashing...
        }
    }
}

The above code is a last line of protection to prevent a critical thread
from terminating abnormally.  This method has always worked for me
as there is no way for the thread to die without being caught by the
throwable catch.   The thread can be stopped, but that method is
deprecated and does not usually happen unless you mean to.

Andy Barnett wrote:

> Now my application is restarted appropriately when a NPE occurs; 
> however, I don't think this is a robust enough solution for my 
> situation. If my application's main thread dies due to any exception, 
> I need the Wrapper to restart it. I don't think I can express that 
> completely with wrapper.filter properties. 

If you have specific cases that you are worried about, I will look into the
feasibility of adding features to the Wrapper.

> Do I have other options? 

The above code is simply a safety net.  Neither this nor the protections
provided by the Wrapper are a replacement for fixing bugs in your
program.

Cheers,
Leif

Re: [Wrapper-user] RE: questions

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

Mike Castle wrote:

>Does that really work?  I thought that just told NT that you need to start
>those dependencies; not that one needs to be up and running before the next.
>
The WrapperSimpleApp and WrapperStartStopApp helper classes will return
their applications have started after about 5 seconds. This was necessary
to make them work reliably with any Java application.
If your applications are integrated using the WrapperListener method then
you can control when that interface's start method returns. The Wrapper
will not tell the NT service manager that the application has started until
the start method has returned, and the NT service manager will not start
a dependent service until the first has been started. In my experience
this has worked reliably.

If you are worried about it, then you can use my other suggestion about
having your master application launch the child JVMs wrapped inside their
own Wrappers rather than launching them directly. That should protect
them from the logout problem. I have not tested that exact thing before.
But I see no reason why it shouldn't work.

Cheers,
Leif

Re: [Wrapper-user] RE: questions

[<da...@ix...>]

In article <3EA...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>If you are worried about launching your JVMs in a particular order, you can
>specify server dependencies in the wrapper.conf file.  That will make the
>NT service manager start and stop the services in the correct order.

Does that really work?  I thought that just told NT that you need to start
those dependencies; not that one needs to be up and running before the next.

I always see NT start them all up at the same time; which is often not what
you want.  (Granted, the applications *should* be roboust enough to retry
whatever they need to retry if the necessary app isn't up and running yet,
but dammit, we're lazy!)

mrc

-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [Wrapper-user] New UNIX Scripts - Request for feedback.

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

Richard,
    Great I would not have come up with that on my own.  I was able to
modify the sh and bash scripts based on the function you sent so that
the scripts now work perfectly without using the realpath utility at all.
I did have to modify things slightly so that the scripts would work
correctly when called with a relative path.
    The new scripts seem to work for all circumstances that I tested so
far.  If you an others could once again take a look at them and make
sure they work on your environments, I would appreciate it.

    Now that these scripts no longer need the realpath utility, I would
like to remove it from the distribution.  One concern is that this could
break some peoples' build scripts which are expecting the file to be
there.   But they will have to be fixed at some point even if I defer
pulling the utility out, so unless I hear any major objections, I'll go 
ahead
and remove it.

Cheers,
Leif

Re: [Wrapper-user] RE: questions

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

The Wrapper controlls the single JVM that it directly launches.  That JVM is
protected from the Windows OS killing it when a user logs off because it
loads the Wrapper.DLL.  That DLL intercepts the logoff control signal.

The 3 JVMs that you are spawning will not be protected so they are still
receiving the logoff control signals and exiting.

Is there any reason why you can not wrap those 3 JVMs in Wrappers as
well?  Either set them up as NT services themselves or spawn their
Wrappers in console mode as you are currently doing with the JVMs now.

If you are worried about launching your JVMs in a particular order, you can
specify server dependencies in the wrapper.conf file.  That will make the
NT service manager start and stop the services in the correct order.

Cheers,
Leif

Jindong Li wrote:

> One more thing I noticed, if I log off the system with the service 
> running, those 3 JVM's that started by my java application which is 
> wrapped by the service wrapper are killed, reason I know this is 
> happening is that, one JVM is used to start TOMCAT, once I logged off, 
> I was not able to talk to the WebServer on port 8080 anymore.
>
> If I then log on again, the service status is still showing running 
> but really it is just the wrapper that's running, all JVM's started by 
> the service seem to be no longer running...
>
> Is this because how the windows log off process works?
>
> Anybody else tried log off, if so after logging off, is the 
> application still running as expected?
>
> Thanks,
>
> Jindong.
>

[Wrapper-user] RE: questions

[Jindong Li <Jin...@so...>]

One more thing I noticed, if I log off the system with the service running,
those 3 JVM's that started by my java application which is wrapped by the
service wrapper are killed, reason I know this is happening is that, one JVM
is used to start TOMCAT, once I logged off, I was not able to talk to the
WebServer on port 8080 anymore.

If I then log on again, the service status is still showing running but
really it is just the wrapper that's running, all JVM's started by the
service seem to be no longer running...

Is this because how the windows log off process works?

Anybody else tried log off, if so after logging off, is the application
still running as expected?

Thanks,

Jindong.

		 -----Original Message-----
		From: 	Jindong Li  
		Sent:	Friday, April 04, 2003 3:04 PM
		To:	'wra...@li...'
		Subject:	RE: questions

		Thanks for your prompt reply...

		My application just starts up another 3 JVM's where RMI
servers running in 2 of them and Tomcat running in the 3rd one...so from the
point of the JVM where this application is launched, I suppose there's no
non-daemon threads running?

		Here're the log files I got after turned on debug for the
wrapper...interesting thing is that when I stop the service from command
line using "net stop", sometime it is successful sometimes it isn't...the
first one is the one that I was able to stop the service from command line,
the second one however, I got the "could not be stopped" message.

		It seems to me that in both cases, wrapper is working just
fine...

		 << File: wrapper.log.stopped >>  << File:
wrapper.log.notbestopped >> 

		Any comment would be appreciated...

		Thanks,

		Jindong.

				 -----Original Message-----
				From: 	Jindong Li  
				Sent:	Wednesday, April 02, 2003 11:06 AM
				To:	'wra...@li...';
'wra...@li...'
				Subject:	questions

				Hi there,

				I'm currently exploring the possibility of
using Java Service Wrapper to run our Java application as an NT service
(Windows 2000 professional), everything is going well so far...you guys did
a great job!!

				I do have couple of questions:

*	The WrapperManager detects if there's any non-daemon threads other
than the current thread and system thread running after the application is
launched, in my case since all my threads are daemon threads, I had to start
another thread in my listener code to run indefinitely until it receives the
stop control from the service panel...otherwise, the service will be stopped
right after it was started, any other way to get around that ?

*	When I use the command line command "net start/stop" to start / stop
the service I installed using wrapper.exe, starting is always successful
without any issue but stopping, on the other hand,  I often get "... service
could not be stopped." even though the service has been stopped indeed...any
idea?  This problem does not appear to exist if stopping from the GUI.

				Thanks and really appreciate your help...

				Jindong.

 
###############################################################
This message has been scanned for viruses and other contents.
###############################################################

Re: [Wrapper-user] Wrapper not restarting JVM after NullPointerException

[Andy B. <aba...@ca...>]

I followed the instructions regarding the "wrapper.filter" properties 
at < http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html 
 > and added these to my wrapper.conf:

> wrapper.filter.trigger.1=java.lang.NullPointerException
> wrapper.filter.action.1=RESTART
> wrapper.filter.trigger.2=java.lang.OutOfMemoryError
> wrapper.filter.action.2=RESTART

Now my application is restarted appropriately when a NPE occurs; 
however, I don't think this is a robust enough solution for my 
situation. If my application's main thread dies due to any exception, I 
need the Wrapper to restart it. I don't think I can express that 
completely with wrapper.filter properties.

Do I have other options?

Cheers,
~Andy

On Monday, April 21, 2003, at 11:40  PM, Andy Barnett wrote:

> In my testing on Linux I set up a Java application to throw a 
> NullPointerException. I expected the Java Service Wrapper to restart 
> my Java application, but instead the Wrapper just stops, apparently 
> exiting normally.
>
> Here is the end of my debug log:
>
>> [. . .]
>
> Here is my setup: I have coded a CmtkWrapper class that implements 
> WrapperListener using Integration Method #3 as described on the 
> website. My CmtkWrapper class starts my ChangeManagementToolkit class 
> which extends ReThread which extends the java.lang.Thread class. So 
> essentially I'm throwing a NPE from within the run() method of a 
> java.lang.Thread.
>
> As I said, I expected the Java Service Wrapper to restart my Java 
> application. Am I doing something wrong or am I misunderstanding what 
> the appropriate behavior should be?
>
> ~Cheers,
> Andy

[Wrapper-user] Wrapper not restarting JVM after NullPointerException

[Andy B. <aba...@ca...>]

In my testing on Linux I set up a Java application to throw a  
NullPointerException. I expected the Java Service Wrapper to restart my  
Java application, but instead the Wrapper just stops, apparently  
exiting normally.

Here is the end of my debug log:

> INFO   | jvm 1    | 2003/04/21 23:28:25 |  
> java.lang.NullPointerException: Test Exception!
> INFO   | jvm 1    | 2003/04/21 23:28:25 |       at  
> com.ctech.cmtk.ChangeManagementToolkit.runLoop(ChangeManagementToolkit. 
> java:56)
> INFO   | jvm 1    | 2003/04/21 23:28:25 |       at  
> com.ctech.util.ReThread.run(ReThread.java:160)
> DEBUG  | wrapperp | 2003/04/21 23:28:27 | send a packet 103 : ping
> INFO   | jvm 1    | 2003/04/21 23:28:27 | Received a packet 103 : ping
> INFO   | jvm 1    | 2003/04/21 23:28:27 | Send a packet 103 : ok
> INFO   | jvm 1    | 2003/04/21 23:28:27 | All non-daemon threads have  
> stopped.  Exiting.
> INFO   | jvm 1    | 2003/04/21 23:28:27 | Send a packet 101 : 0
> DEBUG  | wrapperp | 2003/04/21 23:28:27 | read a packet 103 : ok
> DEBUG  | wrapper  | 2003/04/21 23:28:27 | Got ping response from JVM
> DEBUG  | wrapperp | 2003/04/21 23:28:27 | read a packet 101 : 0
> DEBUG  | wrapper  | 2003/04/21 23:28:27 | JVM requested a shutdown. (0)
> DEBUG  | wrapper  | 2003/04/21 23:28:27 | wrapperStopProcess(0) called.
> DEBUG  | wrapper  | 2003/04/21 23:28:27 | Sending stop signal to JVM
> DEBUG  | wrapperp | 2003/04/21 23:28:27 | send a packet 101 : NULL
> INFO   | jvm 1    | 2003/04/21 23:28:28 | Thread, Wrapper-Connection,  
> handling the shutdown process.
> INFO   | jvm 1    | 2003/04/21 23:28:28 | calling listener.stop()
> INFO   | jvm 1    | 2003/04/21 23:28:28 | returned from listener.stop()
> INFO   | jvm 1    | 2003/04/21 23:28:28 | Send a packet 107 : 0
> INFO   | jvm 1    | 2003/04/21 23:28:28 | Closing socket.
> DEBUG  | wrapperp | 2003/04/21 23:28:28 | read a packet 107 : 0
> DEBUG  | wrapper  | 2003/04/21 23:28:28 | JVM signalled that it was  
> stopped.
> DEBUG  | wrapperp | 2003/04/21 23:28:28 | socket read no code  
> (closed?).
> INFO   | jvm 1    | 2003/04/21 23:28:28 | calling System.exit(0)
> DEBUG  | wrapper  | 2003/04/21 23:28:28 | JVM exited normally.
> STATUS | wrapper  | 2003/04/21 23:28:28 | <-- Wrapper Stopped

Here is my setup: I have coded a CmtkWrapper class that implements  
WrapperListener using Integration Method #3 as described on the  
website. My CmtkWrapper class starts my ChangeManagementToolkit class  
which extends ReThread which extends the java.lang.Thread class. So  
essentially I'm throwing a NPE from within the run() method of a  
java.lang.Thread.

As I said, I expected the Java Service Wrapper to restart my Java  
application. Am I doing something wrong or am I misunderstanding what  
the appropriate behavior should be?

~Cheers,
Andy

Re: [Wrapper-user] New UNIX Scripts - Request for feedback.

[Richard E. <rem...@ed...>]

The following shell function converts all of the symbolic links in a 
path into their "real" directories:


#
# remove all links
#
resolve_path() {
     declare path=$1
     declare l=`echo $path | sed -e 's;/; ;g'`

     declare rpath=

     for c in $l; do
         rpath=$rpath/$c
         while [ -h "$rpath" ] ; do
             ls=`ls -ld "$rpath"`
             link=`expr "$ls" : '.*-> \(.*\)$'`
             if expr "$link" : '/.*' > /dev/null; then
                 rpath="$link"
             else
                 rpath=`dirname "$rpath"`"/$link"
             fi
         done
     done

     echo $rpath
}

# ant is a symbolic link
path=/home/emberson/java/jakarta/ant/lib
echo $path

path=`resolve_path $path`
echo $path
# this echos "/home/emberson/java/jakarta/apache-ant-1.5.3-1/lib"


Richard

Re: [Wrapper-user] Repost: shutdown problem

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

Jim
    Sorry for the slow response.  I just got back from a few days vacation.
While looking into your problem, I discovered some problems with the
current scripts when they are referenced as symbolic links.

    I started a new thread in which I posted a new set of scripts which go
a little ways towards answering your questions.  Please read over that
other email as it describes the current problems in more detail.

    Hopefully I will get everything worked out to be able to directly answer
your question fairly soon.

Cheers,
Leif

[Wrapper-user] New UNIX Scripts - Request for feedback.

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

The bash and sh scripts which have been released with the Wrapper up until
this point were written by another of the founding members of the project.
Historically, I have been mainly focussed on the Windows side but over the
last year have been taking over the management of all platforms.

While looking into Jim's recent problems getting the wrapper scripts to work
on system startup and shutdown. I found that they did not seem to be
working when referenced as symbolic links.

As I had understood it, the purpose of using the realpath binary, included
with the wrapper, was to work around this problem. But the problem is
that as is, the scripts are not able to locate the realpath binary when
referenced as a symbolic link. This is because the scripts were looking
in the directory containing the script. But in the case of symbolic links,
this location resolves to the location of the symbolic link, rather than
that of the script itself. Kind of a chicken and the egg problem!!

Anyway. I reworked the initialization of these scripts to test whether or
not the script is being referenced directly or via a symbolic link.

In the case of direct a reference, the directory of the script can be
resolved using `dirname $0` and so realpath is no longer needed or used.

However, when the script is referenced as a symbolic link, `dirname $0`
will return the location of the symlink and not the script so realpath is
needed. The scripts I am including for you to look over, look for the
realpath command on the path. If it is not available, then the user is
asked to copy it to the /usr/bin directory. (Is this the best choice)

I would really like to be able to have the script locate the realpath binary
in the same directory as the script. But if that was possible then I would
not need the realpath binary in the first place. Like I said, "Chicken and
the egg problem."

One possibility would be to try and parse the output of `ls -al $0` as it
always includes the target of the symbolic link, which is the location that
is provided by realpath. Unfortunately, my script skills are lacking, so
I would appreciate any help in getting that working.

Any other feedback on these scripts would also be appreciated.

Once these new scripts are finalized, I am hoping to get a section written
up on how to install the scripts on the various platforms so that the
Wrapper will be started and stopped cleanly when the system is started
up and shutdown. The only UNIX systems that I am able to actually
reboot for testing are Debian Linux systems. So I will need some info
from Red Hat, Solaris, HP-UX. AIX and Max OS X users about the
procedures involved.

Thanks in advance.
Cheers,
Leif

Re: [Wrapper-user] Wrapper problems

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

Jeff Howden wrote:

>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>>In any case, you should be able to see what the problem
>>is by looking at the wrapper.log file.
>><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
>>    
>>
>
>Here's the entire dump of log data that's generated when I start the
>service.
>
>STATUS | wrapper  | 2003/04/20 16:53:29 | --> Wrapper Started as Service
>STATUS | wrapper  | 2003/04/20 16:53:30 | Launching a JVM...
>INFO   | jvm 1    | 2003/04/20 16:53:30 | Wrapper (Version 3.0.2)
>INFO   | jvm 1    | 2003/04/20 16:53:30 |
>INFO   | jvm 1    | 2003/04/20 16:53:30 | Starting client...
>
If it gets to this point and then never times out then your application 
is most
likely running as far as the Wrapper is concerned.  Could you post the log
file again with wrapper.logfile.loglevel=DEBUG set?  That kicks out more
useful information and will usually help to pin down exactly what is
happening.  Also attach your wrapper.conf file.

>The weird thing is that jar file (status.jar) is definitely being used by
>the wrapper cause the file is locked, preventing me from overwriting,
>renaming, or deleting it.
>
That means that the JVM has opened and is using the status.jar file.  This
will happen even when not using the Wrapper.

>  However, it's web interface doesn't come up as
>expected (it basically listens on a specified port and acts as a
>mini-webserver) when requested in the same manner used when the jar file is
>executed manually.  I check netstat to see what ports the machine is
>listening on and don't see the port the jar file is configured to listen on.
>
It sounds like you are using an executable Jar?  With the Wrapper and the
WrapperSimpleApp helper class, you have to specify the main class from
the jar's manifest as the first argument passed to the WrapperSimpleApp.
If you have configured this incorrectly then there should be no difference
between running in console mode and as a service however.

>I have a sneaking suspicion that the jar file isn't initializing properly
>called as a service by the wrapper, but don't know enough about Java to
>figure out how to isolate and fix it.  The few things I do know are that
>when calling the test batch file (status.bat) it goes through the wrapper
>initialization sequence and then opens up a Java GUI (spawned by status.jar,
>the jar file I'm trying to run as a service).  The console stays open until
>I close the Java GUI.  If I execute status.jar manually then the GUI doesn't
>come up the first time.  In order to get the GUI to open I have to have the
>jar file running and then manually execute it again (by double-clicking it).
>I'm wondering if maybe the GUI opening when using the test batch file
>(status.bat) and starting it as a service are at all related.
>
 From what I read here, it sounds like your application is acting a bit
strangely even without the Wrapper.  The debug info above should be able
to peg or rule out the Wrapper as the cause however.

Cheers,
Leif