On Fri, 7 Dec 2001 18:03, Leif Mortenson wrote:
> I manage a SourceForge project, http://wrapper.sourceforge.net , that
> does this. It currently has 2.2.2 released, but the changes I have made
> to get it working with Phoenix are still being finalized. Release 2.2.3
> with those changes should be up in a few days. I will post again when
> it is.
I just downloaded it and it is great! I adapted the classes as you suggested
and added a simple object that implements WrapperListener. It works great!
> Threw way the Wrapper works is that it actually has a class WrapperManager
> that is loaded into the JVM and actually launches the application.
> Currently,
> Phoenix is being launched and controlled as a generic application
> because I am
> relying on Phoenix's ShutdownHook to shut things down cleanly.
> The Wrapper also provides an Interface, WrapperListener, which provides 3
> service control methods, used to allow the application to respond to start,
> stop, and system signals. If Phoenix had a shutdown method that it
> could access,
> then I could call that directly from the stop method. That should be
> more secure
> than having a TCP connection waiting for connections.
done ! ;)
> The WrapperManager also includes commands which allow the application to
> request that it be shutdown or even that its JVM be restarted. That goes
> against the model that a Component should not control its own life
> cycle, but
> it can be useful for servers. (Or maybe it is Ok, since the Component
> is not
> actually stopping itself, but just making a request to its Container
> that it be
> stopped)
Thats definetly something we want to support. I will definetly look into this.
> I would like to propose that the shutdown() method be made public rather
> than
> private. This will not cause any security problems because there is no
> way for
> any evil classes to get a hold of the CLIMain instance. Currently, its
> only
> references are in the ShutdownHook and in the Main class which created it.
yep.
> If the Main class could call the shutdown() hook using reflection, then my
> problems would be solved. I have written my own Wrapper friendly version
> of the Main class in the launcher package and it all works beautifully with
> Wrapper 2.2.3 and the changes to CLIMain described below.
excellent.
> To make this work correctly, the shutdown() method would also have to
> deregister the shutdown hook when it was called.
I actually didn't do this as some JVMs will die a horrible death if you try
to deregister a shutdown hook after any of shutdown hooks have started.
However I nulled out m_hook and if it is null we skip it during
forcedShutdown()
> I also found it necessary to change the following line of code in the
> CLIMain
> main method.
> ---
> final CLIMain main = new CLIMain();
> ---
> to
> ---
> final CLIMain main = this;
> ---
> What is the reason for creating another instance. The original instance
> can not be obtained by anyone other than the creating class Main. So I
> don't see
> why the extra security is required.
> (if this change is made, then the main method can be simplified)
Yes - I am a complete fool ;) Originally main() method was static but we had
to make it an instance at one stage to force classes to be loaded and
resolved. Of course I forgot to fix this ;)
> I don't believe that any of these changes open up any security holes in
> Phoenix.
> Could you take a look at it and let me know if you see any problems.
Works good !
I haven't fully integrated the config files/dir layout into distribution just
yet. I will try to do that in a bit. However there was a few things I noticed
that I would like to see addressed in a future version of wrapper if possible
;)
Would it be possible to have debugging levels for the native code. As I spent
a while debugging something in the config files (a stupid typo). However if I
had been able to turn on debugging and see the command line produced by the
program I would have figured it out straight away. As it was I went in and
littered your code with debugging output ;)
Could you also add something like
<fixcrlf srcdir="${bin.dist.dir}" includes="**/*.bat" eol="crlf" />
<fixcrlf srcdir="${bin.dist.dir}" includes="**/*.sh" eol="lf" />
to your build file. As the distributions on the website have windows line
endings in all the unix commands and thus they fail. It would also be nice to
make all the shell scripts executable in the tar file by doing something like
<tar longfile="gnu" tarfile="${dist.base}/${dist.name}-bin.tar">
<tarfileset dir="${dist.name}/.." mode="755"> <!-- notice mode here -->
<include name="${dist.name}/**/*.sh"/>
</tarfileset>
<tarfileset dir="${dist.name}/..">
<exclude name="${dist.name}/**/*.sh"/>
</tarfileset>
</tar>
It would also be useful to not have to place some variables into the config
file such as the java command. Instead they could be passed in while starting
up wrapper?
Also if you don't specify a config file it may be useful to not do any
logging at all. I couldn't figure out if there was a way to turn off logging?
Also it would be great to be able to remove the prefix from the logging
output via a command line option or something ;)
--
Cheers,
Pete
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
