> 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.
Did you try the TC 4.0b6 installer for Windows too ?
Maybe bugs were fixed since when you tried it. I didn't get any reports of
problems on that yet, and it's working cool for me.
> 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.
You have to tick an option in the installer, and you're done.
Could you at least try it before posting that ?
> 3. JNI, by definition, has to use native code anyway. With TomcatService
> we have more of the native code under "our control".
I want GOOD system integration; that means I want Tomcat to look like a
native process, and to behave like a native process.
I'm eating my dog food and I've been running it on my laptop ever since I've
added it to the installer. Except the shutdown timeout (which is our fault),
it's been working without any single problem.
> 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.
How do you solve the problem where any local user would be able to shutdown
Tomcat ?
JNI is an elegant solution which allows to get rid of the custom (and
insecure) Tomcat shutdown mechanism.
> 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.
It doesn't get the job done.
I think TomcatService is nice, and in the past it was probably better than
buggy JavaService. However, I started testing 2 weeks ago, and the problems
with JavaService you describe are apparently gone.
So I cast my vote on JavaService.
Remy
