class FacesContextProducer {
@Produces @RequestScoped FacesContext getFacesContext() {
return FacesContext.getCurrentInstance();
}
}
On Tue, Nov 10, 2009 at 5:25 PM, Steven Boscarine
<steven.boscarine(a)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(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org