[jira] Created: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling

["Peter Ertl (JIRA)" <ji...@apache.org>]

programmatical addition or removal of filters prior to wicket filter request handling
-------------------------------------------------------------------------------------

                 Key: WICKET-3219
                 URL: https://issues.apache.org/jira/browse/WICKET-3219
             Project: Wicket
          Issue Type: New Feature
            Reporter: Peter Ertl
            Assignee: Peter Ertl
             Fix For: 1.5-M4
         Attachments: filter-extension.patch

[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
	@Override
	protected void init()
	{
		super.init();

		XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies

		try
		{
			getWicketFilter().addInterceptor(filter);
			////////// getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
		}
		catch (ServletException e)
		{
		  // standard exception which can be thrown from javax.servlet.Filter#init(FilterConfig)
			log.error(e.getMessage(), e);
		}
}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Juergen Donnerstag (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966273#action_12966273 ] 

Juergen Donnerstag commented on WICKET-3219:
--------------------------------------------

That was my first idea as well. I reverted it because in my opinion we don't need it. WebApplication.newWebRequest(HttpServletRequest) is the place where you can do all that already. To register a "filter" simply replace newWebRequest with you own implementation. Wrap the servletrequest with your "filter", create a new WebRequest with that and your done. Have a look at the testcase.

> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Description: 
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)


  was:
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)



> programmatical addition or removal of filters prior to wicket filter request handling
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: filter-extension.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Fix Version/s: 1.5.1

> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>             Fix For: 1.5.1
>
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     MyCustomFilter filter = new MyCustomFilter();
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin MyCustomFilter#doFilter() ->
>         MyCustomFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end MyCustomFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
> - You don't have to touch web.xml ever
> - the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - Migration from non-wicket applications might be easier
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safely at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> IMHO there are plenty of useful use cases.
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl resolved WICKET-3219.
--------------------------------

    Resolution: Won't Fix

> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>             Fix For: 1.5.1
>
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     MyCustomFilter filter = new MyCustomFilter();
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin MyCustomFilter#doFilter() ->
>         MyCustomFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end MyCustomFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
> - You don't have to touch web.xml ever
> - the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - Migration from non-wicket applications might be easier
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safely at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> IMHO there are plenty of useful use cases.
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Attachment: filter-extension.patch

> programmatical addition or removal of filters prior to wicket filter request handling
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>             Fix For: 1.5-M4
>
>         Attachments: filter-extension.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
> 	@Override
> 	protected void init()
> 	{
> 		super.init();
> 		XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies
> 		try
> 		{
> 			getWicketFilter().addInterceptor(filter);
> 			////////// getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
> 		}
> 		catch (ServletException e)
> 		{
> 		  // standard exception which can be thrown from javax.servlet.Filter#init(FilterConfig)
> 			log.error(e.getMessage(), e);
> 		}
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Attachment: interceptors.patch

> programmatical addition or removal of filters prior to wicket filter request handling
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Description: 
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)


  was:
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
	@Override
	protected void init()
	{
		super.init();

		XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies

		try
		{
			getWicketFilter().addInterceptor(filter);
			////////// getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
		}
		catch (ServletException e)
		{
		  // standard exception which can be thrown from javax.servlet.Filter#init(FilterConfig)
			log.error(e.getMessage(), e);
		}
}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)



> programmatical addition or removal of filters prior to wicket filter request handling
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: filter-extension.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Attachment:     (was: filter-extension.patch)

> programmatical addition or removal of filters prior to wicket filter request handling
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Description: 
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    MyCustomFilter filter = new MyCustomFilter();

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin MyCustomFilter#doFilter() ->
        MyCustomFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end MyCustomFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
- You don't have to touch web.xml ever
- the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
- You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
- Migration from non-wicket applications might be easier
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safely at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper

IMHO there are plenty of useful use cases.

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)


  was:
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
- You don't have to touch web.xml ever
- the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
- You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
- Migration from non-wicket applications might be easier
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safely at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper

IMHO there are plenty of useful use cases.

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)



> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     MyCustomFilter filter = new MyCustomFilter();
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin MyCustomFilter#doFilter() ->
>         MyCustomFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end MyCustomFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
> - You don't have to touch web.xml ever
> - the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - Migration from non-wicket applications might be easier
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safely at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> IMHO there are plenty of useful use cases.
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Description: 
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)


  was:
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)



> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Affects Version/s: 1.5-M3
        Fix Version/s:     (was: 1.5-M4)

> programmatical addition or removal of filters prior to wicket filter request handling
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: filter-extension.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
> 	@Override
> 	protected void init()
> 	{
> 		super.init();
> 		XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies
> 		try
> 		{
> 			getWicketFilter().addInterceptor(filter);
> 			////////// getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
> 		}
> 		catch (ServletException e)
> 		{
> 		  // standard exception which can be thrown from javax.servlet.Filter#init(FilterConfig)
> 			log.error(e.getMessage(), e);
> 		}
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Description: 
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
- You don't have to touch web.xml ever
- the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
- You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
- Migration from non-wicket applications might be easier
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safely at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper

IMHO there are plenty of useful use cases.

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)


  was:
[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter using something like

--- sample code ---

public class MyApplication extends WebApplication
{
  @Override
  protected void init()
  {
    super.init();

    XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter

    try
    {
      getWicketFilter().addInterceptor(filter);
      // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
    }
    catch (ServletException e)
    {
      // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
      log.error(e.getMessage(), e);
    }
  }

// ...

}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
  	  end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
	send response to browser

- The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application lifecycle
- You don't have to touch web.xml ever
- You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
- You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)



> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
> - You don't have to touch web.xml ever
> - the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - Migration from non-wicket applications might be easier
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safely at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> IMHO there are plenty of useful use cases.
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-3219:
-------------------------------

    Summary: programmatical add or remove of request filters to intercept requests prior to wicket  (was: programmatical addition or removal of filters prior to wicket filter request handling)

> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request  prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     XForwardFilter filter = new XForwardFilter(); // transparent proxy handling behind front-end proxies, implements javax.servlet.Filter
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin XForwardFilter#doFilter() ->
>         XForwardFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end XForwardFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You don't have to touch web.xml ever
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig))
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safe at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> - the filter class can not be invalid (<filter-class> in web.xml) since it's checked by the compiler
> - Eventually migration from pre-wicket application might be easier
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (WICKET-3219) programmatical add or remove of request filters to intercept requests prior to wicket

["Martijn Dashorst (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martijn Dashorst updated WICKET-3219:
-------------------------------------

    Fix Version/s:     (was: 1.5.1)

> programmatical add or remove of request filters to intercept requests prior to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.patch
>
>
> [full-working patch included]
> I would like to extend WicketFilter so you can add (or remove) standard servlet filters programatically to it. These will filter the request prior to wicket using Filter#doChain(). At the end of the filter chain wicket itself will process the request.
> Usually the wicket request handling looks like this:
>  incoming browser request -> 
>    begin WicketFilter#doFilter ->
>      wicket request processing ->
>    end WicketFilter#doFilter ->
>  send response to browser
> Now when adding standard java.servlet.Filter instances to the WicketFilter using something like
> --- sample code ---
> public class MyApplication extends WebApplication
> {
>   @Override
>   protected void init()
>   {
>     super.init();
>     MyCustomFilter filter = new MyCustomFilter();
>     try
>     {
>       getWicketFilter().addInterceptor(filter);
>       // getWicketFilter().addInterceptor(filter, config); // alternate config (e.g. mock filter config since FilterConfig is just an interface)
>     }
>     catch (ServletException e)
>     {
>       // standard exception thrown from javax.servlet.Filter#init(FilterConfig)
>       log.error(e.getMessage(), e);
>     }
>   }
> // ...
> }
> --- EOF sample code ---
> the processing will change like that:
>   incoming browser request -> 
>     begin WicketFilter#doFilter ->
>       begin MyCustomFilter#doFilter() ->
>         MyCustomFilter processing ->
>         chain.doFilter(request,response) ->
>           invoke wicket request processing ->
>   	  end MyCustomFilter#doFilter() ->
>     end WicketFilter#doFilter ->
> 	send response to browser
> - The filter (= interceptor) will be invoked for the same filter path WicketFilter is configured
> Being able to add filters like this will have the following advantages:
> - The filter can be added or removed anytime during the wicket application lifecycle
> - You can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
> - You don't have to touch web.xml ever
> - the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - Migration from non-wicket applications might be easier
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
> - Tigher integration of the filter with wicket since the application and session is already attached to the current thread context (similar to WicketSessionFilter, but without web.xml fiddling)
> - Plugins can add filters to the application without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safely at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> IMHO there are plenty of useful use cases.
> Please check the patch to get the whole idea.
> Votes and comments are greatly appreciated :-)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira