[Orchestra] FrameworkAdapter tidyup

2007-09-10 Thread Simon Kitching
Hi, Currently the class FrameworkAdapterServletFilter caches the HttpServletRequest and HttpServletResponse objects so that they can be accessed by the JsfFrameworkAdapter class. This seems a little clumsy; it would be nicer if the JsfFrameworkAdapter class was itself responsible for caching

Re: [Orchestra] FrameworkAdapter tidyup

2007-09-10 Thread Mario Ivankovits
] Date: Monday, Sep 10, 2007 6:46 pm Subject: [Orchestra] FrameworkAdapter tidyup To: Reply-MyFaces Development dev@myfaces.apache.orgTo: dev@myfaces.apache.org Hi, Currently the class FrameworkAdapterServletFilter caches the HttpServletRequest and HttpServletResponse objects so

[orchestra] FrameworkAdapter setup (was Re: [orchestra] servlet filters ..)

2007-08-19 Thread Mario Ivankovits
Hi! So I am fine by adding some Framework-Adapter specified stuff to the OrchestraServletFilter - instead of creating a new filter. Isn't OrchestraServletFilter currently optional [1]? Using it to set up the FrameworkAdapter would make it mandatory... Sorry Mario, I should have

Re: [orchestra] FrameworkAdapter setup (was Re: [orchestra] servlet filters ..)

2007-08-19 Thread simon
On Sun, 2007-08-19 at 13:07 +0200, Mario Ivankovits wrote: I am currently cleaning up the RequestParameterProvider (as proposed by Matthias). I'll now provide a FacesContextFactory and the filter. When testing the filter I've found, that it also requires the FrameworkAdapter which requires the

[orchestra] FrameworkAdapter

2007-08-18 Thread simon
Hi, The FrameworkAdapter class currently uses a static variable to find its singleton object. However static variables are tricky in unit testing, and are a problem when a library is deployed via a shared classloader. However the whole point of the FrameworkAdapter is that it is accessable from

Re: [orchestra] FrameworkAdapter

2007-08-18 Thread Mario Ivankovits
Hi! The FrameworkAdapter class currently uses a static variable to find its singleton object. However static variables are tricky in unit testing, and are a problem when a library is deployed via a shared classloader. The only thing which comes to mind is using a ThreadLocal, and having a