[weld-dev] @Inject FacesContext

[Steven Boscarine]

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
>