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
Kirk True wrote:
Hi all,
Can anyone suggest some trivial newbie projects for the Tomcat code
base? I don't care how menial it is, typo changes, logging, testing
(something specific), etc. I've been lurking on the list for awhile and
want to start getting my hands dirty.
Thanks,
Kirk
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
Hello, Dear All,
First, thank you very much for you valuable comments, Mark.
I've revised my project plan based on the comments of Mark, since I could
not edit my proposal any longer, I wrote the revised version of project plan
in a comment of my proposal, you can find it for certain by
On Apr 4, 2009, at 3:01 PM, Xie Xiaodong wrote:
Hello, Dear All,
First, thank you very much for you valuable comments, Mark.
I've revised my project plan based on the comments of Mark, since
I could
not edit my proposal any longer, I wrote the revised version of
project plan
in a
Thank you, David.
After having a glance at JSR-196 Specification, the intuitive of design
decision is to implement the built in auth methods (BASIC, DIGEST, FORM,
CLIENT_CERT) of Tomcat Valve with ServerAuthModule. And I agreed the
difficulty of implementing the auth function into filter you
Although the specification does not cover whether the *ServerAuthModule *should
be stateful or stateless, I think we'd better keep it stateless for
scalability.
2009/4/5 Xie Xiaodong xxd82...@gmail.com
Thank you, David.
After having a glance at JSR-196 Specification, the intuitive of
Added:
tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java?rev=762039view=auto
14 matches
Mail list logo
