RE: my proposal for re implement tomcat valves as filters
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
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: my proposal for re implement tomcat valves as filters
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org