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
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
>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: > > 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
Re: Separating Service code from Tomcat 4.0
Elijah Roberts at [EMAIL PROTECTED] wrote: > > Looking through your code, I think that you definitely intended for the > NT piece to be in the same place. Using the same command line arguments > and everything. But with a new file just for the NT specific service > information (jsvc-nt.c). If that is the case, I'll look through the files > in more detail and see how difficult that will be. That's correct... BUT, hold your horses, as I want to modify how JNI is called... There is a HUGE security hole right now, as I too call static methods inside a class called ServiceLoader. I need to finish some fixes to webapp and then I'll move on to Service... (Couple of days!) Pier
Re: Separating Service code from Tomcat 4.0
On Wednesday July 25, 2001 Elijah Roberts wrote: > 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? Looking through your code, I think that you definitely intended for the NT piece to be in the same place. Using the same command line arguments and everything. But with a new file just for the NT specific service information (jsvc-nt.c). If that is the case, I'll look through the files in more detail and see how difficult that will be. Elijah Roberts
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
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 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
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: >> >> [ ] +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. I'm -1 on that... The service code I'm building, and the one coming with mod jk are completely different, they don't even share the same Java interfaces. The service code that currently is parked under Tomcat 4.0 is more-or-less a complete solution to Operating-Systems daemons written in Java, and that package tries to solve several problems (not just running tomcat as a service in Win32), including (but not limited to) binding to port <1024 under Java while running the VM process as user nobody... Pier
Re: Separating Service code from Tomcat 4.0
> 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
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
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
> >> 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
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
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
> > 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
"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
[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
> 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
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
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
> 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
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
>"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
"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
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
[ ] +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
[ ] +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
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
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
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
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
"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... jakarta-tomcat-connectors is a place where C and Java are mixed ;-) What about jakarta-tomcat-connectors/service? > > Pier
Re: Separating Service code from Tomcat 4.0
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... Pier
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, 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
