Home » Eclipse Projects » Equinox » OSGi Servlet Filter Proposal
| OSGi Servlet Filter Proposal [message #61517] |
Wed, 15 February 2006 01:32  |
Eclipse User |
|
|
|
Originally posted by: jfallows.txesystems.com
Folks,
After studying the equinox codebase, I've come up with the following
proposal to add support for Servlet Filters. Please let me know what
you think.
* Request flow
The processing flow for a particular request must be well defined so
that Filters are executed at the appropriate times, either inside the
OSGi Web Plugin, or in the host container, depending on where they are
registered.
o Host J2EE Filters (including BridgeFilter)
o Embedded OSGi Filters
o Host J2EE BridgeServlet
o Embedded OSGi Servlets
* Initialization
Move the FrameworkLauncher initialization code into
BridgeServletContextListener, shared as a ServletContext attribute by
both BridgeServlet and BridgeFilter. One reference to
ServletConfig.getInitParameter() in BridgeServlet can be changed to
ServletContext.getInitParameter(), used to configure the framework controls.
* BridgeFilter
Create a new class, BridgeFilter, to invoke embedded OSGi Filters.
public class BridgeFilter implements Filter
{
public static void registerFilterDelegate(
Filter filter)
{ ... }
...
}
This code follows a similar design pattern as BridgeServlet, after
refactoring the FrameworkLauncher initialization into
BridgeServletContextListener.
* Bridge Web Application
The following shows the web.xml configuration needed by the OSGi Bridge.
<filter>
<filter-name>equinox</filter-name>
<filter-class>
org.eclipse.equinox.servlet.bridge.BridgeFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>equinox</filter-name>
<servlet-name>equinox</servlet-name>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
<listener>
org.eclipse.equinox.servlet.bridge.BridgeServletContextListe ner
</listener>
<servlet>
<servlet-name>equinox</servlet-name>
<servlet-class>
org.eclipse.equinox.servlet.bridge.BridgeServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>equinox</servlet-name>
<url-pattern>/bridge</url-pattern>
</servlet-mapping>
Notice that the BridgeFilter is registered for REQUEST, FORWARD and
INCLUDE dispatchers, so that the OSGi HttpService can decide if any OSGi
Filters are registered for the current dispatcher. The ERROR dispatcher
is not currently necessary as that would require <web-app><error-page>
integration as well to be useful.
* FilterChainRegistration
It is legal for multiple Filter instances to be registered under the
same alias, but they all form a single FilterChain and are chained in
registration order via FilterChain.doFilter(ServletRequest,
ServletResponse).
During OSGi Web Plugin startup, a FilterChainRegistration is lazily
created for the given alias, and the registered Filter instance is
added, resulting in a well-defined FilterChain for the given alias and
dispatcher type (REQUEST, INCLUDE, FORWARD).
* ProxyFilter
An instance of the ProxyFilter class acts as the delegate for all
BridgeFilter requests.
public class ProxyFilter implements Filter
{
public void init(
FilterConfig config)
{...}
public void destroy()
{...}
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain chain)
{
// lookup up FilterChainRegistration
// registration.handleRequest(request, response)
// chain.doFilter(request, response);
}
public void registerFilter(
String alias,
Filter filter,
Dictionary initParams,
int dispatcherMask,
HttpContext context) throws ServletException, NamespaceException
{ ... }
...
}
* Filter execution during Forward and Include
The RequestDispatcher API supports the concept of forwarding and
including other request paths, causing Filters that are registered as
FORWARD or INCLUDE dispatchers to be invoked before any Servlet
processing the request.
Such flows need to be routed through the main Web application
RequestDispatcher but directed to the BridgeFilter and BridgeServlet to
get the right processing sequence.
Therefore ServletContext.getRequestDispatcher(String
contextRelativePath) is prefixed with the URL mapping for the
BridgeServlet ("/bridge" in the above example) when retrieved from
inside an OSGi Web Plugin. Similarly, the same mapping prefix is
required when ServletRequest.getRequestDispatcher(String path) is called
with an "absolute" path (leading / char).
The returned RequestDispatcher can set the value of a Servlet attribute
to "FORWARD" or "INCLUDE" when either the forward() or include() method
is called respectively.
* Extension point configuration
A new filters extension point follows similar syntax to the servlets
extension point syntax, with additional information about the dispatcher
registration (REQUEST, INCLUDE, FORWARD).
public class FilterManager implements ExtensionPointTracker.Listener
{
...
}
A new FilterManager class parses the extension point syntax and
registers the Filter with the HttpService.
* HttpService
The HttpService needs to be enhanced to support Filter registration.
public interface HttpService
{
public final int DISPATCHER_REQUEST = 0;
public final int DISPATCHER_FORWARD = 1;
public final int DISPATCHER_INCLUDE = 2;
public void registerFilter(
String alias,
Filter filter,
Dictionary initParams,
int dispatcherMask,
HttpContext context) throws ServletException, NamespaceException;
// existing methods
}
I'll be prototyping this implementation while awaiting feedback from the
group. For now, I'll leave the HttpService API unchanged and cast to
HttpServiceImpl in FilterManager to register each embedded OSGi Filter.
Let me know what you think.
Kind Regards,
John Fallows.
--
Author: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044
|
|
|
| Re: OSGi Servlet Filter Proposal [message #61569 is a reply to message #61517] |
Wed, 15 February 2006 13:56  |
| Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
Hi John,
These look good and are both worth looking at.
Could you open "two" Enhancement Requests for this.
One for the refactoring the framework launcher to a context listener.
The other for adding filter support.
Thanks.
-Simon
"John R. Fallows" <jfallows@txesystems.com> wrote in message
news:dsu0c2$o1i$1@utils.eclipse.org...
> Folks,
>
> After studying the equinox codebase, I've come up with the following
> proposal to add support for Servlet Filters. Please let me know what
> you think.
>
> * Request flow
> The processing flow for a particular request must be well defined so
> that Filters are executed at the appropriate times, either inside the
> OSGi Web Plugin, or in the host container, depending on where they are
> registered.
>
> o Host J2EE Filters (including BridgeFilter)
> o Embedded OSGi Filters
> o Host J2EE BridgeServlet
> o Embedded OSGi Servlets
>
> * Initialization
> Move the FrameworkLauncher initialization code into
> BridgeServletContextListener, shared as a ServletContext attribute by
> both BridgeServlet and BridgeFilter. One reference to
> ServletConfig.getInitParameter() in BridgeServlet can be changed to
> ServletContext.getInitParameter(), used to configure the framework
controls.
>
> * BridgeFilter
> Create a new class, BridgeFilter, to invoke embedded OSGi Filters.
>
> public class BridgeFilter implements Filter
> {
> public static void registerFilterDelegate(
> Filter filter)
> { ... }
>
> ...
> }
>
> This code follows a similar design pattern as BridgeServlet, after
> refactoring the FrameworkLauncher initialization into
> BridgeServletContextListener.
>
> * Bridge Web Application
> The following shows the web.xml configuration needed by the OSGi Bridge.
>
> <filter>
> <filter-name>equinox</filter-name>
> <filter-class>
> org.eclipse.equinox.servlet.bridge.BridgeFilter
> </filter-class>
> </filter>
>
> <filter-mapping>
> <filter-name>equinox</filter-name>
> <servlet-name>equinox</servlet-name>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>FORWARD</dispatcher>
> <dispatcher>INCLUDE</dispatcher>
> </filter-mapping>
>
> <listener>
> org.eclipse.equinox.servlet.bridge.BridgeServletContextListe ner
> </listener>
>
> <servlet>
> <servlet-name>equinox</servlet-name>
> <servlet-class>
> org.eclipse.equinox.servlet.bridge.BridgeServlet
> </servlet-class>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>equinox</servlet-name>
> <url-pattern>/bridge</url-pattern>
> </servlet-mapping>
>
> Notice that the BridgeFilter is registered for REQUEST, FORWARD and
> INCLUDE dispatchers, so that the OSGi HttpService can decide if any OSGi
> Filters are registered for the current dispatcher. The ERROR dispatcher
> is not currently necessary as that would require <web-app><error-page>
> integration as well to be useful.
>
> * FilterChainRegistration
> It is legal for multiple Filter instances to be registered under the
> same alias, but they all form a single FilterChain and are chained in
> registration order via FilterChain.doFilter(ServletRequest,
> ServletResponse).
>
> During OSGi Web Plugin startup, a FilterChainRegistration is lazily
> created for the given alias, and the registered Filter instance is
> added, resulting in a well-defined FilterChain for the given alias and
> dispatcher type (REQUEST, INCLUDE, FORWARD).
>
> * ProxyFilter
> An instance of the ProxyFilter class acts as the delegate for all
> BridgeFilter requests.
>
> public class ProxyFilter implements Filter
> {
> public void init(
> FilterConfig config)
> {...}
>
> public void destroy()
> {...}
>
> public void doFilter(
> ServletRequest request,
> ServletResponse response,
> FilterChain chain)
> {
> // lookup up FilterChainRegistration
> // registration.handleRequest(request, response)
> // chain.doFilter(request, response);
> }
>
> public void registerFilter(
> String alias,
> Filter filter,
> Dictionary initParams,
> int dispatcherMask,
> HttpContext context) throws ServletException, NamespaceException
> { ... }
>
> ...
> }
>
> * Filter execution during Forward and Include
> The RequestDispatcher API supports the concept of forwarding and
> including other request paths, causing Filters that are registered as
> FORWARD or INCLUDE dispatchers to be invoked before any Servlet
> processing the request.
>
> Such flows need to be routed through the main Web application
> RequestDispatcher but directed to the BridgeFilter and BridgeServlet to
> get the right processing sequence.
>
> Therefore ServletContext.getRequestDispatcher(String
> contextRelativePath) is prefixed with the URL mapping for the
> BridgeServlet ("/bridge" in the above example) when retrieved from
> inside an OSGi Web Plugin. Similarly, the same mapping prefix is
> required when ServletRequest.getRequestDispatcher(String path) is called
> with an "absolute" path (leading / char).
>
> The returned RequestDispatcher can set the value of a Servlet attribute
> to "FORWARD" or "INCLUDE" when either the forward() or include() method
> is called respectively.
>
> * Extension point configuration
> A new filters extension point follows similar syntax to the servlets
> extension point syntax, with additional information about the dispatcher
> registration (REQUEST, INCLUDE, FORWARD).
>
> public class FilterManager implements ExtensionPointTracker.Listener
> {
> ...
> }
>
> A new FilterManager class parses the extension point syntax and
> registers the Filter with the HttpService.
>
> * HttpService
> The HttpService needs to be enhanced to support Filter registration.
>
> public interface HttpService
> {
> public final int DISPATCHER_REQUEST = 0;
> public final int DISPATCHER_FORWARD = 1;
> public final int DISPATCHER_INCLUDE = 2;
>
> public void registerFilter(
> String alias,
> Filter filter,
> Dictionary initParams,
> int dispatcherMask,
> HttpContext context) throws ServletException, NamespaceException;
>
> // existing methods
> }
>
> I'll be prototyping this implementation while awaiting feedback from the
> group. For now, I'll leave the HttpService API unchanged and cast to
> HttpServiceImpl in FilterManager to register each embedded OSGi Filter.
>
> Let me know what you think.
>
> Kind Regards,
> John Fallows.
> --
> Author: Pro JSF and Ajax: Building Rich Internet Components
> http://apress.com/book/bookDisplay.html?bID=10044
|
|
|
| Re: OSGi Servlet Filter Proposal [message #61616 is a reply to message #61569] |
Wed, 15 February 2006 17:38 |
| Eclipse User |
|
|
|
Originally posted by: jfallows.txesystems.com
Hi Simon,
Simon Kaegi wrote:
> Hi John,
>
> These look good and are both worth looking at.
Thanks, I'll submit a patch for each as they become functional. :)
> Could you open "two" Enhancement Requests for this.
> One for the refactoring the framework launcher to a context listener.
> The other for adding filter support.
Done.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=128067
Refactor FrameworkLauncher startup into ServletContextListener
https://bugs.eclipse.org/bugs/show_bug.cgi?id=128068
Servlet Filter support for Equinox
Kind Regards,
John Fallows.
>
> Thanks.
> -Simon
>
> "John R. Fallows" <jfallows@txesystems.com> wrote in message
> news:dsu0c2$o1i$1@utils.eclipse.org...
>> Folks,
>>
>> After studying the equinox codebase, I've come up with the following
>> proposal to add support for Servlet Filters. Please let me know what
>> you think.
>>
>> * Request flow
>> The processing flow for a particular request must be well defined so
>> that Filters are executed at the appropriate times, either inside the
>> OSGi Web Plugin, or in the host container, depending on where they are
>> registered.
>>
>> o Host J2EE Filters (including BridgeFilter)
>> o Embedded OSGi Filters
>> o Host J2EE BridgeServlet
>> o Embedded OSGi Servlets
>>
>> * Initialization
>> Move the FrameworkLauncher initialization code into
>> BridgeServletContextListener, shared as a ServletContext attribute by
>> both BridgeServlet and BridgeFilter. One reference to
>> ServletConfig.getInitParameter() in BridgeServlet can be changed to
>> ServletContext.getInitParameter(), used to configure the framework
> controls.
>> * BridgeFilter
>> Create a new class, BridgeFilter, to invoke embedded OSGi Filters.
>>
>> public class BridgeFilter implements Filter
>> {
>> public static void registerFilterDelegate(
>> Filter filter)
>> { ... }
>>
>> ...
>> }
>>
>> This code follows a similar design pattern as BridgeServlet, after
>> refactoring the FrameworkLauncher initialization into
>> BridgeServletContextListener.
>>
>> * Bridge Web Application
>> The following shows the web.xml configuration needed by the OSGi Bridge.
>>
>> <filter>
>> <filter-name>equinox</filter-name>
>> <filter-class>
>> org.eclipse.equinox.servlet.bridge.BridgeFilter
>> </filter-class>
>> </filter>
>>
>> <filter-mapping>
>> <filter-name>equinox</filter-name>
>> <servlet-name>equinox</servlet-name>
>> <dispatcher>REQUEST</dispatcher>
>> <dispatcher>FORWARD</dispatcher>
>> <dispatcher>INCLUDE</dispatcher>
>> </filter-mapping>
>>
>> <listener>
>> org.eclipse.equinox.servlet.bridge.BridgeServletContextListe ner
>> </listener>
>>
>> <servlet>
>> <servlet-name>equinox</servlet-name>
>> <servlet-class>
>> org.eclipse.equinox.servlet.bridge.BridgeServlet
>> </servlet-class>
>> </servlet>
>>
>> <servlet-mapping>
>> <servlet-name>equinox</servlet-name>
>> <url-pattern>/bridge</url-pattern>
>> </servlet-mapping>
>>
>> Notice that the BridgeFilter is registered for REQUEST, FORWARD and
>> INCLUDE dispatchers, so that the OSGi HttpService can decide if any OSGi
>> Filters are registered for the current dispatcher. The ERROR dispatcher
>> is not currently necessary as that would require <web-app><error-page>
>> integration as well to be useful.
>>
>> * FilterChainRegistration
>> It is legal for multiple Filter instances to be registered under the
>> same alias, but they all form a single FilterChain and are chained in
>> registration order via FilterChain.doFilter(ServletRequest,
>> ServletResponse).
>>
>> During OSGi Web Plugin startup, a FilterChainRegistration is lazily
>> created for the given alias, and the registered Filter instance is
>> added, resulting in a well-defined FilterChain for the given alias and
>> dispatcher type (REQUEST, INCLUDE, FORWARD).
>>
>> * ProxyFilter
>> An instance of the ProxyFilter class acts as the delegate for all
>> BridgeFilter requests.
>>
>> public class ProxyFilter implements Filter
>> {
>> public void init(
>> FilterConfig config)
>> {...}
>>
>> public void destroy()
>> {...}
>>
>> public void doFilter(
>> ServletRequest request,
>> ServletResponse response,
>> FilterChain chain)
>> {
>> // lookup up FilterChainRegistration
>> // registration.handleRequest(request, response)
>> // chain.doFilter(request, response);
>> }
>>
>> public void registerFilter(
>> String alias,
>> Filter filter,
>> Dictionary initParams,
>> int dispatcherMask,
>> HttpContext context) throws ServletException, NamespaceException
>> { ... }
>>
>> ...
>> }
>>
>> * Filter execution during Forward and Include
>> The RequestDispatcher API supports the concept of forwarding and
>> including other request paths, causing Filters that are registered as
>> FORWARD or INCLUDE dispatchers to be invoked before any Servlet
>> processing the request.
>>
>> Such flows need to be routed through the main Web application
>> RequestDispatcher but directed to the BridgeFilter and BridgeServlet to
>> get the right processing sequence.
>>
>> Therefore ServletContext.getRequestDispatcher(String
>> contextRelativePath) is prefixed with the URL mapping for the
>> BridgeServlet ("/bridge" in the above example) when retrieved from
>> inside an OSGi Web Plugin. Similarly, the same mapping prefix is
>> required when ServletRequest.getRequestDispatcher(String path) is called
>> with an "absolute" path (leading / char).
>>
>> The returned RequestDispatcher can set the value of a Servlet attribute
>> to "FORWARD" or "INCLUDE" when either the forward() or include() method
>> is called respectively.
>>
>> * Extension point configuration
>> A new filters extension point follows similar syntax to the servlets
>> extension point syntax, with additional information about the dispatcher
>> registration (REQUEST, INCLUDE, FORWARD).
>>
>> public class FilterManager implements ExtensionPointTracker.Listener
>> {
>> ...
>> }
>>
>> A new FilterManager class parses the extension point syntax and
>> registers the Filter with the HttpService.
>>
>> * HttpService
>> The HttpService needs to be enhanced to support Filter registration.
>>
>> public interface HttpService
>> {
>> public final int DISPATCHER_REQUEST = 0;
>> public final int DISPATCHER_FORWARD = 1;
>> public final int DISPATCHER_INCLUDE = 2;
>>
>> public void registerFilter(
>> String alias,
>> Filter filter,
>> Dictionary initParams,
>> int dispatcherMask,
>> HttpContext context) throws ServletException, NamespaceException;
>>
>> // existing methods
>> }
>>
>> I'll be prototyping this implementation while awaiting feedback from the
>> group. For now, I'll leave the HttpService API unchanged and cast to
>> HttpServiceImpl in FilterManager to register each embedded OSGi Filter.
>>
>> Let me know what you think.
>>
>> Kind Regards,
>> John Fallows.
>> --
>> Author: Pro JSF and Ajax: Building Rich Internet Components
>> http://apress.com/book/bookDisplay.html?bID=10044
>
>
--
Author: Pro JSF and Ajax: Building Rich Internet Components
http://apress.com/book/bookDisplay.html?bID=10044
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 01:47:15 GMT 2024
Powered by FUDForum. Page generated in 0.03205 seconds |
] 
Search
Help
Register
Login
Home
