RE: [PROPOSAL] The Commons - web connector
Still no response for this sub-project proposal.
The upcoming PMC could be an occasion to speak about it.
I saw at least 4 potentials commiters working on it :
- Dan Milstein, our resident hacker/expert of mod_jk.
- Keith Wannamaker, webdav specialist
- Pier P. Fumagalli, mod_jserv and mod_webapp father
- I, Henri Gomez, mod_jk and adaptation to Apache 2.0
We start speaking of an updated mod_jk with ajp13++ (ajp14)
which must fix current known problem like :
- lack of security between Apache / Tomcat
Tomcat accept connection from anybody to it's ajp12/ajp13
connector. We may add so trivial authentification scheme
at least at connect time.
Nothing too expensive but last days on Tomcat list there is
an interesting Thread on 'Encrypting password' ('challenge-response')
- problem with large upload between client -> apache -> tomcat.
If tomcat is broken between the upload we just couldn't do anything
with remaining data and load-balancing/fault-tolerant will be no help
there. We must have a persitant storage used in these upload case (flat
file ?)
- context loading/unloading information could be sent from
Tomcat to Apache to let him choose a working Tomcat for
the requested context. Indispensable in production site with
many virutal where admin will want to update specific context.
- mod_jk handle load-balancing but many will just want a simple
fault-tolerant configuration. I Tomcat1 fail just go to Tomcat2,
and just in that case.
Thanks to comment.
>Hi to all,
>
>What about a new sub-project, web connector, where all
>the developpement on mod_jserv and mod_jk
>(and why not mod_webapp) could live.
>
>Apache 1.3 and 2.0 are allready supported by mod_jk but also
>IIS, AOL, and NES (iPlanet) even JNI.
>
>Tomcat's 3.x and 4.x provide interfaces (modules,
>interceptor or whatever) that these connectors will implement :)
>
>A project which could be in The Commons even if there is
>still C code inside but also many java part (TC mod/interceptor).
>
>We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use
>mod_webapp from Apache 2.0...
>
>Comments ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons - web connector
On Wed, 14 Mar 2001, GOMEZ Henri wrote: > Still no response for this sub-project proposal. A big +1 This will also reduce the pressure on making changes in the "stable" code. If a bug is found in the connector - we can just make a new release of the connector ( both sides ), without a need to make a dot.dot release of tomcat. ( tomcat 3.3 should still include the current mod_jk, with some of the fixes that are "safe" and/or proven in the new potential module ) BTW, if the "commons" project is aproved, than this can be a part of the "sandbox"/"agora" - and it doesn't require any special aproval from PMC or other projects ( only a vote on tomcat-dev). > I saw at least 4 potentials commiters working on it : > > - Dan Milstein, our resident hacker/expert of mod_jk. > - Keith Wannamaker, webdav specialist > - Pier P. Fumagalli, mod_jserv and mod_webapp father > - I, Henri Gomez, mod_jk and adaptation to Apache 2.0 I can help with some performance and a bit in the C side. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons - web connector
I don't see the advantages to having a separate project for the connectors.
Can someone explain that to me?
The main disadvantage that I see is that the connectors and Tomcat are very
tightly linked -- I think having one developer list for TC and the
connectors makes a lot of sense. I think having one bug system for TC and
the connectors makes a lot of sense (especially since it's not always clear
if the bug is in TC or in the connector when it is reported). Ditto for the
user list, where TC/connector configuration issues are ever popular.
Would this separate project include both C and Java code? It would have to,
if it would have any meaning (just working on one side of the protocols
would be a nightmare to sync up with a "separate" project). But if there's
Java code in there, there's going to have to be different code for each
different engine which the connector talks to (e.g. TC 3, TC 4). Pulling
that code out of the main projects makes no sense to me. It is totally
dependent on the rest of the project code.
I'm not sure if I'd want to be a committer on a different project -- once
3.3 is released, I'm planning on working on the 4.x branch. The first thing
I'd like to do (which I threatened to do a long time ago!), would be to
write an ajp13 connector and/or merge mod_webapp with mod_jk. That is
"connector" work, but I, personally, am more interested in the servlet
engine as a whole than on "just" the connectors.
-Dan
GOMEZ Henri wrote:
>
> Still no response for this sub-project proposal.
>
> The upcoming PMC could be an occasion to speak about it.
>
> I saw at least 4 potentials commiters working on it :
>
> - Dan Milstein, our resident hacker/expert of mod_jk.
> - Keith Wannamaker, webdav specialist
> - Pier P. Fumagalli, mod_jserv and mod_webapp father
> - I, Henri Gomez, mod_jk and adaptation to Apache 2.0
>
> We start speaking of an updated mod_jk with ajp13++ (ajp14)
> which must fix current known problem like :
>
> - lack of security between Apache / Tomcat
> Tomcat accept connection from anybody to it's ajp12/ajp13
> connector. We may add so trivial authentification scheme
> at least at connect time.
> Nothing too expensive but last days on Tomcat list there is
> an interesting Thread on 'Encrypting password' ('challenge-response')
>
> - problem with large upload between client -> apache -> tomcat.
> If tomcat is broken between the upload we just couldn't do anything
> with remaining data and load-balancing/fault-tolerant will be no help
> there. We must have a persitant storage used in these upload case (flat
> file ?)
>
> - context loading/unloading information could be sent from
> Tomcat to Apache to let him choose a working Tomcat for
> the requested context. Indispensable in production site with
> many virutal where admin will want to update specific context.
>
> - mod_jk handle load-balancing but many will just want a simple
> fault-tolerant configuration. I Tomcat1 fail just go to Tomcat2,
> and just in that case.
>
> Thanks to comment.
>
> >Hi to all,
> >
> >What about a new sub-project, web connector, where all
> >the developpement on mod_jserv and mod_jk
> >(and why not mod_webapp) could live.
> >
> >Apache 1.3 and 2.0 are allready supported by mod_jk but also
> >IIS, AOL, and NES (iPlanet) even JNI.
> >
> >Tomcat's 3.x and 4.x provide interfaces (modules,
> >interceptor or whatever) that these connectors will implement :)
> >
> >A project which could be in The Commons even if there is
> >still C code inside but also many java part (TC mod/interceptor).
> >
> >We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use
> >mod_webapp from Apache 2.0...
> >
> >Comments ?
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons - web connector
On Wed, 14 Mar 2001, Dan Milstein wrote: > I don't see the advantages to having a separate project for the connectors. > Can someone explain that to me? I don't think the proposal meant a separate top level project, with separate list, etc. It meant to decouple mod_jk and the connector from tomcat 3.3 As you can see in previous mails, there are people who "will not touch any line of tomcat 3.x". I think mod_jk and the connector part of tomcat3.3 is a great piece of work, with a lot of great ideas - and it doesn't depend in any way of tomcat3.3 - the same as mod_webapp is not specific to tomcat4.0 I think it will help to have a "common" and "neutral" repository, with the goal of creating a connector based on the best ideas from mod_jk and mod_webapp - or ( as mod_jk is designed ) multiple protocols that are used in by both tomcat3.3, tomcat4.0 and maybe other containers. As I said, the connector is in charge with implementing a protocol of communication between the server and container - it doesn't depend on having "Interceptors" or "Valves", it doesn't depend on having 6 core classes or 20 interfaces, it doesn't depend on having a Loader interface or using the standard ClassLoader. Of course, there are parts that are specific to a container - but the idea is to share what's common. In the same way, it would be great to develop a single set of general-purpose utilities - like ThreadPools, MessageBytes, etc - that will combine the best out of both codebases and may be used by others as well. And it would be great to have common code for jasper, with specialized classes implementing what's different - 90% of the code in jasper3.3 and jasper4.0 is common ( but is diverging every day ). Right now the biggest problem is the fact that some people refuse to accept there are other ideas and solutions. This leads to duplications all across jakarta, not only in tomcat3.3/4.0. And the only solution I know out of this is to concentrate in what's common, and respect the differences. > The main disadvantage that I see is that the connectors and Tomcat are very > tightly linked -- I think having one developer list for TC and the The protocol and most of the connector is not linked in any way to the underlying architecture of tomcat ( i.e. the Interceptor is just a wrapper, a way to plug in the connector ). The list, bug system, etc will stay the same, of course, it's just that it'll be less "coupled" with tomcat3.3, and may have a more independent evolution. > would be a nightmare to sync up with a "separate" project). But if there's > Java code in there, there's going to have to be different code for each > different engine which the connector talks to (e.g. TC 3, TC 4). Pulling > that code out of the main projects makes no sense to me. It is totally > dependent on the rest of the project code. Tomcat 3.3 should work with mod_webapp, tomcat4.0 should work with mod_jk. There are differences - but most of the code should be common. The C code should be the same, and on the Java side the only thing that is different is the interface on the upper side. > I'm not sure if I'd want to be a committer on a different project -- once I don't think it should be a different project - but the hope is that more commiters will contribute on a 3.3-4.0 common connector. > 3.3 is released, I'm planning on working on the 4.x branch. The first thing After 3.3 is released I guess most of us will be working on something else - for me it'll the "next" generation of container, combining the best of 3.x and 4.x. Having a connector that combines the best of mod_jk and mod_webapp will be a great step in that direction. > I'd like to do (which I threatened to do a long time ago!), would be to > write an ajp13 connector and/or merge mod_webapp with mod_jk. That is > "connector" work, but I, personally, am more interested in the servlet > engine as a whole than on "just" the connectors. Same for me. I would be happy to help in anything that is a "merge" that combines the best of both. Costin ( BTW, I already have a prototype and a name for the combined thing :-) > > GOMEZ Henri wrote: > > > > Still no response for this sub-project proposal. > > > > The upcoming PMC could be an occasion to speak about it. > > > > I saw at least 4 potentials commiters working on it : > > > > - Dan Milstein, our resident hacker/expert of mod_jk. > > - Keith Wannamaker, webdav specialist > > - Pier P. Fumagalli, mod_jserv and mod_webapp father > > - I, Henri Gomez, mod_jk and adaptation to Apache 2.0 > > > > We start speaking of an updated mod_jk with ajp13++ (ajp14) > > which must fix current known problem like : > > > > - lack of security between Apache / Tomcat > > Tomcat accept connection from anybody to it's ajp12/ajp13 > > connector. We may add so trivial authentification scheme > > at least at connect time. > > Nothing too expensive but last days on Tomcat list there is > > an interesting Thread on
RE: [PROPOSAL] The Commons - web connector
>I don't see the advantages to having a separate project for >the connectors. >Can someone explain that to me? > >The main disadvantage that I see is that the connectors and >Tomcat are very tightly linked. Why did you want the connector and Tomcat so tightly linked ? Take for example, mod_perl, mod_rubys or mod_python. Did mod_perl is hardly linked to perl ? Did you mix developpement of perl and mod_perl ? >I think having one developer list for TC and the >connectors makes a lot of sense. Yes we must split user/dev connector list from tomcat (core) list. >I think having one bug >system for TC and the connectors makes a lot of sense (especially since it's not >always clear if the bug is in TC or in the connector when it is reported). if a request works against the Tomcat native http connector and didn't works when passing via connector, it's clearly a connector bug. >Ditto for the user list, where TC/connector configuration issues are ever popular. +1 >Would this separate project include both C and Java code? It >would have to, if it would have any meaning (just working on one side of the protocols >would be a nightmare to sync up with a "separate" project). A connector is part of code in C (Apache, IIS, NES) and part in Java (the plug in Tomcats). No need to split here. >But if there's Java code in there, there's going to have to be different code for each >different engine which the connector talks to (e.g. TC 3, TC 4). Pulling >that code out of the main projects makes no sense to me. It is totally >dependent on the rest of the project code. Sure, TC 3 and TC 4 use differents 'Interception' mechanism but the core ajp12/ajp13 code is and must be the same. >I'm not sure if I'd want to be a committer on a different >project -- once 3.3 is released, I'm planning on working on the 4.x branch. If you remember when the tomcat 3.3 was finally decided it was asked to developpers to keep working on it after release. >The first thing >I'd like to do (which I threatened to do a long time ago!), would be to >write an ajp13 connector and/or merge mod_webapp with mod_jk. That is >"connector" work, but I, personally, am more interested in the servlet >engine as a whole than on "just" the connectors. I'm more interesting in building a stable connector and I'll concentrate on that. There is allready many talentuous developper like Costin or Craig (I don't forget Nacho, Larry, Remy, Pier) to works on Tomcat core. Working on connector is important for production world (and just before management decision) since stable, fast and featured connectors will help impose Tomcat's in real world. It's my personal opinion and vision but what make me choose JServ was Apache mod_jserv connector with it's fault-tolerance and load-balancing. And only this feature make my company (and others later) choose the Apache solution for servlet/jsp developpment and production. Regards
RE: [PROPOSAL] The Commons - web connector
Dan, Henri, Remember the goal - to have a high quality connector and servlet container. Whatever brings us closer to that is good. Right now there are 3-4 people fixing bugs and working on mod_jk - and you 2 have probably the most knowledge about it. I was hoping that by moving it in a separate place we might get to share and merge the connector with 4.0. And that would be good because it'll increase the quality and the community behind the connector. This can happen only if all of you agree ( and also Craig, Pier and Remy who are working on connectors too on the 4.0 side ). Everything else ( list, cvs, integration with tomcat, etc ) is detail :-) Costin On Thu, 15 Mar 2001, GOMEZ Henri wrote: > >I don't see the advantages to having a separate project for > >the connectors. > >Can someone explain that to me? > > > >The main disadvantage that I see is that the connectors and > >Tomcat are very tightly linked. > > Why did you want the connector and Tomcat so tightly linked ? > > Take for example, mod_perl, mod_rubys or mod_python. > Did mod_perl is hardly linked to perl ? Did you mix > developpement of perl and mod_perl ? > > >I think having one developer list for TC and the > >connectors makes a lot of sense. > > Yes we must split user/dev connector list from tomcat (core) list. > > >I think having one bug > >system for TC and the connectors makes a lot of sense (especially since > it's not > >always clear if the bug is in TC or in the connector when it is reported). > > > if a request works against the Tomcat native http connector and didn't > works when passing via connector, it's clearly a connector bug. > > >Ditto for the user list, where TC/connector configuration issues are ever > popular. > +1 > > >Would this separate project include both C and Java code? It > >would have to, if it would have any meaning (just working on one side of > the protocols > >would be a nightmare to sync up with a "separate" project). > > A connector is part of code in C (Apache, IIS, NES) and part in Java (the > plug in > Tomcats). No need to split here. > > >But if there's Java code in there, there's going to have to be different > code for each > >different engine which the connector talks to (e.g. TC 3, TC 4). Pulling > >that code out of the main projects makes no sense to me. It is totally > >dependent on the rest of the project code. > > Sure, TC 3 and TC 4 use differents 'Interception' mechanism but the core > ajp12/ajp13 code > is and must be the same. > > >I'm not sure if I'd want to be a committer on a different > >project -- once 3.3 is released, I'm planning on working on the 4.x branch. > > > If you remember when the tomcat 3.3 was finally decided it was asked to > developpers to keep working on it after release. > > >The first thing > >I'd like to do (which I threatened to do a long time ago!), would be to > >write an ajp13 connector and/or merge mod_webapp with mod_jk. That is > >"connector" work, but I, personally, am more interested in the servlet > >engine as a whole than on "just" the connectors. > > I'm more interesting in building a stable connector and I'll concentrate > on that. There is allready many talentuous developper like Costin or Craig > (I don't forget Nacho, Larry, Remy, Pier) to works on Tomcat core. > > Working on connector is important for production world (and just before > management decision) since stable, fast and featured connectors will help > impose Tomcat's in real world. > > It's my personal opinion and vision but what make me choose JServ was > Apache mod_jserv connector with it's fault-tolerance and load-balancing. > And only this feature make my company (and others later) choose the Apache > solution for servlet/jsp developpment and production. > > Regards >
RE: [PROPOSAL] The Commons - web connector
>This can happen only if all of you agree ( and also Craig, >Pier and Remy who are working on connectors too on the 4.0 side ). The goal of the proposal was to include all people involved on connectors from TC 3.1 up to 4.0. After reading the 'Commons Proposal' in jakarta-general I was thinking that web-connector could fall in that category of common/sharing project. I'm open to all proposition. >Everything else ( list, cvs, integration with tomcat, etc ) is >detail :-) Yep, administrative task.
RE: [PROPOSAL] The Commons - web connector
>Costin > >( BTW, I already have a prototype and a name for the combined thing :-) Could you tell us what's the proposed name ?
Re: [PROPOSAL] The Commons - web connector
For those who don't read jakarta-general (myself included), a draft of The 'Commons Proposal' can be found at: http://husted.com/about/commons/ -Dan GOMEZ Henri wrote: > > >This can happen only if all of you agree ( and also Craig, > >Pier and Remy who are working on connectors too on the 4.0 side ). > > The goal of the proposal was to include all people involved on > connectors from TC 3.1 up to 4.0. > > After reading the 'Commons Proposal' in jakarta-general I was > thinking that web-connector could fall in that category of > common/sharing project. I'm open to all proposition. > > >Everything else ( list, cvs, integration with tomcat, etc ) is > >detail :-) > > Yep, administrative task. -- Dan Milstein // [EMAIL PROTECTED]
