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: Tomcat newbie developer tasks?
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 > > Kirk True wrote: >> Hi all, >> >> Is there a list of tasks with which one can begin to get familiar with >> the Tomcat source and contribute? Most of the bugs in the Bugzilla >> look difficult (at least without some guidance) or already have patches. Welcome back. These should be be a good place to get started: https://issues.apache.org/bugzilla/show_bug.cgi?id=46958 https://issues.apache.org/bugzilla/show_bug.cgi?id=46924 https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 Ask questions here, add patches to bugzilla and ping the list if you don't see any response to a proposed patch after a few days. 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
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: 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 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
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 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
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
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
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 > >
GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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 searching the "Show Student Proposal" page with "xiaodong xie wrote". Sorry for this inconvenience. I am now getting myself familiar with the Servlet Container Profile of JSR-196 in order to move the Authentication funcationality of valve into some independent structure consistence with JSR-196. This part will be added into my project proposal in some comment later. Any more comments, feedback and criticism to my proposal are welcomed. -- Sincerely yours and Best Regards, Xie Xiaodong
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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 comment of my proposal, you can find it for certain by
searching the
"Show Student Proposal" page with "xiaodong xie wrote". Sorry for this
inconvenience.
I am now getting myself familiar with the Servlet Container
Profile of
JSR-196 in order to move the Authentication funcationality of valve
into
some independent structure consistence with JSR-196. This part will
be added
into my project proposal in some comment later.
Any more comments, feedback and criticism to my proposal are
welcomed.
While it is possible to implement the built in auth methods (BASIC,
DIGEST, FORM, CLIENT_CERT) as jaspi auth modules it's not as
efficient as having a more tomcat-specific auth method. The important
part is really having a validate request method called before the web
resource constraint check and a secure response method called after
the request has been processed. There are a lot of opportunities for
improved caching if you don't follow the jaspi model exactly, mostly
by letting the authenticator return the user identity rather than
passing in a brand new Subject instance for each request.
I recommend that the valve or filter look something like this:
check user data constraints
Status status = validate request
if (status == success) {
check web resource constraints
process request
secure response
}
//otherwise the validate request call will have set up an appropriate
response to continue the authentication message exchange
"validate request" and "secure response" are delegated to some kind of
authenticator similar to but more efficient than a jaspi auth context
constraint checking can either be (abstract) methods on the (base)
valve or delegated to some other object. The point here is to easily
support both constraint based checking (as done in tomcat today) and
jacc based permission checking (as done in geronimo and presumably
other javaee integrations such as jboss)
thanks
david jencks
--
Sincerely yours and Best Regards,
Xie Xiaodong
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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 mentioned in
previous mail, so I decided to implementing so independent structure
consistent with JSR-196. As this specification specified, the API is
something like this:
1. AuthConfigFactory factory = AuthConfigFactory.getFactory();
2. AuthConfigProvider provider =
factory.getConfigProvider(layer,appID,listener);
3. ServerAuthConfig config =
provider.getServerAuthConfig(layer,appID,cbh)
4. String authContextID = config.getAuthContextID(messageInfo);
5. ServerAuthContext context =
config.getAuthContext(authContextID,subject,properties);
6. context.secureResponse(messageInfo,subject);
And the functionality of formal Tomcat valve will be refactored into
ServerAuthModule which will be encapsulated by ServerAuthContext.
I'll check where caching could be used for the efficiency.
And I think it is import to go with the specification since it will allow
other developer to contribute their own code, and our code could also be
used by others.
ps: I greatly agree with the structure you give in previous mail:
check user data constraints
Status status = validate request
if (status == success) {
check web resource constraints
process request
secure response
}
2009/4/5 David Jencks
>
> 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 comment of my proposal, you can find it for certain by searching the
>> "Show Student Proposal" page with "xiaodong xie wrote". Sorry for this
>> inconvenience.
>> I am now getting myself familiar with the Servlet Container Profile of
>> JSR-196 in order to move the Authentication funcationality of valve into
>> some independent structure consistence with JSR-196. This part will be
>> added
>> into my project proposal in some comment later.
>> Any more comments, feedback and criticism to my proposal are welcomed.
>>
>
> While it is possible to implement the built in auth methods (BASIC, DIGEST,
> FORM, CLIENT_CERT) as jaspi auth modules it's not as efficient as having a
> more tomcat-specific auth method. The important part is really having a
> validate request method called before the web resource constraint check and
> a secure response method called after the request has been processed. There
> are a lot of opportunities for improved caching if you don't follow the
> jaspi model exactly, mostly by letting the authenticator return the user
> identity rather than passing in a brand new Subject instance for each
> request.
>
> I recommend that the valve or filter look something like this:
>
> check user data constraints
> Status status = validate request
> if (status == success) {
> check web resource constraints
> process request
> secure response
> }
> //otherwise the validate request call will have set up an appropriate
> response to continue the authentication message exchange
>
> "validate request" and "secure response" are delegated to some kind of
> authenticator similar to but more efficient than a jaspi auth context
>
> constraint checking can either be (abstract) methods on the (base) valve or
> delegated to some other object. The point here is to easily support both
> constraint based checking (as done in tomcat today) and jacc based
> permission checking (as done in geronimo and presumably other javaee
> integrations such as jboss)
>
> thanks
> david jencks
>
>
>>
>> --
>> Sincerely yours and Best Regards,
>> Xie Xiaodong
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
Re: GSOC: Convert current Tomcat valves to Servlet Filters, I revised my project plan based on the comments of Mark
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
> 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 mentioned in
> previous mail, so I decided to implementing so independent structure
> consistent with JSR-196. As this specification specified, the API is
> something like this:
>
>
>1. AuthConfigFactory factory = AuthConfigFactory.getFactory();
>2. AuthConfigProvider provider =
>factory.getConfigProvider(layer,appID,listener);
>3. ServerAuthConfig config =
>provider.getServerAuthConfig(layer,appID,cbh)
>4. String authContextID = config.getAuthContextID(messageInfo);
>5. ServerAuthContext context =
>config.getAuthContext(authContextID,subject,properties);
>6. context.secureResponse(messageInfo,subject);
>
> And the functionality of formal Tomcat valve will be refactored into
> ServerAuthModule which will be encapsulated by ServerAuthContext.
>
> I'll check where caching could be used for the efficiency.
>
> And I think it is import to go with the specification since it will allow
> other developer to contribute their own code, and our code could also be
> used by others.
>
> ps: I greatly agree with the structure you give in previous mail:
>
> check user data constraints
> Status status = validate request
> if (status == success) {
> check web resource constraints
> process request
> secure response
> }
>
>
>
>
>
>
> 2009/4/5 David Jencks
>
>
>> 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 comment of my proposal, you can find it for certain by searching the
>>> "Show Student Proposal" page with "xiaodong xie wrote". Sorry for this
>>> inconvenience.
>>> I am now getting myself familiar with the Servlet Container Profile of
>>> JSR-196 in order to move the Authentication funcationality of valve into
>>> some independent structure consistence with JSR-196. This part will be
>>> added
>>> into my project proposal in some comment later.
>>> Any more comments, feedback and criticism to my proposal are welcomed.
>>>
>>
>> While it is possible to implement the built in auth methods (BASIC,
>> DIGEST, FORM, CLIENT_CERT) as jaspi auth modules it's not as efficient as
>> having a more tomcat-specific auth method. The important part is really
>> having a validate request method called before the web resource constraint
>> check and a secure response method called after the request has been
>> processed. There are a lot of opportunities for improved caching if you
>> don't follow the jaspi model exactly, mostly by letting the authenticator
>> return the user identity rather than passing in a brand new Subject instance
>> for each request.
>>
>> I recommend that the valve or filter look something like this:
>>
>> check user data constraints
>> Status status = validate request
>> if (status == success) {
>> check web resource constraints
>> process request
>> secure response
>> }
>> //otherwise the validate request call will have set up an appropriate
>> response to continue the authentication message exchange
>>
>> "validate request" and "secure response" are delegated to some kind of
>> authenticator similar to but more efficient than a jaspi auth context
>>
>> constraint checking can either be (abstract) methods on the (base) valve
>> or delegated to some other object. The point here is to easily support both
>> constraint based checking (as done in tomcat today) and jacc based
>> permission checking (as done in geronimo and presumably other javaee
>> integrations such as jboss)
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> --
>>> Sincerely yours and Best Regards,
>>> Xie Xiaodong
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
>
> --
> Sincerely yours and Best Regards,
> Xie Xiaodong
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
svn commit: r762039 [2/2] - in /tomcat/trunk/modules/tomcat-lite/test: ./ org/ org/apache/ org/apache/tomcat/ org/apache/tomcat/lite/ org/apache/tomcat/test/ org/apache/tomcat/test/watchdog/ org/apach
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=762039&view=auto
==
---
tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java
(added)
+++
tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java
Sun Apr 5 01:36:27 2009
@@ -0,0 +1,103 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tomcat.test.watchdog;
+
+import java.util.Date;
+import java.util.Locale;
+import java.util.TimeZone;
+
+/**
+ * A parser for date strings commonly found in http and email headers that
+ * follow various RFC conventions. Given a date-string, the parser will
+ * attempt to parse it by trying matches with a set of patterns, returning
+ * null on failure, a Date object on success.
+ *
+ * @author Ramesh.Mandava
+ */
+public class RfcDateParser {
+
+private boolean isGMT = false;
+
+static final String[] standardFormats = {
+ "', 'dd-MMM-yy HH:mm:ss z", // RFC 850 (obsoleted by 1036)
+ "', 'dd-MMM-yy HH:mm:ss", // ditto but no tz. Happens too often
+ "EEE', 'dd-MMM- HH:mm:ss z", // RFC 822/1123
+ "EEE', 'dd MMM HH:mm:ss z", // REMIND what rfc? Apache/1.1
+ "', 'dd MMM HH:mm:ss z", // REMIND what rfc? Apache/1.1
+ "EEE', 'dd MMM hh:mm:ss z", // REMIND what rfc? Apache/1.1
+ "', 'dd MMM hh:mm:ss z", // REMIND what rfc? Apache/1.1
+ "EEE MMM dd HH:mm:ss z ", // Date's string output format
+ "EEE MMM dd HH:mm:ss ", // ANSI C asctime format()
+ "EEE', 'dd-MMM-yy HH:mm:ss", // No time zone 2 digit year RFC 1123
+ "EEE', 'dd-MMM- HH:mm:ss" // No time zone RFC 822/1123
+};
+
+/* because there are problems with JDK1.1.6/SimpleDateFormat with
+ * recognizing GMT, we have to create this workaround with the following
+ * hardcoded strings */
+static final String[] gmtStandardFormats = {
+ "',' dd-MMM-yy HH:mm:ss 'GMT'", // RFC 850 (obsoleted by 1036)
+ "EEE',' dd-MMM- HH:mm:ss 'GMT'", // RFC 822/1123
+ "EEE',' dd MMM HH:mm:ss 'GMT'", // REMIND what rfc? Apache/1.1
+ "',' dd MMM HH:mm:ss 'GMT'", // REMIND what rfc? Apache/1.1
+ "EEE',' dd MMM hh:mm:ss 'GMT'", // REMIND what rfc? Apache/1.1
+ "',' dd MMM hh:mm:ss 'GMT'", // REMIND what rfc? Apache/1.1
+ "EEE MMM dd HH:mm:ss 'GMT' " // Date's string output format
+};
+
+String dateString;
+
+public RfcDateParser(String dateString) {
+ this.dateString = dateString.trim();
+ if (this.dateString.indexOf("GMT") != -1) {
+ isGMT = true;
+ }
+}
+
+public Date getDate() {
+
+int arrayLen = isGMT ? gmtStandardFormats.length :
standardFormats.length;
+for (int i = 0; i < arrayLen; i++) {
+Date d = null;
+
+if (isGMT) {
+d = tryParsing(gmtStandardFormats[i]);
+} else {
+d = tryParsing(standardFormats[i]);
+}
+if (d != null) {
+return d;
+}
+
+}
+
+return null;
+}
+
+private Date tryParsing(String format) {
+
+ java.text.SimpleDateFormat df = new java.text.SimpleDateFormat(format,
Locale.US);
+ if (isGMT) {
+ df.setTimeZone(TimeZone.getTimeZone("GMT"));
+ }
+ try {
+ return df.parse(dateString);
+ } catch (Exception e) {
+ return null;
+ }
+}
+} /* class RfcDateParser */
Propchange:
tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java
--
svn:eol-style = native
Propchange:
tomcat/trunk/modules/tomcat-lite/test/org/apache/tomcat/test/watchdog/RfcDateParser.java
--
svn:e
RE: [GSOC] Filters & Async Support in Servlet 3.0
Two Scenarios of thread per request :- 1- if the request send directly to server without filter:- When a connection is idle between requests, the thread can be recycled, and the connection is placed in a centralized NIO select set to detect new requests without consuming a separate thread. 2- if the request chain to filter :- when a connection is idle between requests , the thread is still allocated to the particular request since the servlet 3.0 specification says :"A Filter and the target servlet or resource at the end of the filter chain must execute in the same invocation thread" It is look like thread per connection. if that is false what do you understand from this sentence :"A Filter and the target servlet or resource at the end of the filter chain must execute in the same invocation thread" ?? I wrote proposal for the second project "improve the JMX support within Apache Tomcat" i'm waiting for your feedback and i need your advice about which project i have to put my focus because i'm student and the time is valuable Anas _ Quick access to your favorite MSN content and Windows Live with Internet Explorer 8. http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A
