tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: my proposal for "re implement tomcat valves as filters"
Date Thu, 02 Apr 2009 10:20:13 GMT
anas Ahmed wrote:
> 
>> Mark Thomas wrote :
>>
>>
>> Feedback:
>> Good first draft. There are a coupe of areas I would like to see more detail on:
>>
>>    1. Impact of Servlet 3 and async processing.
> 
> Lack of asynchronous support in the Servlet 2.5 specification has caused 
> server vendors to devise workarounds by weaving proprietary classes 
> and interfaces that promote scalable Comet programming into 
> the Servlet 2.5 API.As Servlet 3 support async processing, 
> I think there is no need to Comet programming 
> (CometEvent, CometFilter, CometFilterChain, CometProcessor, 
> CometEventImpl, CometConnectionManagerValve classes are no longer needed).
> I think others features like annotations will not be useful

That wasn't what I meant. What I meant was "What needs to be done to make the
filters compatible with ASync support and are there any valves where ASync
support may cause issues?"

>>    2. The filter requires a ServletContext at initialisation. How might you
>>       handle this for a filter defined at the Engine/Host level?
> 
> My idea to handle this is as follow - tracks other component that can be defined at Context
and Host, 
> for example  HttpServlet (<servlet> </servlet> tag).- read HttpServlet implantation
and specification, then try to make 
> implementation to FilterClass implement  Filter interface, same as 
> HttpServlet, so Filter can be defined at host level. 
> Then try to make necessary modification on Filter to wide it at Engine level.

If I have understood you correctly, you want to modify the Filter interface.
This is not possible. The Filter interface is defined by the spec and cannot be
changed. Also you appear to indicate that Servlet's can be defined at the Host
level. This is not the case.

>>    3. Authentication will require access to Tomcat internals. Is a filter the
>>       right solution for these valves? What might a better approach be? What
>>       about JSR 196?
> still searching , can you explain more.

JSR196 is the "Java Authentication Service Provider Interface for Containers".
This might be an alternative solution for the authentication valves rather than
converting them to filters.

Geronimo may already have a solution for this. I haven't checked.

http://jcp.org for more info.

Mark

> 
>> I would also suggest you spend a little time to build Tomcat from source
>> (http://svn.apache.org/repos/asf/tomcat/trunk). Once you have Tomcat building,
>> I'd suggest looking at the AccessLogValve and how that might be converted to a
>> Filter to give you a better ide of the issues involved and how long things might
>> take.
> i will do but there is no lot time ,Friday is the last day for submit proposal ,what
is the necessary modifications to add them to proposal ?
Proposals can be modified after the submission date as you continue to discuss
your ideas with us.

> finally how many students will work in this project?
One.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message