avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Propper way to shut down avalon.
Date Sat, 15 Dec 2001 22:43:04 GMT
On Mon, 10 Dec 2001 22:03, Leif Mortenson wrote:
> Ok, here we go. :-)


> In the wrapper.conf, file, you have added all of the Phoenix jar files
> to the classpath.  You don't need this because Phoenix finds and loads
> all of the classes in the lib directory when it is running.  You only
> need the following:
>     wrapper.java.classpath.1=phoenix-loader.jar
>     wrapper.java.classpath.2=wrapper.jar


> I saw that you had the following line in the wrapper.conf file:
>     #wrapper.java.additional.1=-Dwrapper.debug=true
> That will work, but the way we had designed it was to use the
> wrapper.debug property in wrapper.conf to toggle this. :-)

yep ;)

> The run.bat script currently sets the following 4 parameters when it
> launches Java.  Currently if I set all four then I get security
> violations.  I am not sure if this is because I am doing something
> wrong.  But if you need to have these set, then that would be done in
> wrapper.conf as follows.
>     # Java Additional Parameters
>     wrapper.java.additional.1=-Djava.ext.dirs=..\lib
>     wrapper.java.additional.2=-Dphoenix.home=..
> #wrapper.java.additional.3=-Djava.security.policy=jar:file:../bin/wrapper-l
> #wrapper.java.additional.4=-Djava.security.manager

applied. Can you tell me if the CVS version works for you (it works fine on 

> For the DaemonLauncher, I am sending you the version that I had written.
>  It was coded so that it treats class loaders etc exactly like the Main
> class does.  It also handles error cases while starting much better.
>  This version does not use an ActionListener.  But it does set the
> thread's class loader like Main does.
> This version also kicks out debug information when wrapper.debug is
> enabled.
> Could you give this version a try and see how you like it.

I integrated parts of it and will do a bit more integration soon but I would 
prefer to keep most of the code in Main.java so that it is easier to maintain 
in the future.

> We were also talking about how to implement the change user feature that
> you(?) requested.  It should be easy to do, but the user really needs to
> be set after the application, in this case Phoenix, is completely up and
> running.  The problem is that because CLIMain.main never returns, there
> is currently no way to tell whether Phoenix has completed its startup or
> not.
> There are 4 ways we can make this work.
> One is for CLIMain.main to return when setup is complete.  (Hard to do?)

Okay I did this sorta. An extra parameter is passed to main() in the 
frontend. This parameter is a boolean that indicates whether the frontend 
should block or be non-blocking. So if you run it from the run.sh script it 
will be blocking while if it is run from the DaeomonLauncher it will block.

> In the ant.properties.sample file, could you please change the wrapper
> definitions to the following:
> # ----- Java Service Wrapper, version 2.2.3 or later -----
> #wrapper.home=${base.path}/wrapper_linux_2.2.3
> #wrapper.jar=${wrapper.home}/lib/wrapper.jar
> # Linux/Solaris
> #wrapper.exe=${wrapper.home}/bin/wrapper
> #wrapper.dll=${wrapper.home}/lib/libwrapper.so
> # Windows
> #wrapper.exe=${wrapper.home}/bin/Wrapper.exe
> #wrapper.dll=${wrapper.home}/lib/Wrapper.dll
> We cleaned up several things.  Including the locations of the libraries
> in 2.2.3.  As well as fixed lots of bugs.


> One more thing, is about the scripts used to launch Phoenix using the
> wrapper.  It doesn't look like they are being included in the
> wrapper-dist build right now.  It is fairly easy to start and stop the
> windows version without a batch file, but the scripts for the unix
> versions provide the ability to start and stop them without having to
> hit CTRL-C.  Useful for when you want to install Phoenix as a daemon on
> the system.
> It doesn't look like there is any plaform specific code in the current
> build.xml, but it is fairly easy to add checks for the platform so that
> the correct scripts are copied into the dist/bin directory for each
> platform.

will look at that next.



 These aren't the droids you're 
 looking for. Move along. 

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message