You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by anas Ahmed <an...@msn.com> on 2009/04/01 09:33:58 UTC
my proposal for "re implement tomcat valves as filters"
I have posted my application on the GSOC site for the project "re-implement
tomcat valves as filters"
please give your suggestion and participate with your ideas to make
this proposal better
Thanks
Anas Ahmed
_________________________________________________________________
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
Re: my proposal for "re implement tomcat valves as filters"
Posted by Mark Thomas <ma...@apache.org>.
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
RE: my proposal for "re implement tomcat valves as filters"
Posted by anas Ahmed <an...@msn.com>.
> 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
> 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.
> 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.
> 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 ?
finally how many students will work in this project?
Thanks
Anas Ahmed
_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_042009
Re: my proposal for "re implement tomcat valves as filters"
Posted by Mark Thomas <ma...@apache.org>.
anas Ahmed wrote:
> I have posted my application on the GSOC site for the project "re-implement
> tomcat valves as filters"
> please give your suggestion and participate with your ideas to make
> this proposal better
Feedback provided in the GSOC app and repeated below. Feel free to discuss your
ideas regarding these questions on the dev list.
Mark
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.
2. The filter requires a ServletContext at initialisation. How might you
handle this for a filter defined at the Engine/Host level?
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?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org