Re: [Proposal] Remove older of the two BIO AJP connectors
> I am saying the exact same thing - we shouldn't add another protocol, it was > > a mistake to even have AJP proto in the first place, and we shouldn't > attempt > to extend it. > > However we do need some form of communication between tomcat and jk - > what AJP provides won't allow much. And what I was suggesting is to not > do another protocol - but find an existing one and use/adapt it. Another solution could be : - just use HTTP between HTTPd/IIS and Tomcat to forward request. - add some special HTTP requests on Tomcat to get informations about load or live topology. ie: When a new Tomcat enter a 'named' cluster group, others should get the informations and should be able to deliver to HTTPd/IIS with just simple HTTP requests so no need to add the multicast support in HTTP/IIS. There is allready cluster middleware in TC (tribes) to do this. Same thing when a Tomcat shutdown or exit a 'named' cluster group. A good idea will be to provide a simple/default Tomcat load servlet but let people override or provide their own. In many uses, it's not the number of threads or Tomcat CPUs load which should be counter but for example remote SQL load. Just an idea - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Mon, Apr 6, 2009 at 3:06 PM, Filip Hanik - Dev Lists wrote: > Mladen Turk wrote: > >> Costin Manolache wrote: >> >>> So in essence you have a new protocol but the sole difference is how you describe it. >>> >>> The API can be something like: >>> - legacyRequest(RequestMessage) - whatever we have in the current AJP >>> protocol >>> - getServerLoad() and whatever new we wanted to add >>> >>> Instead of defining AJP extensions, we just pick one of the marshalling >>> libs >>> and use them >>> for encoding the new methods. >>> >>> >> Again, you are presuming a new protocol and IMO everyone >> here are just getting nasty red spots on their faces when >> you do such a thing ;) >> > I was gonna reply earlier, but my red spot reaction got kind of severe :) > I have a hard time seeing why we would need yet another protocol. > I think history has shown that to be a tough challenge. I am saying the exact same thing - we shouldn't add another protocol, it was a mistake to even have AJP proto in the first place, and we shouldn't attempt to extend it. However we do need some form of communication between tomcat and jk - what AJP provides won't allow much. And what I was suggesting is to not do another protocol - but find an existing one and use/adapt it. Costin > >> IMHO the solution would be to gather separate >> community and move all development outside the >> Tomcat, because it simply doesn't fit here. >> The current code base for mod_jk and java side >> connector is huge, and imagine how large it would >> be with all the bells and whistles added. >> >> Tomcat could serve as an incubator for such a >> project, but I see no reason not to use >> Apache Incubator directly. Maybe we will >> attract larger community this way. >> >> >> Regards >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Proposal] Remove older of the two BIO AJP connectors
Mladen Turk wrote: Costin Manolache wrote: So in essence you have a new protocol but the sole difference is how you describe it. The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Again, you are presuming a new protocol and IMO everyone here are just getting nasty red spots on their faces when you do such a thing ;) I was gonna reply earlier, but my red spot reaction got kind of severe :) I have a hard time seeing why we would need yet another protocol. I think history has shown that to be a tough challenge. IMHO the solution would be to gather separate community and move all development outside the Tomcat, because it simply doesn't fit here. The current code base for mod_jk and java side connector is huge, and imagine how large it would be with all the bells and whistles added. Tomcat could serve as an incubator for such a project, but I see no reason not to use Apache Incubator directly. Maybe we will attract larger community this way. Regards - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Very interesting thread. What's the needs in server / tc communications ? - new apis - new communication layer ajp is a not so bad protocol but the jk impl mix comm & marsh/unmarsh & api. we could find a persistant communication layer (openwire from activemq ?) we could define a set of apis (getLoad, forwardRequest) Then we should be able to glue both to a servlet engine like tomcat. Could we assemble existing components and attract external people ? I hope so, that was the idea behind my original post on this thread. I'm pretty sure we could collects ideas and needs here and after have a general idea of what should be done, how and where. Incubator is a good idea, so it won't just be (seen) as a new tomcat sub project or a nth attempt to rewrite mod_jk. Also it could be used by other servlet engines, more brains, more ideas. Openess is the key. Le 4 avr. 09 à 19:15, Costin Manolache a écrit : On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk wrote: Costin Manolache wrote: On Sat, Apr 4, 2009 at 9:03 AM, David Jencks wrote: My understanding of 'what we talk about' is what to do with mod_jk - deprecate/remove old code, add few features to better match current tomcat ( and current requirements - larger clusters, etc ). It seems there is some agreement that current AJP protocol won't work, but bigger disagreement on weather to just do nothing at all ( i.e. just maintain current code ), or do some small addition to AJP, use HTTP, etc. I got the impression that majority of people here wish to maintain the mod_jk. Rainer wishes to add few things in new 1.3 branch which is fine with me. The rest like Jean-Frederic said 'Won't happen' which I read, there is no man power here that would do something new. I agree there is no man power to implement a new protocol. But if we just use one - openwire or something similar - it may be much easier. Adding the dependency and getting it to build should be few hours/ days, then adding various handlers can be done very incrementally. If I read correctly Rainer's list, some improvements will be easier if he had a better/more extensible communication mechanism, load balancing in particular. I don't have a lot of time - certainly not for a new connector/ branch/etc, but I and others may find few hours if it would be easier - and I think a more extensible communication would do that. Changing existing code - without breaking backward compat - is pretty hard. I would love to make 'something new', but it obviously won't happen under Tomcat umbrella. Why not ? It seems well in scope. Costin Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk wrote: > Costin Manolache wrote: > >> On Sat, Apr 4, 2009 at 9:03 AM, David Jencks >> wrote: >> >> >> My understanding of 'what we talk about' is what to do with mod_jk - >> deprecate/remove old code, add few features >> to better match current tomcat ( and current requirements - larger >> clusters, >> etc ). It seems there is some agreement that >> current AJP protocol won't work, but bigger disagreement on weather to >> just >> do nothing at all ( i.e. just maintain current >> code ), or do some small addition to AJP, use HTTP, etc. >> >> > I got the impression that majority of people here > wish to maintain the mod_jk. Rainer wishes to add few > things in new 1.3 branch which is fine with me. > > The rest like Jean-Frederic said 'Won't happen' > which I read, there is no man power here that > would do something new. > I agree there is no man power to implement a new protocol. But if we just use one - openwire or something similar - it may be much easier. Adding the dependency and getting it to build should be few hours/days, then adding various handlers can be done very incrementally. If I read correctly Rainer's list, some improvements will be easier if he had a better/more extensible communication mechanism, load balancing in particular. I don't have a lot of time - certainly not for a new connector/branch/etc, but I and others may find few hours if it would be easier - and I think a more extensible communication would do that. Changing existing code - without breaking backward compat - is pretty hard. > > I would love to make 'something new', but it > obviously won't happen under Tomcat umbrella. Why not ? It seems well in scope. Costin > > > > Regards > -- > ^(TM) > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Proposal] Remove older of the two BIO AJP connectors
Costin Manolache wrote: On Sat, Apr 4, 2009 at 9:03 AM, David Jencks wrote: My understanding of 'what we talk about' is what to do with mod_jk - deprecate/remove old code, add few features to better match current tomcat ( and current requirements - larger clusters, etc ). It seems there is some agreement that current AJP protocol won't work, but bigger disagreement on weather to just do nothing at all ( i.e. just maintain current code ), or do some small addition to AJP, use HTTP, etc. I got the impression that majority of people here wish to maintain the mod_jk. Rainer wishes to add few things in new 1.3 branch which is fine with me. The rest like Jean-Frederic said 'Won't happen' which I read, there is no man power here that would do something new. I would love to make 'something new', but it obviously won't happen under Tomcat umbrella. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
David Jencks wrote: I don't really know what you guys are talking about LOL. Not sure we do as well :) but it might be you are looking for a cross-platform multiplexing asynchronous message exchange system. If so you might look into activemq's openwire transport. IIUC they have a message grammar that is compiled into code for various platforms including java, .net, c++, etc. openwire-c is in the sandbox, so dunno how well this is supported. However it uses apr, so this is huge advantage, and there is open invitation for making it better. Perhaps this is a protocol layer we could reuse. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Sat, Apr 4, 2009 at 9:03 AM, David Jencks wrote: > I don't really know what you guys are talking about but it might be you are > looking for a cross-platform multiplexing asynchronous message exchange > system. If so you might look into activemq's openwire transport. IIUC they > have a message grammar that is compiled into code for various platforms > including java, .net, c++, etc. > One more option to choose from - does anyone have experience with this ? How many dependencies, performance, etc ? My understanding of 'what we talk about' is what to do with mod_jk - deprecate/remove old code, add few features to better match current tomcat ( and current requirements - larger clusters, etc ). It seems there is some agreement that current AJP protocol won't work, but bigger disagreement on weather to just do nothing at all ( i.e. just maintain current code ), or do some small addition to AJP, use HTTP, etc. Costin > > thanks > david jencks > > > On Apr 4, 2009, at 8:42 AM, Costin Manolache wrote: > > On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk wrote: >> >> Costin Manolache wrote: >>> >>> So in essence you have a new protocol but the sole > difference is how you describe it. > > > The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Again, you are presuming a new protocol and IMO everyone >>> here are just getting nasty red spots on their faces when >>> you do such a thing ;) >>> >>> >> My understanding was that some people want to add features to mod_jk >> to support extended load balancing, eventually the fancy async stuff, etc. >> >> I can't see how this can be done without proto changes - current AJP won't >> work. >> And this is quite specific to tomcat, you can't dump it on incubator. >> >> What I'm trying to suggest is that a 'new protocol' ( as in - enhanced >> AJP, >> AJP2.0, etc ) >> is not a good idea. Instead the extensions needed should be done by using >> existing libraries and protocols, and when this is stable the AJP protocol >> should be >> deprecated (thus reducing the code size). Thrift/protobufs can be used >> quite >> easily >> on top of an existing transport, as payload, and can represent all the >> messages >> you want. >> >> >> Costin >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Proposal] Remove older of the two BIO AJP connectors
I don't really know what you guys are talking about but it might be you are looking for a cross-platform multiplexing asynchronous message exchange system. If so you might look into activemq's openwire transport. IIUC they have a message grammar that is compiled into code for various platforms including java, .net, c++, etc. thanks david jencks On Apr 4, 2009, at 8:42 AM, Costin Manolache wrote: On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk wrote: Costin Manolache wrote: So in essence you have a new protocol but the sole difference is how you describe it. The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Again, you are presuming a new protocol and IMO everyone here are just getting nasty red spots on their faces when you do such a thing ;) My understanding was that some people want to add features to mod_jk to support extended load balancing, eventually the fancy async stuff, etc. I can't see how this can be done without proto changes - current AJP won't work. And this is quite specific to tomcat, you can't dump it on incubator. What I'm trying to suggest is that a 'new protocol' ( as in - enhanced AJP, AJP2.0, etc ) is not a good idea. Instead the extensions needed should be done by using existing libraries and protocols, and when this is stable the AJP protocol should be deprecated (thus reducing the code size). Thrift/protobufs can be used quite easily on top of an existing transport, as payload, and can represent all the messages you want. Costin - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk wrote: > Costin Manolache wrote: > >> So in essence you have a new protocol but the sole >>> difference is how you describe it. >>> >>> >> >> The API can be something like: >> - legacyRequest(RequestMessage) - whatever we have in the current AJP >> protocol >> - getServerLoad() and whatever new we wanted to add >> >> Instead of defining AJP extensions, we just pick one of the marshalling >> libs >> and use them >> for encoding the new methods. >> >> > Again, you are presuming a new protocol and IMO everyone > here are just getting nasty red spots on their faces when > you do such a thing ;) > My understanding was that some people want to add features to mod_jk to support extended load balancing, eventually the fancy async stuff, etc. I can't see how this can be done without proto changes - current AJP won't work. And this is quite specific to tomcat, you can't dump it on incubator. What I'm trying to suggest is that a 'new protocol' ( as in - enhanced AJP, AJP2.0, etc ) is not a good idea. Instead the extensions needed should be done by using existing libraries and protocols, and when this is stable the AJP protocol should be deprecated (thus reducing the code size). Thrift/protobufs can be used quite easily on top of an existing transport, as payload, and can represent all the messages you want. Costin
Re: [Proposal] Remove older of the two BIO AJP connectors
Costin Manolache wrote: So in essence you have a new protocol but the sole difference is how you describe it. The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Again, you are presuming a new protocol and IMO everyone here are just getting nasty red spots on their faces when you do such a thing ;) IMHO the solution would be to gather separate community and move all development outside the Tomcat, because it simply doesn't fit here. The current code base for mod_jk and java side connector is huge, and imagine how large it would be with all the bells and whistles added. Tomcat could serve as an incubator for such a project, but I see no reason not to use Apache Incubator directly. Maybe we will attract larger community this way. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Sat, Apr 4, 2009 at 1:10 AM, Mladen Turk wrote: > Costin Manolache wrote: > >> >>> and certainly not >>> worth creating a new protocol. We need to pick one of thrift/protobuf/hessian for marshaling, and start doing some mux-ing in the protocol. All those framework you mention are just helpers for >>> *building* the custom protocol. They actually mandate >>> that we will have one but now hidden inside some IDL >>> language description. Any such framework makes >>> almost impossible to change the protocol specification >>> while preserving backward compatibility >>> (One huge problem why AJP is not usable any more) >>> >> >> >> You preserve backward compat by keeping the protocol stable >> and supporting all methods you define in the IDL. What is needed >> is bi-directional communication between web server and tomcat - >> so you can do all the extensions on the list. >> The stability of the actual method definition is probably more important >> than the protocol itself - if we start using an IDL, it is even possible >> to >> expose the methods over multiple protocols if there is a >> compelling reason. >> >> > Sure, but then you force everyone that wish to talk to you > to use the same framework. The same thing can be done > with a pencil and a peace of paper cause we only need one > protocol, not zillion of them. > So in essence you have a new protocol but the sole > difference is how you describe it. > > None of them has multiplexing (Google protobufs doesn't even > have the transport layer just marshal/unmarshal, while thrift > transport is unix only). > The only OSS solution that I know is w3c's http mux, but that's only > Java part and IMO incompatible with ASL license. > I think it is good to separate marshaling from the transport and the actual service API. Our main value is the API - simple forwarding, async forwarding, load info, etc. After we implement the primitive - it is possible to expose them over multiple transports - socket, unix, etc and even marshal the messages using different libraries. We could even expose an API over plain HTTP ( without mux-ing ). I am only suggesting one marshal library ( at least for start ), and a small changes to the transport we have. The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Later we can add: - asyncInputData(reqId, Data) - on tomcat - asyncSendData(reqId, Data) - on web server For transport - we can keep most of the current code, but for async we need to stop waiting for a response to each request, and use a request ID ( or 'channel ID' ) and multiplex. I think this can be done without a huge effort, and incrementally - i.e. alongside the existing code, reusing what we have. Well, maybe I'm underestimating, but I'm pretty sure the harder part will be agreeing on details like what marshaling to use, what branch and review process - can anyone veto a proto/api he doesn't like, etc :-) That's why I'm suggesting that long term we could support multiple marshalling and API extensions, if there are strong religious reasons. In any case - there are quite a few mux protos out there - SSH proto, PPP, few in w3c /http.next, etc, and most can use any payload ( marshalling/api ). And for 'human readable' - I can throw in XMPP as an alternative to your wsgi :-) Costin > > >> >>> I'm kind of more fun of >>> http://www.wsgi.org/wsgi/ >>> >>> At least it's human readable and already working :) >>> >> >> >> Well, the spec is not so human readable :-) - can you point me to the >> description >> of the communication protocol - i.e. the marshaling, framing, etc ? I >> don't >> mind >> 'human readable', or even supporting multiple formats. Are they >> multiplexing >> or >> request-waiting-response ? Do they already define methods for load >> balancing, etc ? >> If yes - sure, it's one valid option. >> >> > Sorry, Costin I was pulling your leg with that. > It's an example of where we could end up eventually. > > In essence there is no webserver/backend (proxy) protocol > or standard that exists and that is usable with > async, security, rpc and multiplexing support. Period. > > The only dedicated one were AJP and FCGI, but both > were designed with web.0 in mind. > > > Regards > -- > ^(TM) > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Proposal] Remove older of the two BIO AJP connectors
Costin Manolache wrote: and certainly not worth creating a new protocol. We need to pick one of thrift/protobuf/hessian for marshaling, and start doing some mux-ing in the protocol. All those framework you mention are just helpers for *building* the custom protocol. They actually mandate that we will have one but now hidden inside some IDL language description. Any such framework makes almost impossible to change the protocol specification while preserving backward compatibility (One huge problem why AJP is not usable any more) You preserve backward compat by keeping the protocol stable and supporting all methods you define in the IDL. What is needed is bi-directional communication between web server and tomcat - so you can do all the extensions on the list. The stability of the actual method definition is probably more important than the protocol itself - if we start using an IDL, it is even possible to expose the methods over multiple protocols if there is a compelling reason. Sure, but then you force everyone that wish to talk to you to use the same framework. The same thing can be done with a pencil and a peace of paper cause we only need one protocol, not zillion of them. So in essence you have a new protocol but the sole difference is how you describe it. None of them has multiplexing (Google protobufs doesn't even have the transport layer just marshal/unmarshal, while thrift transport is unix only). The only OSS solution that I know is w3c's http mux, but that's only Java part and IMO incompatible with ASL license. I'm kind of more fun of http://www.wsgi.org/wsgi/ At least it's human readable and already working :) Well, the spec is not so human readable :-) - can you point me to the description of the communication protocol - i.e. the marshaling, framing, etc ? I don't mind 'human readable', or even supporting multiple formats. Are they multiplexing or request-waiting-response ? Do they already define methods for load balancing, etc ? If yes - sure, it's one valid option. Sorry, Costin I was pulling your leg with that. It's an example of where we could end up eventually. In essence there is no webserver/backend (proxy) protocol or standard that exists and that is usable with async, security, rpc and multiplexing support. Period. The only dedicated one were AJP and FCGI, but both were designed with web.0 in mind. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Fri, Apr 3, 2009 at 10:24 AM, Mladen Turk wrote: > Costin Manolache wrote: > >> +1 on removing from trunk. >> >> IMHO AJP as a protocol is a dead end - it is not worth extending, >> > > Agreed. It has to many limitations to satisfy the > modern webserver/backend connector. > > and certainly not >> worth creating a new protocol. We need to pick one of >> thrift/protobuf/hessian for >> marshaling, and start doing some mux-ing in the protocol. >> > > All those framework you mention are just helpers for > *building* the custom protocol. They actually mandate > that we will have one but now hidden inside some IDL > language description. Any such framework makes > almost impossible to change the protocol specification > while preserving backward compatibility > (One huge problem why AJP is not usable any more) You preserve backward compat by keeping the protocol stable and supporting all methods you define in the IDL. What is needed is bi-directional communication between web server and tomcat - so you can do all the extensions on the list. The stability of the actual method definition is probably more important than the protocol itself - if we start using an IDL, it is even possible to expose the methods over multiple protocols if there is a compelling reason. > > > I'm kind of more fun of > http://www.wsgi.org/wsgi/ > > At least it's human readable and already working :) Well, the spec is not so human readable :-) - can you point me to the description of the communication protocol - i.e. the marshaling, framing, etc ? I don't mind 'human readable', or even supporting multiple formats. Are they multiplexing or request-waiting-response ? Do they already define methods for load balancing, etc ? If yes - sure, it's one valid option. Costin > > Regards > -- > ^(TM) > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Proposal] Remove older of the two BIO AJP connectors
Costin Manolache wrote: +1 on removing from trunk. IMHO AJP as a protocol is a dead end - it is not worth extending, Agreed. It has to many limitations to satisfy the modern webserver/backend connector. and certainly not worth creating a new protocol. We need to pick one of thrift/protobuf/hessian for marshaling, and start doing some mux-ing in the protocol. All those framework you mention are just helpers for *building* the custom protocol. They actually mandate that we will have one but now hidden inside some IDL language description. Any such framework makes almost impossible to change the protocol specification while preserving backward compatibility (One huge problem why AJP is not usable any more) I'm kind of more fun of http://www.wsgi.org/wsgi/ At least it's human readable and already working :) Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
+1 on removing from trunk. IMHO AJP as a protocol is a dead end - it is not worth extending, and certainly not worth creating a new protocol. We need to pick one of thrift/protobuf/hessian for marshaling, and start doing some mux-ing in the protocol. If we end up using MINA or some other RPC - all the better, as long as it has a decent native side. Costin On Fri, Apr 3, 2009 at 2:20 AM, Rainer Jung wrote: > On 27.03.2009 21:22, Mark Thomas wrote: > > Mladen Turk wrote: > >> Mark Thomas wrote: > >>> All, > >>> > >>> I have been looking at trunk for opportunities to remove duplicate / > >>> obsolete > >>> code. We currently have two BIO AJP connectors: > >>> - org.apache.jk.server.JkCoyoteHandler > >>> - org.apache.coyote.ajp.AjpProtocol > >>> > >>> I would like to remove org.apache.jk.server.JkCoyoteHandler and > >>> associated classes. > >>> > >>> What do folks think? > >>> > >> Ain't those used for 5.5? > >> You can however just remove them from the build. > >> Other option is to copy them to the 5.5 and not referencing > >> the connectors for those set of classes. > > > > Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend > > changing 5.5.x or 6.0.x > > +1: I support removing org.apache.jk.server.JkCoyoteHandler from TC > trunk (aka TC 7). > > I would be interested in any comments, what kind of feature or quality > might still be missing in org.apache.coyote.ajp.AjpProtocol and help to > implement them (if any). > > Rémy, others: are there improvements that should be done to this connector? > > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Proposal] Remove older of the two BIO AJP connectors
On Fri, 2009-04-03 at 11:20 +0200, Rainer Jung wrote: > Rémy, others: are there improvements that should be done to this connector? This is AJP, and the connector is made up from creative cut & pasting. So it could be missing stuff. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On 27.03.2009 21:22, Mark Thomas wrote: > Mladen Turk wrote: >> Mark Thomas wrote: >>> All, >>> >>> I have been looking at trunk for opportunities to remove duplicate / >>> obsolete >>> code. We currently have two BIO AJP connectors: >>> - org.apache.jk.server.JkCoyoteHandler >>> - org.apache.coyote.ajp.AjpProtocol >>> >>> I would like to remove org.apache.jk.server.JkCoyoteHandler and >>> associated classes. >>> >>> What do folks think? >>> >> Ain't those used for 5.5? >> You can however just remove them from the build. >> Other option is to copy them to the 5.5 and not referencing >> the connectors for those set of classes. > > Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend > changing 5.5.x or 6.0.x +1: I support removing org.apache.jk.server.JkCoyoteHandler from TC trunk (aka TC 7). I would be interested in any comments, what kind of feature or quality might still be missing in org.apache.coyote.ajp.AjpProtocol and help to implement them (if any). Rémy, others: are there improvements that should be done to this connector? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: I doubt you will get veto if this starts as module project that can be used as drop-in component without changing the overall API. Under Tomcat umbrella we have now : - a Servlet container - an Apache/IIS connector (jk) - a native connector First guess, but I may be wrong, why not split in 3 projects ? Don't think that's a smart way to move right now because a) We simply don't have resources (community) for that. However at least part of the native connector could in the future go somewhere else (commons probably). I'm trying to create one or two commons projects that would allow more easier java/native integration, and if someone creates a workable MINA based connector, native is already in there. JK is different, because we still don't know which way to go in the future. If we came up with something bright and shiny like JK3, and create enough community we could ask for a TLP status and move the 1.2 native code to that new project, leaving tomcat to what it essentially is (servlet container) Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
> I doubt you will get veto if this starts as module project > that can be used as drop-in component without changing the > overall API. > > The guys from MINA even use our tomcat native for high > performance polling, so it's natural in a way to cooperate > more closely. > > We can use two current BIO connectors as part of the core, > and see how MINA can be used for async connectors. > Since it supports both Java NIO and Tomcat Native, it's > just cooperating with the guys and see what we would need > to use it more effectively (and how at the first place :) Thanks Mladen, happy to get a such positive feedback ! Under Tomcat umbrella we have now : - a Servlet container - an Apache/IIS connector (jk) - a native connector First guess, but I may be wrong, why not split in 3 projects ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. It takes outreach to make that happen. Mark isn't offbase, keep posting your wishes here, but if you want to make it happen, engage these other communities. I could engage but there should be an acceptance here. I couldn't attract Mina/Felix people and got a veto here, it will be unfair and unproductive for other commuties. I call for openess and if it receive a positive feedback here, we could next contact others ASF projects. I doubt you will get veto if this starts as module project that can be used as drop-in component without changing the overall API. The guys from MINA even use our tomcat native for high performance polling, so it's natural in a way to cooperate more closely. We can use two current BIO connectors as part of the core, and see how MINA can be used for async connectors. Since it supports both Java NIO and Tomcat Native, it's just cooperating with the guys and see what we would need to use it more effectively (and how at the first place :) Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
>> It's disturbing that you fail to mention Geronimo altogether. If we can't >> have cohesion within the ASF - you expect to create it externally? >> > > I think that where Henri is going is that Tomcat has always been dependant > on corporate sponsorship. First on Sun (who forked the code to GlassFish), > then on JBoss (whom I understand from messages on the list has forked as > well), and currently on SpringSource. Geronimo has historically considered > Tomcat as a poor cousin ;), and preferred Jetty. Admittedly that has > changed recently, and we're getting more patch submissions from Geronimo. > But AFAIK, there are still no committers to both Tomcat and Geronimo. Right Bill. And I wonder why Geronimo, OSGI, Eclipse or GWT select Jetty ? It's a good product but may be it's more attractive and open to newcomers ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
> It's disturbing that you fail to mention Geronimo altogether. If we can't > have cohesion within the ASF - you expect to create it externally? It wasn't a list of J2EE engine but a list of applications/corps who drive Tomcat life. And Geronimo didn't take/fork/guide Tomcat isn't it ? :) >> That's my wishes for Tomcat, not just code, bits and specs compliance, >> but recreate a new wider commiters/contributors community. > > It takes outreach to make that happen. Mark isn't offbase, keep posting > your wishes here, but if you want to make it happen, engage these other > communities. I could engage but there should be an acceptance here. I couldn't attract Mina/Felix people and got a veto here, it will be unfair and unproductive for other commuties. I call for openess and if it receive a positive feedback here, we could next contact others ASF projects. > The ASF isn't about being the only code solution. It's about collaboration > to create what the active developers determine is the best solution. If > anything is lacking in Tomcat, address it, and work with others to address > it, but certainly don't spend your time wishing things were otherwise. Yes ASF is not the only solution, but with the rich apis/tools/peoples in various ASF projects, it seems to me more elegant and pragmatic to involve ASFers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
"William A. Rowe, Jr." wrote in message news:49d55f2c.2030...@rowe-clan.net... > Henri Gomez wrote: >> >> If i recall the tomcat story (10 years). >> Today >> >> Sun has it's own implementation, Grizzly. >> Jboss forked tc code in it's own implémentation for AS. >> Spring Source embed it in it's DM server. > > It's disturbing that you fail to mention Geronimo altogether. If we can't > have cohesion within the ASF - you expect to create it externally? > I think that where Henri is going is that Tomcat has always been dependant on corporate sponsorship. First on Sun (who forked the code to GlassFish), then on JBoss (whom I understand from messages on the list has forked as well), and currently on SpringSource. Geronimo has historically considered Tomcat as a poor cousin ;), and preferred Jetty. Admittedly that has changed recently, and we're getting more patch submissions from Geronimo. But AFAIK, there are still no committers to both Tomcat and Geronimo. >> That's my wishes for Tomcat, not just code, bits and specs compliance, >> but recreate a new wider commiters/contributors community. > > It takes outreach to make that happen. Mark isn't offbase, keep posting > your wishes here, but if you want to make it happen, engage these other > communities. > > The ASF isn't about being the only code solution. It's about > collaboration > to create what the active developers determine is the best solution. If > anything is lacking in Tomcat, address it, and work with others to address > it, but certainly don't spend your time wishing things were otherwise. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: > > If i recall the tomcat story (10 years). > Today > > Sun has it's own implementation, Grizzly. > Jboss forked tc code in it's own implémentation for AS. > Spring Source embed it in it's DM server. It's disturbing that you fail to mention Geronimo altogether. If we can't have cohesion within the ASF - you expect to create it externally? > That's my wishes for Tomcat, not just code, bits and specs compliance, > but recreate a new wider commiters/contributors community. It takes outreach to make that happen. Mark isn't offbase, keep posting your wishes here, but if you want to make it happen, engage these other communities. The ASF isn't about being the only code solution. It's about collaboration to create what the active developers determine is the best solution. If anything is lacking in Tomcat, address it, and work with others to address it, but certainly don't spend your time wishing things were otherwise. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Mark Thomas wrote: Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. Mina is also ASF and why not speak with the MINA team ? May be they'll more than interesting working on such area. Again, if *you* want to pursue this / think this is a good idea - *you* need to invest the time to pursue this / persuade others that it is worth them pursuing. The problem with any framework is that with all the benefits you pay the price. One is that it contain things you will absolutely never need or use, and the second is that you depend on the framework, so anything you need to add or fix its other community dependent. Unless at least three of us become the mina's pmc members that can push for a release, we would put ourself is the 'plug and pray' situation. However that doesn't prevent anyone with extra time and will to create the mina based connector, but of course as a separate module not part of the core. In time this would eventually lead to satisfying the first requirement, and eventually use it as core component. IMHO we had a good example in http-client, where two communities even under ASF umbrella simply couldn't cooperate. The guys from http commons simply choose to take a blank sheet of paper and completely break the backward compatibility, leaving us sticked to version 3. Of course we could use version 4 (it was beta for how long, two years or more) since now released, but who can assure us version 4.1 won't make all our work obsolete again. And, regarding maven, I absolutely agree with Mark. There is nothing wrong with ant, and really see no reason why would the switch be needed. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: >>> May be being the RI prevents major evolution/révolution ? >> Tomcat isn't the RI and hasn't been for some time. > > Up to 2.5/2.1 ? > >>> Tomcat Light is a good idea but only costin works on it. >> If you like the idea, help him out. > > Why should we still get this kind of reply on Tomcat list ? ;-( Because you are criticizing the direction things are going but making little to no contribution to moving Tomcat forward in the direction you think it should be going. > The idea is to attract a community on it and GSoC is a great opportunity. +1. Any help/advice you want to give to the prospective students would be very much appreciated as they as their questions on the dev list. >>> Asf has a great server framework, mina, but it's not used by Tc. >> I'm not sure building Tomcat on top of another framework is a good idea. If >> you >> have a PoC that shows otherwise that would be very interesting. > > Mina is also ASF and why not speak with the MINA team ? > May be they'll more than interesting working on such area. Again, if *you* want to pursue this / think this is a good idea - *you* need to invest the time to pursue this / persuade others that it is worth them pursuing. >>> Maven has never been used as build system and 10 years after Tc is still >>> stick with ant. > >> And what, exactly is wrong with Ant? It does the job we need it to do and it >> is >> far simpler to work with than Maven. This has been discussed before and the >> conclusion then was that the pain wasn't worth the gain. I don't see anything >> that has changed that. > > That's a reccurent part of the problem on the tomcat-dev list. > Why should we change something working ? Exactly. If it ain't broke don't fix it. There is always scope to do things better but the reward has to be worth the effort required. That case has yet to be made (in my view) for switching to Maven. > Maven arguments exist and you just can't say, it works with ant why > changing anything ? They do but the last time someone tried to make them, the argument wasn't compelling. > How many major projects in ASF (and elsewhere) switched to Maven ? No idea. > It will really help make Tomcat more modular, maven modules will split > the complexity in more parts. > And modules could became bundles easily via maven-felix-plugin. > >>> No luck, we couldn't use the maven modules approach for tc. Modules >>> would have helped the transition to Bundle. >> We don't have to use Maven to build a more modular Tomcat. > > May be but with a big build.xml instead of many small poms ? Which is fine by me right now. If there was a compelling argument to switch to Maven and go through the associated learning curve I would be +1 for the switch. I have yet to see a compelling argument. >>> That's my wishes for Tomcat, not just code, bits and specs compliance, >>> but recreate a new wider commiters/contributors community. >> So start making contributions to take Tomcat in this direction. > > I'll be happy to spent some personal time (not during my job time), Great. > but there should be a real acceptance here. You need to make the case for each of these changes. If there is a case then I for one would be +1. > Maven use : > > I worked some times ago on a mavenised version of Tomcat. > As it required a different source structure, I moved all sources to a > new layout. > > And to automatize it, you should use some ant script before so it's > clearly unfriendly (and unusual for maven developpers > conventions/standardization) As I said above, I don't see that the pain is worth the gain. I'm happy to be convinced otherwise. > Openess : > > Did the Tomcat community want to share and use components ? > > Mina could provide some components. > Felix could use Tomcat as it HTTP implementation instead of Jetty. I'm all for code re-use where we can. That is one of the reasons I am working on the Commons components that Tomcat uses. Any re-use is always going to be a trade off. Each case will need to be looked at on it's merits but where it makes sense to do so it will get a +1 from me. > OSGI : > > Did Tomcat 7 should use an OSGI core and use it dynamic bundles model > to load on demand module (a sort of on demand HTTPd modules) ? That is an awfully big step from where we are now. How do you propose we get from where we are to a set of bundles running on an OSGI framework? > The discussion is open and please don't just reply "make contributions". > > Ideas are contributions, not just code. +1 but without contributions the ideas are unlikely to get anywhere Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
>> May be being the RI prevents major evolution/révolution ? > > Tomcat isn't the RI and hasn't been for some time. Up to 2.5/2.1 ? >> Tomcat Light is a good idea but only costin works on it. > If you like the idea, help him out. Why should we still get this kind of reply on Tomcat list ? ;-( I won't speak for Costin but I didn't have such time to works on Tomcat. And for such project we need full time people involved. The idea is to attract a community on it and GSoC is a great opportunity. >> Asf has a great server framework, mina, but it's not used by Tc. > I'm not sure building Tomcat on top of another framework is a good idea. If > you > have a PoC that shows otherwise that would be very interesting. Mina is also ASF and why not speak with the MINA team ? May be they'll more than interesting working on such area. >> Osgi is getting more and more adoption > True. Indeed >> and Eclipse or Felix select Jetty as their http implementation. > Back to size / ease of embedding. > >> Maven has never been used as build system and 10 years after Tc is still >> stick with ant. > And what, exactly is wrong with Ant? It does the job we need it to do and it > is > far simpler to work with than Maven. This has been discussed before and the > conclusion then was that the pain wasn't worth the gain. I don't see anything > that has changed that. That's a reccurent part of the problem on the tomcat-dev list. Why should we change something working ? Maven arguments exist and you just can't say, it works with ant why changing anything ? How many major projects in ASF (and elsewhere) switched to Maven ? It will really help make Tomcat more modular, maven modules will split the complexity in more parts. And modules could became bundles easily via maven-felix-plugin. >> No luck, we couldn't use the maven modules approach for tc. Modules >> would have helped the transition to Bundle. > We don't have to use Maven to build a more modular Tomcat. May be but with a big build.xml instead of many small poms ? Probably it didn't help/allow new peoples join the project and add some fresh air & ideas ? >>> We could probably be more responsive / encouraging. I am trying to get >>> a couple >>> of GSoC projects for Tomcat this year. Hopefully that will generate >>> something. >> >> Good but may be too late ;-( > Better late than never. >> That's why i wonder if tc 7.0 will just implements what 3.0 >> requierements or will be a major evolution ? >> >> My wishes for tc 7 and later : >> >> A very small core for faster start and better embedded use. >> >> Valves/filters/whatever should be just plugable modules. Here also OSGI >> / Felix / ServiceMixKernel have many good ideas to use. >> >> Maven as a build system should be seriously reconsidered, modularity, >> artifacts depots, osgi support will be easier >> >> Tomcat project should use and share components from others ASF >> projects, Mina, Felix, ServiceMix, Commons have great stuff that could >> (should) be used. It will even be attractive for new commiters from >> these ASF project. >> >> That's my wishes for Tomcat, not just code, bits and specs compliance, >> but recreate a new wider commiters/contributors community. > > So start making contributions to take Tomcat in this direction. I'll be happy to spent some personal time (not during my job time), but there should be a real acceptance here. Maven use : I worked some times ago on a mavenised version of Tomcat. As it required a different source structure, I moved all sources to a new layout. And to automatize it, you should use some ant script before so it's clearly unfriendly (and unusual for maven developpers conventions/standardization) Openess : Did the Tomcat community want to share and use components ? Mina could provide some components. Felix could use Tomcat as it HTTP implementation instead of Jetty. ... OSGI : Did Tomcat 7 should use an OSGI core and use it dynamic bundles model to load on demand module (a sort of on demand HTTPd modules) ? The discussion is open and please don't just reply "make contributions". Ideas are contributions, not just code. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: >>> May be being the Servlet/JSP RI didn't allow too much 'revolution'. >> Have you read the 3.0 spec draft? There is a fair amount of change. >> Whether it >> is good or not is a different question though. > > I read it. It's a new spec. Dot. > > May be being the RI prevents major evolution/révolution ? Tomcat isn't the RI and hasn't been for some time. > Tomcat Light is a good idea but only costin works on it. If you like the idea, help him out. > Asf has a great server framework, mina, but it's not used by Tc. I'm not sure building Tomcat on top of another framework is a good idea. If you have a PoC that shows otherwise that would be very interesting. > Osgi is getting more and more adoption True. > and Eclipse or Felix select Jetty as their http implementation. Back to size / ease of embedding. > Maven has never been used as build system and 10 years after Tc is still > stick with ant. And what, exactly is wrong with Ant? It does the job we need it to do and it is far simpler to work with than Maven. This has been discussed before and the conclusion then was that the pain wasn't worth the gain. I don't see anything that has changed that. > No luck, we couldn't use the maven modules approach for tc. Modules > would have helped the transition to Bundle. We don't have to use Maven to build a more modular Tomcat. >>> Probably it didn't help/allow new peoples join the project and add >>> some fresh air & ideas ? >> We could probably be more responsive / encouraging. I am trying to get >> a couple >> of GSoC projects for Tomcat this year. Hopefully that will generate >> something. > > Good but may be too late ;-( Better late than never. > That's why i wonder if tc 7.0 will just implements what 3.0 > requierements or will be a major evolution ? > > My wishes for tc 7 and later : > > A very small core for faster start and better embedded use. > > Valves/filters/whatever should be just plugable modules. Here also OSGI > / Felix / ServiceMixKernel have many good ideas to use. > > Maven as a build system should be seriously reconsidered, modularity, > artifacts depots, osgi support will be easier > > Tomcat project should use and share components from others ASF > projects, Mina, Felix, ServiceMix, Commons have great stuff that could > (should) be used. It will even be attractive for new commiters from > these ASF project. > > That's my wishes for Tomcat, not just code, bits and specs compliance, > but recreate a new wider commiters/contributors community. So start making contributions to take Tomcat in this direction. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Le 30 mars 09 à 18:00, Mark Thomas a écrit : Henri Gomez wrote: Ain't those used for 5.5? You can however just remove them from the build. Other option is to copy them to the 5.5 and not referencing the connectors for those set of classes. Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend changing 5.5.x or 6.0.x What's the state for Tomcat 7 ? Development is happening in trunk. I wonder if they're allready some discussions/plans about it. Not just technical/specs/RI plans but more generally what could/ should Tomcat 7 be ? /trunk/TOMCAT-7-RELEASE-PLAN.txt I could see that many projects (GWT/Eclipse), are now switching to Jetty (which is great container also). Did we miss something at some time ? Ease of embedding? Size? Of course better embedding support, smallest (may be less jars), a faster start mode (with minimal features). And also more openess to new commiters and external projects. I still think that what make httpd success is it's modular approach with a well known internal request process. Many modules raised outside core httpd team/project and some even joined it later. And it get a bigger commiters community with new ideas and constant évolution/révolution. May be being the Servlet/JSP RI didn't allow too much 'revolution'. Have you read the 3.0 spec draft? There is a fair amount of change. Whether it is good or not is a different question though. I read it. It's a new spec. Dot. May be being the RI prevents major evolution/révolution ? Tomcat Light is a good idea but only costin works on it. Asf has a great server framework, mina, but it's not used by Tc. Osgi is getting more and more adoption and Eclipse or Felix select Jetty as their http implementation. Maven has never been used as build system and 10 years after Tc is still stick with ant. No luck, we couldn't use the maven modules approach for tc. Modules would have helped the transition to Bundle. Probably it didn't help/allow new peoples join the project and add some fresh air & ideas ? We could probably be more responsive / encouraging. I am trying to get a couple of GSoC projects for Tomcat this year. Hopefully that will generate something. Good but may be too late ;-( If i recall the tomcat story (10 years). Code given by Sun to ASF. Tc 3.0 ? Some ASF refactoring later came Tc 3.1 and then 3.2. First 'fork', tc 3.3 - tc 4.0. One project with individuals, the other with Sun commiters. tc 4.1 and then 5.0 ended the fork. But it became a Jboss commiters driven project. 5.5 and later 6.0 show the switch from Jboss to SpringSource 'leadership'. Today Sun has it's own implementation, Grizzly. Jboss forked tc code in it's own implémentation for AS. Spring Source embed it in it's DM server. Differents historicals leaders, differents commercial purposes/ requierements may explain why evolution/revolution has never been really well accepted ;( That's why i wonder if tc 7.0 will just implements what 3.0 requierements or will be a major evolution ? My wishes for tc 7 and later : A very small core for faster start and better embedded use. Valves/filters/whatever should be just plugable modules. Here also OSGI / Felix / ServiceMixKernel have many good ideas to use. Maven as a build system should be seriously reconsidered, modularity, artifacts depots, osgi support will be easier Tomcat project should use and share components from others ASF projects, Mina, Felix, ServiceMix, Commons have great stuff that could (should) be used. It will even be attractive for new commiters from these ASF project. That's my wishes for Tomcat, not just code, bits and specs compliance, but recreate a new wider commiters/contributors community. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Henri Gomez wrote: >>> Ain't those used for 5.5? >>> You can however just remove them from the build. >>> Other option is to copy them to the 5.5 and not referencing >>> the connectors for those set of classes. >> Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend >> changing 5.5.x or 6.0.x > > What's the state for Tomcat 7 ? Development is happening in trunk. > I wonder if they're allready some discussions/plans about it. > > Not just technical/specs/RI plans but more generally what could/should > Tomcat 7 be ? /trunk/TOMCAT-7-RELEASE-PLAN.txt > I could see that many projects (GWT/Eclipse), are now switching to > Jetty (which is great container also). > > Did we miss something at some time ? Ease of embedding? Size? > May be being the Servlet/JSP RI didn't allow too much 'revolution'. Have you read the 3.0 spec draft? There is a fair amount of change. Whether it is good or not is a different question though. > Probably it didn't help/allow new peoples join the project and add > some fresh air & ideas ? We could probably be more responsive / encouraging. I am trying to get a couple of GSoC projects for Tomcat this year. Hopefully that will generate something. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
>> Ain't those used for 5.5? >> You can however just remove them from the build. >> Other option is to copy them to the 5.5 and not referencing >> the connectors for those set of classes. > > Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend > changing 5.5.x or 6.0.x What's the state for Tomcat 7 ? I wonder if they're allready some discussions/plans about it. Not just technical/specs/RI plans but more generally what could/should Tomcat 7 be ? I could see that many projects (GWT/Eclipse), are now switching to Jetty (which is great container also). Did we miss something at some time ? May be being the Servlet/JSP RI didn't allow too much 'revolution'. Probably it didn't help/allow new peoples join the project and add some fresh air & ideas ? What's your opinion about it ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Mladen Turk wrote: > Mark Thomas wrote: >> All, >> >> I have been looking at trunk for opportunities to remove duplicate / >> obsolete >> code. We currently have two BIO AJP connectors: >> - org.apache.jk.server.JkCoyoteHandler >> - org.apache.coyote.ajp.AjpProtocol >> >> I would like to remove org.apache.jk.server.JkCoyoteHandler and >> associated classes. >> >> What do folks think? >> > > Ain't those used for 5.5? > You can however just remove them from the build. > Other option is to copy them to the 5.5 and not referencing > the connectors for those set of classes. Sorry - should have been clear. I only meant in Tomcat 7. I didn't intend changing 5.5.x or 6.0.x Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Mark Thomas wrote: All, I have been looking at trunk for opportunities to remove duplicate / obsolete code. We currently have two BIO AJP connectors: - org.apache.jk.server.JkCoyoteHandler - org.apache.coyote.ajp.AjpProtocol I would like to remove org.apache.jk.server.JkCoyoteHandler and associated classes. What do folks think? Ain't those used for 5.5? You can however just remove them from the build. Other option is to copy them to the 5.5 and not referencing the connectors for those set of classes. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
