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
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
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
On Mon, Apr 6, 2009 at 3:06 PM, Filip Hanik - Dev Lists
devli...@hanik.comwrote:
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
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
On Sat, Apr 4, 2009 at 1:10 AM, Mladen Turk mt...@apache.org 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
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
On Sat, Apr 4, 2009 at 8:12 AM, Mladen Turk mt...@apache.org 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
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
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
Costin Manolache wrote:
On Sat, Apr 4, 2009 at 9:03 AM, David Jencks david_jen...@yahoo.com 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
On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk mt...@apache.org wrote:
Costin Manolache wrote:
On Sat, Apr 4, 2009 at 9:03 AM, David Jencks david_jen...@yahoo.com
wrote:
My understanding of 'what we talk about' is what to do with mod_jk -
deprecate/remove old code, add few features
to
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
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),
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
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
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
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
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
+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 -
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
On Fri, Apr 3, 2009 at 10:24 AM, Mladen Turk mt...@apache.org 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
Le 30 mars 09 à 18:00, Mark Thomas ma...@apache.org 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
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
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
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
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
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
William A. Rowe, Jr. wr...@rowe-clan.net 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
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
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
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
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
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
34 matches
Mail list logo
