I'm speaking here with very limited experience with projects like this
and the only JNI code I have written has been to verify NDS names and
passwords and enumerate users in an NDS Group object. And, I haven't
looked at the JavaService code yet. So, take all this with a grain of
salt.

I'm sure that the JavaService code is precious and a work of art and
definitely needs to be continued. No question.

However,

1. I tried my damndest and couldn't get the JavaService to work with
Tomcat on an NT server that I have.
I tried javaserv, srvyany, etc. Nothing worked for me. *Very very
frustrating*, and I can usually figure out just about anything. That is
why I wrote the TomcatService program. I, from an Apache/Tomcat user's
point of view, just want Tomcat to work. Period. Tomcat is what I need.
Tomcat should be the focus, NOT installing it and getting it to run.

2. The beauty of TomcatService is that it is very simple and
fundamentally generic. (It is true that it could and probably will help
quite a few other projects too.) And, the first thing for users to do is
just get the Tomcat startup.bat and shutdown.bat files to work. After
that, there is hardly anything else that needs to be done or could go
wrong (knock on wood). Getting Tomcat to work quickly and easily is the
important thing here. That's what the vast majority of the users care
about. Let's not make the installation so difficult that people blame it
on Tomcat and dump it for something else.

3. JNI, by definition, has to use native code anyway. With TomcatService
we have more of the native code under "our control".

4. I think it would ruin the simplicity, power, generic nature, and
usefulness of the TomcatService code if we start dumping in the *much
more complex* JNI code.

5. Most of the less experienced (but the vast majority) of programmers
are going to naturally drift toward the simpler code, and the more
people the code can help, the better. The simpler the code the better.

I suppose my vote would be to keep them separate (JavaService and
TomcatService), but mix them freely in a third program when a "natural"
and practical usefulness for their marriage becomes obvious. I don't see
that right now, but perhaps, you all can see farther down the road than
I can.

With best wishes and intentions for both programs,

Joe
//-------------------

> Pier P. Fumagalli" wrote:
> 
> Kevin Seguin at [EMAIL PROTECTED] wrote:
> 
> >>> ME BIG DOPE :) :) :) There are TWO Win32 Service
> >> implementations... I
> >>> thought Joe and Elijah were working on the same code :) :)
> >> :) But THEY'RE
> >>> NOT! (Sometimes I'm just so fuckin' stupid! :)
> >>>
> >>> On a very rough analysis, Elijah's JavaService is better as
> >> it uses JNI,
> >> but
> >>> on the other hand, Joe's TomcatService is better because
> >> the sources are
> >> way
> >>> simpler, even though it uses the batch files...
> >>
> >> Ok, but JavaService looks perfect to me :
> >> - Uses JNI indeed
> >> - Service installation / removal works great
> >> - Pipes the out and the err of the JVM process into logs files in
> >> CATALINA_HOME/logs (good)
> >> - Logs stop / start / trouble to the NT event log
> >> - Very generic
> >>
> >
> > fwiw, i agree with remy.  i took a (quick) look at JavaService, and it seems
> > to be ideal.
> 
> Ok, wanna help out to integrate the whole kit'n kaboodle with the Service
> code we have?
> 
>     Pier
> 
> BTW, I can't move the code until Henri removes his -1....

Reply via email to