Re: [weld-dev] @Inject FacesContext
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