> "Patrick Luby" <[EMAIL PROTECTED]> wrote:
>
> > Maybe I should clarify what I am trying to do. I am trying to enable the
use
> > of setuid() within the existing Tomcat startup process (i.e. shell
scripts). I
> > definitely like your native launcher and the more I look at it, the more
I
> > like its sophisticated function. I just want to make the setuid() call
> > available even if I haven't startup Tomcat using your native launcher.
The way
> > to do that is to use the Java->JNI method of creating a shared library
that
> > contains a function with a name that matches a demangled version of a
"public
> > native" Java method. Then, when Tomcat is started via a script (as it
does
> > now), the StandardServer class can do the following:
> >
> > - Invoke System.loadLibrary()
> > - Bind all of the ports (if you are root, you can bind to ports <= 1024)
> > - If we are root, invoke a "public native" method that Java maps to the
C
> > function contained in the shared library. The C function would contain
> > the setuid() C call to change the Java process to a non-root user
>
> Hmm... I don't like it, but now I got what you're trying to do...
>
> > The above method effectively does the same thing as your native
launcher. The
> > only difference is that I thought it might be a may to get your setuid
code
> > into the standard Tomcat installations
>
> The only code working is within Tomcat, and it's there already... Look at
> the API changes in the Connector I pointed out yesterday, and at the
> different Embedded solutions (like the one Remy did for Win32 services)...
> The java code is there, the entry points are all there... All we need is a
> JNI wrapper/invocator which loads the VM, calls initialize(), sets the
> UID/GID, calls(start), wait for a signal, calls stop()...
>
> > much sooner since my proposed approach
> > is compatible with the existing Tomcat configuration and startup.
>
> Given that I don't even have time to blow my nose ATM, I won't argue on
> implementation, but just comment on the idea... Calling setuid() from Java
> is crap (design wise), because it's against all design principles Java is
> based on... It's not portable, and there is already a much better
> alternative that is completely platform independant... Someone just needs
to
> make it work (I'd give a one-week time to a guy like you to make it run :)
I agree with Pier here. I think we should only try to implement daemon
fnctionality using the appropriate wrapper. Implmenting it with standard
Tomcat using scripts is a nasty hack.
Somehow, Patrick doesn't seem to like my BootstrapService (which works
perfectly well; it's even been in use for a long time through the NT service
which ships with the Windows installer) :-(
> As I said, I'm more on the approach I outlined several times here and on
the
> JSR-096 mailing list my preferred approach to the problem is to create a
> wrapper around the Java Virtual Machine and an API defining the lifecycle
of
> a Daemon process...
>
> Not in many details, the API I would love to see is (at the end) something
> like:
>
> public interface Daemon extends Runnable {
> public void init(...);
> public void destroy();
> }
>
> Init() can be called as root if the process is started as root, otherwise,
> it gets called at whoever, after init() returns cleanly, the main thread
> starts sleeping and waiting for signals, a new thread is created and this
> calls the run() method in Daemon (extends runnable!)...
>
> To stop the whole kid, the destroy() method is called by the main thread
> after this receives a signal. The destroy method implementation will stop
> the thread in run(), clean all it has to clean, and return.
>
> When the thread going in run() returns, we simply call our exit() and
> terminate the JVM process....
>
> IMO, this is the most portable thing, and design wise is kinda cool, as we
> "extend" the idea of a Runnable which is an object associated with a
thread.
> A process is nothing else that a thread of execution associated with some
> memory, so, there's quite a nice parallel....
>
> People might like it, people might not... Since I don't have time ATM ,
it's
> up to you folks...
Question: How is JSR 96 doing ? Did you leave the EG because the lead is
impossible to work with ? What I mean is: is there still hope that the final
spec is decent ?
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
