RE: Separating Service code from Tomcat 4.0
GOMEZ Henri at [EMAIL PROTECTED] wrote: I'm +1 for jakarta-service and -1 for jakarta-tomcat-service Still of this idea? I can't open jakarta-service as I have to get down to the PMC to do it, and I'd like to commit some code... Thanks... Argh, if you need the PMC agreement, it will delay that piece of code too much. Let's go with jakarta-tomcat-service for now. +1 for jakarta-service
Re: Separating Service code from Tomcat 4.0
GOMEZ Henri at [EMAIL PROTECTED] wrote: GOMEZ Henri at [EMAIL PROTECTED] wrote: I'm +1 for jakarta-service and -1 for jakarta-tomcat-service Still of this idea? I can't open jakarta-service as I have to get down to the PMC to do it, and I'd like to commit some code... Thanks... Argh, if you need the PMC agreement, it will delay that piece of code too much. Let's go with jakarta-tomcat-service for now. +1 for jakarta-service When the code is in a better shape, and closer to a release. Thanks Pier
RE: Separating Service code from Tomcat 4.0
I'm +1 for jakarta-service and -1 for jakarta-tomcat-service Still of this idea? I can't open jakarta-service as I have to get down to the PMC to do it, and I'd like to commit some code... Thanks... Argh, if you need the PMC agreement, it will delay that piece of code too much. Let's go with jakarta-tomcat-service for now. +1 for jakarta-service When the code is in a better shape, and closer to a release. Thanks You've corrected : +1 for jakarta-tomcat-service
Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Hi Joe et al, Joe Flowers wrote: [snip cogent words about running TC as a service] I agree with you 100% WRT the difficulty of getting JavaService to work -- a sysadmin here pulled most of his few remaining hairs one day trying to get it working, so while I haven't personally looked at it I can well sympathize. For the Domino connector I took a slightly different approach: the Domino connector can optionally be configured to start Tomcat when it loads. This has a number of benefits including * simplified installation * assurance that Tomcat starts and stops at the right time relative to the web server's lifecycle * conceptually portable By conceptually portable I mean that while the code in the connector to implement Tomcat startup and shutdown isn't the same for all platforms the concept of running Tomcat in that way is -- you can safely assume that whatever the platform the admin has already arranged for the web server to start automatically if that's what they want, and the arrangements for starting Tomcat at the same time are essentially the same across all platforms. It would be easy enough to add the same functionality to the other connectors. This is a simple solution for all platforms in all cases except the one where you want to have Tomcat autostart in stand-alone mode, and I would assume that that's a relatively rare requirement. If there's interest I can investigate adding the same functionality to the other connectors. -- Andy Armstrong, Tagish
RE: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Hi Joe et al, Joe Flowers wrote: [snip cogent words about running TC as a service] I agree with you 100% WRT the difficulty of getting JavaService to work -- a sysadmin here pulled most of his few remaining hairs one day trying to get it working, so while I haven't personally looked at it I can well sympathize. For the Domino connector I took a slightly different approach: the Domino connector can optionally be configured to start Tomcat when it loads. This has a number of benefits including * simplified installation * assurance that Tomcat starts and stops at the right time relative to the web server's lifecycle * conceptually portable By conceptually portable I mean that while the code in the connector to implement Tomcat startup and shutdown isn't the same for all platforms the concept of running Tomcat in that way is -- you can safely assume that whatever the platform the admin has already arranged for the web server to start automatically if that's what they want, and the arrangements for starting Tomcat at the same time are essentially the same across all platforms. Good things, that's the way ApacheJServ was working. That's a case of use (the connector start the Tomcat) where a JavaService should fit well in jakarta-tomcat-connectors, may be a version simpler that the 'more general java-services' It would be easy enough to add the same functionality to the other connectors. +1 This is a simple solution for all platforms in all cases except the one where you want to have Tomcat autostart in stand-alone mode, and I would assume that that's a relatively rare requirement. No so rare since many sites use a farm a Tomcat behind their web-server (using mod_jk load-balancing features) If there's interest I can investigate adding the same functionality to the other connectors. I'd like to see it on Apache at least. Could it be shared (or replace) the jk_service allready present in jtc/jk/native ?
RE: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Not a safe assumption. My company is using Tomcat in standalone mode within a large project. -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] [snip] It would be easy enough to add the same functionality to the other connectors. This is a simple solution for all platforms in all cases except the one where you want to have Tomcat autostart in stand-alone mode, and I would assume that that's a relatively rare requirement. If there's interest I can investigate adding the same functionality to the other connectors. -- Andy Armstrong, Tagish
Re: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Twiggs, Glenn at [EMAIL PROTECTED] wrote: Not a safe assumption. My company is using Tomcat in standalone mode within a large project. I believe he's talking about when tomcat is ran standalone AND thru a connector... Pier
RE: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Yes. With a patch applied to avoid the NT Logout snafu that causes the VM to shutdown. Glenn. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] One question - is anyone using the jk_service ( the NT service starter that is included with tomcat3.x ) ? Costin
Re: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
GOMEZ Henri wrote: [snip] This is a simple solution for all platforms in all cases except the one where you want to have Tomcat autostart in stand-alone mode, and I would assume that that's a relatively rare requirement. No so rare since many sites use a farm a Tomcat behind their web-server (using mod_jk load-balancing features) Ah yes -- I forgot about that. If there's interest I can investigate adding the same functionality to the other connectors. I'd like to see it on Apache at least. Could it be shared (or replace) the jk_service allready present in jtc/jk/native ? I'd have thought so -- I'll have a look. -- Andy Armstrong, Tagish
Re: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Quoting Andy Armstrong [EMAIL PROTECTED]: Hi Joe et al, Joe Flowers wrote: [snip cogent words about running TC as a service] I agree with you 100% WRT the difficulty of getting JavaService to work -- a sysadmin here pulled most of his few remaining hairs one day trying to get it working, so while I haven't personally looked at it I can well sympathize. Yes, I can also confirm it's extremely hard to do too. One time, I forgot to check the NT Service check box in the installer, and it failed to install !!! ;-) So the bottom line is : give it another try using the installer (and keep your hair :) ). Maybe bugs were fixed or something like that. Remy
Re: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Remy Maucherat wrote: Quoting Andy Armstrong [EMAIL PROTECTED]: Hi Joe et al, Joe Flowers wrote: [snip cogent words about running TC as a service] I agree with you 100% WRT the difficulty of getting JavaService to work -- a sysadmin here pulled most of his few remaining hairs one day trying to get it working, so while I haven't personally looked at it I can well sympathize. Yes, I can also confirm it's extremely hard to do too. One time, I forgot to check the NT Service check box in the installer, and it failed to install !!! ;-) So the bottom line is : give it another try using the installer (and keep your hair :) ). Maybe bugs were fixed or something like that. It wasn't my hair -- I don't have any any more ;-) -- Andy Armstrong, Tagish
Re: Separating Service code from Tomcat 4.0
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 Remy
Re: Separating Service code from Tomcat 4.0
[X] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments: There are: jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_service.c jakarta-tomcat-connectors/jk/native/nt_service/jk_nt_service.c jakarta-tomcat-4.0/service Do I miss something? Cheers Jean-frederic PS: For m$ nt I had some old code to run a console application as a service (Probably useless but if someone is interested I could ask if it could be donated).
Re: Separating Service code from Tomcat 4.0
Pier P. Fumagalli wrote: Pier P. Fumagalli at [EMAIL PROTECTED] wrote: I'd say, let's stick it with Tomcat until we don't have a proof-of-concept that it works, and then we can decide... I like jakarta-tomcat-service. Request-for-vote: Can I go ahead and open the new CVS repo? Pier Print and detach the following portion, then mail it over to me at: Pier Somewhere in London United Kingdom And don't forget to put a STAMP :) --- [ ] +1 - Do it, and I can help [X] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments: -- Andy Armstrong, Tagish
RE: Separating Service code from Tomcat 4.0
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.
Re: Separating Service code from Tomcat 4.0
jean-frederic clere at [EMAIL PROTECTED] wrote: [X] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments: There are: jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_service.c jakarta-tomcat-connectors/jk/native/nt_service/jk_nt_service.c jakarta-tomcat-4.0/service Do I miss something? Yes, the first two are _completely_ different from the third. Service doesn't even touch windows, now... Pier
Re: Separating Service code from Tomcat 4.0
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
RE: Separating Service code from Tomcat 4.0
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? cheeky ;) but seriously, i'd love to. very low on spare time, tho, so i wouldn't be able to make any guarantees :)
Re: Separating Service code from Tomcat 4.0
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
Re: Separating Service code from Tomcat 4.0
[ ] +1 - Do it, and I can help [X] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments: If we do so ( create the service workspace ), can we also check in the existing service ( the one that was used in the last year or so for tomcat 3.3 ) ? It has the benefit that it works with JDK1.1 ( or anything else, as it's using exec instead of jni ) ( it needs a bit of customization, i.e. replace few #defines, to start anything ). We also need to update the documentations of jk_service, to mention that we now have 2 service starters to choose from. Costin
Re: Separating Service code from Tomcat 4.0
On Wednesday July 25, 2001 Remy Maucherat wrote: 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. I'm also curious as to what specifically would not work for you. A lot of people have downloaded JavaService and I don't recall anyone who I was not able help at least get the service working. If there is some problem, I would like to get it fixed so that I don't encounter it someday myself. 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. This is one of the reasons I wrote with JNI in the first place. I wanted the process to show up as tomcat.exe not as java.exe in the task manager. When you've got four or five Java based services running and they all are simply listed as java.exe it's a pain to figure out what going on sometimes. Also, I didn't really want to have to start a whole seperate JVM to stop a service using a socket, I would rather have a seperate call made into the existing JVM to limit memory and cpu use. If you decide to include JavaSerive as part of Tomcat I'd be willing to help with any changes that are necessary to use it. Elijah Roberts
Re: Separating Service code from Tomcat 4.0
Elijah Roberts at [EMAIL PROTECTED] wrote: On Wednesday July 25, 2001 Remy Maucherat wrote: I want GOOD system integration; that means I want Tomcat to look like a native process, and to behave like a native process. This is one of the reasons I wrote with JNI in the first place. I wanted the process to show up as tomcat.exe not as java.exe in the task manager. When you've got four or five Java based services running and they all are simply listed as java.exe it's a pain to figure out what going on sometimes. Also, I didn't really want to have to start a whole seperate JVM to stop a service using a socket, I would rather have a seperate call made into the existing JVM to limit memory and cpu use. If you decide to include JavaSerive as part of Tomcat I'd be willing to help with any changes that are necessary to use it. Yes. I am definitely _EAGER_ to include JavaService with my Service code, and distribute it all together with Tomcat 4.0 (from the next beta). A couple of changes are needed for your code to be integrated with my current Service, as you use static methods in classes, while my Service is an interface which needs to be implemented... And I have a two-step initialization process, since under Unix we can use the first one (load) to bind to ports 1024 while running as root, and start() gets called after the user has been downgraded. Pier
Re: Separating Service code from Tomcat 4.0
On Wednesday July 25, 2001 Pier P. Fumagalli wrote: Yes. I am definitely _EAGER_ to include JavaService with my Service code, and distribute it all together with Tomcat 4.0 (from the next beta). A couple of changes are needed for your code to be integrated with my current Service, as you use static methods in classes, while my Service is an interface which needs to be implemented... And I have a two-step initialization process, since under Unix we can use the first one (load) to bind to ports 1024 while running as root, and start() gets called after the user has been downgraded. I see. So instead of calling a static method, the service would need to create an object and then call the load method followed by the start method? I suppose I should look at your code. Where you planning on integrating the NT portion into the same set of source files or having a seperate set? Elijah Roberts
Re: Separating Service code from Tomcat 4.0
GOMEZ Henri at [EMAIL PROTECTED] wrote: I'm +1 for jakarta-service and -1 for jakarta-tomcat-service Still of this idea? I can't open jakarta-service as I have to get down to the PMC to do it, and I'd like to commit some code... Thanks... Pier
Separating Service code from Tomcat 4.0
Since it can be used by different projects (not only Tomcat), I wanted to separate the Service code into a new CVS repository (jakarta-service). How about it? Pier
Re: Separating Service code from Tomcat 4.0
On Tue, 24 Jul 2001, Pier P. Fumagalli wrote: Since it can be used by different projects (not only Tomcat), I wanted to separate the Service code into a new CVS repository (jakarta-service). How about it? Under the management of which subproject? How about putting it in commons, if it's really as general purpose as it sounds? Pier Craig
Re: Separating Service code from Tomcat 4.0
Pier P. Fumagalli wrote: Since it can be used by different projects (not only Tomcat), I wanted to separate the Service code into a new CVS repository (jakarta-service). How about it? +1 Pier
Re: Separating Service code from Tomcat 4.0
On Tue, 24 Jul 2001, jean-frederic clere wrote: Pier P. Fumagalli wrote: Craig R. McClanahan at [EMAIL PROTECTED] wrote: On Tue, 24 Jul 2001, Pier P. Fumagalli wrote: Since it can be used by different projects (not only Tomcat), I wanted to separate the Service code into a new CVS repository (jakarta-service). How about it? Under the management of which subproject? For now, still Tomcat... My only concern is that also the build process isn't integrated, as most of it is Java code, while Service is native... How about putting it in commons, if it's really as general purpose as it sounds? Dunno, I don't know that much about commons to really say... From what I know, also commons is 100% Java... So far, commons is 100% Java, but I don't believe they (really we, cause I'm a committer there :-) would be opposed to a commonly useful project that has native code components. jakarta-tomcat-connectors is a place where C and Java are mixed ;-) What about jakarta-tomcat-connectors/service? Except for the fact that it's not a connector, and has nothing really to do with Tomcat :-) If we stay under Tomcat auspices, I'd vote for jakarta-tomcat-service instead. Pier Craig
Re: Separating Service code from Tomcat 4.0
Craig R. McClanahan at [EMAIL PROTECTED] wrote: So far, commons is 100% Java, but I don't believe they (really we, cause I'm a committer there :-) would be opposed to a commonly useful project that has native code components. Dunno... jakarta-tomcat-connectors is a place where C and Java are mixed ;-) What about jakarta-tomcat-connectors/service? Except for the fact that it's not a connector, and has nothing really to do with Tomcat :-) Exactly... If we stay under Tomcat auspices, I'd vote for jakarta-tomcat-service instead. I'd say, let's stick it with Tomcat until we don't have a proof-of-concept that it works, and then we can decide... I like jakarta-tomcat-service. Pier
Re: Separating Service code from Tomcat 4.0
Pier P. Fumagalli at [EMAIL PROTECTED] wrote: I'd say, let's stick it with Tomcat until we don't have a proof-of-concept that it works, and then we can decide... I like jakarta-tomcat-service. Request-for-vote: Can I go ahead and open the new CVS repo? Pier Print and detach the following portion, then mail it over to me at: Pier Somewhere in London United Kingdom And don't forget to put a STAMP :) --- [ ] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments:
Re: Separating Service code from Tomcat 4.0
On Tue, 24 Jul 2001, Pier P. Fumagalli wrote: Pier P. Fumagalli at [EMAIL PROTECTED] wrote: I'd say, let's stick it with Tomcat until we don't have a proof-of-concept that it works, and then we can decide... I like jakarta-tomcat-service. Request-for-vote: Can I go ahead and open the new CVS repo? Pier Print and detach the following portion, then mail it over to me at: Pier Somewhere in London United Kingdom And don't forget to put a STAMP :) --- [X] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments: Craig
Re: Separating Service code from Tomcat 4.0
[ ] +1 - Do it, and I can help [X] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments: Haven't even looked at it but I trust Pier :-) Mike Anderson
Re: Separating Service code from Tomcat 4.0
[ ] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [X] -0 - Do it, even if that would make the build process (even) more complex. [ ] -1 - Don't do it, because Remy
Re: Separating Service code from Tomcat 4.0
Remy Maucherat at [EMAIL PROTECTED] wrote: Do it, even if that would make the build process (even) more complex. I believe this can be achieved by simply copying the few interfaces over to jakarta-tomcat-4.0. Once those have been defined, they shouldn't change. While the actual big work is on the C code, which is the real thing we want to develop... And that part is completely separated from Tomcat, and its build process... Pier
Re: Separating Service code from Tomcat 4.0
Pier P. Fumagalli wrote: Pier P. Fumagalli at [EMAIL PROTECTED] wrote: I'd say, let's stick it with Tomcat until we don't have a proof-of-concept that it works, and then we can decide... I like jakarta-tomcat-service. Request-for-vote: Can I go ahead and open the new CVS repo? Pier Print and detach the following portion, then mail it over to me at: Pier Somewhere in London United Kingdom And don't forget to put a STAMP :) --- [X] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [X] -0 - Do it, even ifI hate MS. [ ] -1 - Don't do it, because My comments: Assuming you're talking about the NT/2000 service codes. Joe //
RE: Separating Service code from Tomcat 4.0
Pier P. Fumagalli wrote: Since it can be used by different projects (not only Tomcat), I wanted to separate the Service code into a new CVS repository (jakarta-service). How about it? Ok for jakarta-service. And I agree with Pier that since it's not only related to tomcat, shouldn't go under jakarta-tomcat-service. Should we have all developpment started by a tomcat commiter under the jakarta-tomcat responsability. I'm +1 for jakarta-service and -1 for jakarta-tomcat-service
Re: Separating Service code from Tomcat 4.0
Joe Flowers at [EMAIL PROTECTED] wrote: [X] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [X] -0 - Do it, even ifI hate MS. [ ] -1 - Don't do it, because My comments: Assuming you're talking about the NT/2000 service codes. Yes, that's another reason why I'm proposing the split. I am integrating your Service code with my Service code (so we're going to be both very happy campers), and I would actually request your commit status on the jakarta-tomcat-service CVS module... You're the author of that code, and I would be _so_happy_ to see you on board... Especially for the design of a new Service API... :) Pier
Re: Separating Service code from Tomcat 4.0
Remy Maucherat at [EMAIL PROTECTED] wrote: Do it, even if that would make the build process (even) more complex. I believe this can be achieved by simply copying the few interfaces over to jakarta-tomcat-4.0. Once those have been defined, they shouldn't change. While the actual big work is on the C code, which is the real thing we want to develop... And that part is completely separated from Tomcat, and its build process... Ok. +1 then. Remy
Re: Separating Service code from Tomcat 4.0
GOMEZ Henri at [EMAIL PROTECTED] wrote: Ok for jakarta-service. And I agree with Pier that since it's not only related to tomcat, shouldn't go under jakarta-tomcat-service. Should we have all developpment started by a tomcat commiter under the jakarta-tomcat responsability. I'm +1 for jakarta-service and -1 for jakarta-tomcat-service Well, creating a new top-level project requires an action from the PMC, and for brevity, that's what I would like to avoid right now... I believe that jakarta-tomcat-service is OK for now, and that when we get to a decently sized critical mass, we can spin it off as its own subproject, with mailing lists, committers and all that crap... So, although it's not directly related to Tomcat, and it'll be actually better to have it as a different thing, I'd rather start it spin it off under the auspices of the current Tomcat project, if it's ok for the others. Pier
Re: Separating Service code from Tomcat 4.0
Pier P. Fumagalli at [EMAIL PROTECTED] wrote: Joe Flowers at [EMAIL PROTECTED] wrote: [X] +1 - Do it, and I can help [ ] +0 - Do it, but I can't help [X] -0 - Do it, even ifI hate MS. [ ] -1 - Don't do it, because My comments: Assuming you're talking about the NT/2000 service codes. Yes, that's another reason why I'm proposing the split. I am integrating your Service code with my Service code (so we're going to be both very happy campers), and I would actually request your commit status on the jakarta-tomcat-service CVS module... You're the author of that code, and I would be _so_happy_ to see you on board... Especially for the design of a new Service API... :) 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... I'll dig into those further :) Pier
