Is the following injection going to be supported in Java EE 6? @Inject FacesContext ctx; Because I can't even begin to count how many times I'm going to need that when developing apps. Probably the #1 injection in JSF apps. (True, I could make a producer method myself, but so will the n-thousand other JSF developers). -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Why do you want to access them directly? Surely that's what we're trying to get away from? On Tue, Nov 10, 2009 at 4:02 PM, Nicklas Karlsson <nickarls(a)gmail.com&gt; wrote: > ...and the HTTP session and request. Probably something most > frameworks will provide if nothing else. > > On Tue, Nov 10, 2009 at 10:50 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: >> Is the following injection going to be supported in Java EE 6? >> >> @Inject FacesContext ctx; >> >> Because I can't even begin to count how many times I'm going to need that >> when developing apps. Probably the #1 injection in JSF apps. >> >> (True, I could make a producer method myself, but so will the n-thousand >> other JSF developers). >> >> -Dan >> >> -- >> Dan Allen >> Senior Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> http://www.google.com/profiles/dan.j.allen >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> > > > > -- > --- > Nik > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

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

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

This reminds me of Ubuntu's Paper Cuts (https://lists.ubuntu.com/archives/ubuntu-devel/2009-June/028354.html) Little things really add up after awhile and drive away users to Spring, Groovy, or even off Java.   I know of many python and ruby shops in Boston that are run by frustrated former Java programmers. In my opinion, it's really worth your time to consider ways to make CDI as friendly to users as you possibly can. Those elements of polish really help new users and make using your product a much nicer experience and will drive Weld adoption, Gavin King book sales, etc :) I really think your users will thank you. Gavin King wrote: >   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&gt; 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 >>> >>> >> > > > > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Is the following injection going to be supported in Java EE 6? @Inject FacesContext ctx; Because I can't even begin to count how many times I'm going to need that when developing apps. Probably the #1 injection in JSF apps. (True, I could make a producer method myself, but so will the n-thousand other JSF developers). -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Gavin King wrote: > > I didn't put it in, since I figured it was hard to justify that this > is better than FacesContext.getCurrentInstance(). > How would one unit test a class that has such a call?

That just seems to me like the opposite of what we are trying to achieve with injection. I would argue against HttpSession and request (I'm assuming ServletRequest) because that is the point of FacesContext...to abstract that away somewhat. But you still need FacesContext. -Dan On Tue, Nov 10, 2009 at 4:51 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > > Call FacesContext.setCurrentInstance() :-) > > On Tue, Nov 10, 2009 at 4:29 PM, Steven Boscarine > <steven.boscarine(a)childrens.harvard.edu&gt; wrote: > > > > Gavin King wrote: > >> > >> I didn't put it in, since I figured it was hard to justify that this > >> is better than FacesContext.getCurrentInstance(). > >> > > > > How would one unit test a class that has such a call? > > > > > > > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

I don't post much here but I felt obliged to comment on this thread (and my other message awaits for moderation). I have to agree with Dan. This probably will be one of the most used injections. The reason for injection is to be able to stub and unit test easily. Right now the getCurrentInstance() is static and you'd need to use ugly constructions to replace it with a stub (I am not saying it's impossible but I am talking here from the feedback I've gathered and personal experience when unit testing pure JSF). If faces context will be injectable it will make many people happy :) Btw, FacesContext.setCurrentInstance() is protected (so you can't just call it) which means you'd need to make some 'suboptimal' constructions to make it work in unit tests. Best regards, Siarhei Dudzin On Tue, Nov 10, 2009 at 10:51 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > > Call FacesContext.setCurrentInstance() :-) > > On Tue, Nov 10, 2009 at 4:29 PM, Steven Boscarine > <steven.boscarine(a)childrens.harvard.edu&gt; wrote: > > > > Gavin King wrote: > >> > >> I didn't put it in, since I figured it was hard to justify that this > >> is better than FacesContext.getCurrentInstance(). > >> > > > > How would one unit test a class that has such a call? > > > > > > > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev

> The reason for injection is to be able to stub and unit test easily. Right > now the getCurrentInstance() is static and you'd need to use ugly > constructions to replace it with a stub (I am not saying it's impossible but > I am talking here from the feedback I've gathered and personal experience > when unit testing pure JSF). And the other, more subtle annoyance is the you have to eventually make that decision in a method when to create a local variable for FacesContext because your code is getting too verbose. FacesContext ctx = FacesContext.getCurrentInstance(); I hate writing that line. Every time I do, I think to myself "I hate this stupid line of code." -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen