[weld-dev] @Inject FacesContext

[Gavin King]

  class FacesContextProducer {
     @Produces @RequestScoped FacesContext getFacesContext() {
         return FacesContext.getCurrentInstance();
      }
  }


On Tue, Nov 10, 2009 at 5:25 PM, Steven Boscarine
<steven.boscarine at childrens.harvard.edu> wrote:
> Hello All,
> If it matters any, I agree with Dan 100% and think many users will
> appreciate the change.
> It is a convenient timesaver and makes it easy to mock the FacesContext for
> unit tests.
> I presently get around it by abstracting code that does useful work away
> from the FacesContext and into a separate class that is decoupled from JSF
> or any web frameworks.  The downside is this approach is that I often end up
> with modules with a few too many classes to do a simple job.
>
> Although this is probably far-fetched, aren't there threading concerns with
> mocking FacesContext.setCurrentInstance() ?  Doesn't that mean two tests
> running in parallel cannot have different FacesContext objects (without
> locking)?
> We are very concerned with scalability in the heathcare field and do
> multi-threaded TestNG integration tests regularly.
> Thanks,
> Steven Boscarine
> Pr Software Engineer
> Children's Hospital Boston
>
>
> Dan Allen wrote:
>>
>> I couldn't imagine writing a JSF application without accessing
>> FacesContext. It's not even a matter of a perfect world vs the real world.
>> The FacesContext was designed to be accessed. Add faces messages. Push a
>> file. Check the value of a UIComponent for cross field validation. I'm sure
>> I could think of many other cases.
>>
>> Having to access using FacesContext.getCurrentInstance() is so ugly.
>>
>> -Dan
>>
>
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org