-
1. Re: Weld issue: Unsatisfied dependencies for type [HttpSession]
nickarls Jan 24, 2011 1:25 AM (in response to witoldsz)It fails because producer method injection points are injection points so it's trying to look for a HttpSession in CDI. That one is no apparently no longer available. Without checking at the code, I guess that between Weld versions used in 3.0 and 3.1, the HttpSession has had a qualifier or something added so it wouldn't collide with user/other stuff.
For JSF you could easily add something like (from the top of my head)
@Produces @RequestScoped public HttpSession getSession()
{
return (HttpSession)FacesContext.getCurrentInstance().getExternalContext().getSession(true);
}
(you can find the Weld forum at http://seamframework.org/Community/WeldUsers for more wizardry questions)
-
2. Weld issue: Unsatisfied dependencies for type [HttpSession]
witoldsz Jan 24, 2011 9:25 AM (in response to nickarls)That is so strange what you have said: "HttpSession is no longer available in CDI"?
Previous versions of Weld were providing HttpSession objects, I have just downloaded the JSR-299 final release documentation and in chapter 6.7 it is said that HttpSession is provided. Isn't that a regression?
As a workaround, I would not mind registering my own factory, but this is not a Seam/JSF application, but a backend serving nothing but JSON (and maybe XML) through JAX-RS.
Thanks,
Witold Szczerba
-
3. Re: Weld issue: Unsatisfied dependencies for type [HttpSession]
nickarls Jan 24, 2011 10:59 AM (in response to witoldsz)Where does it say so? Are you referring to the JSR-299 spec or to the Weld reference docs?
Earlier, Weld exposed the HttpSession producer because it needed it internally anyway but I don't think this is longer the case after the context refactor. Perhaps it has moved to Solder(?). Anyway, if it *would* produce it, you wouldn't get the exception, would you? ;-)
For non-jsf stuff, you could probably have a ThreadLocal<HttpSession> in a WebListener and populate on request creation and expose it with a producer method...
-
4. Re: Weld issue: Unsatisfied dependencies for type [HttpSession]
witoldsz Jan 24, 2011 6:50 PM (in response to nickarls)Nicklas Karlsson wrote:
Where does it say so? Are you referring to the JSR-299 spec or to the Weld reference docs?
Well, in 6.7.2. Session context lifecycle they say the session context (bound to HttpSession) is provided by a built-in context object, so I assumed the HttpSession object itself is available as well, which not only is no longer the case, but also it looks like this huge inconvenient is turned into a feature .
For non-jsf stuff, you could probably have a ThreadLocal<HttpSession> in a WebListener and populate on request creation and expose it with a producer method...
I know that may sound like a lame rant, so I apologize in advance if it does so, but well: Guice, Spring and probably many other Web frameworks' modules provides such a basic infrastructure objects like HttpSession out of the box, because it is really hard to imagine an application, backed by a servlet engine, which does not require them and... here we are with tadaaaa most recent Java EE 6 advertised as a "Everything out-of-the-box" solution and in order to write a simple proof-of-concept application, I am given advice like registering listeners for a HttpSession in ThreadLocal to be returned by a producer method.....
<rhetorical> Don't you think such a infrastructure bindings should be provided to web developer by a framework? </rhetorical>
Thanks,
Witold Szczerba
-
5. Re: Weld issue: Unsatisfied dependencies for type [HttpSession]
witoldsz Jan 24, 2011 7:06 PM (in response to witoldsz)Witold Szczerba wrote:
[...] it is really hard to imagine an application, backed by a servlet engine, which does not require them [this was about: objects like HttpSession] and... here we are with tadaaaa most recent Java EE 6 advertised as a "Everything out-of-the-box" solution and in order to write a simple proof-of-concept application, I am given advice like registering listeners for a HttpSession in ThreadLocal to be returned by a producer method.....I am thinking maybe I am wrong... Maybe I should not put logged user into a HttpSession object, but create a @SessionScoped CurrentUserContext and let the WebUserProvider use it to look for WebUser unstead? But it appears to be redundant, because sooner or later I will need more and more CurrentSomethingContexts so I will end up with one generic CurrentContext with a HashMap inside, used by a number of producers... I need to think a little more about it...
-
6. Re: Weld issue: Unsatisfied dependencies for type [HttpSession]
nickarls Jan 25, 2011 1:20 AM (in response to witoldsz)Your rant would be very on-the-mark if CDI would be a web framework. But it's not, it's (mostly) technology agnostic "Context and Dependecy Injection". You can use it in Java SE. It just happens to have pre-implemented lifecycle hooks and context implementations for Servlet because it's a common technology. Seam is a web framework (and it happens to provide that producer in the servlet/faces modules)
-
7. Re: Weld issue: Unsatisfied dependencies for type [HttpSession]
nickarls Jan 25, 2011 1:22 AM (in response to witoldsz)Yes. The fact that CDI doesn't provide producers for any Servlet artifacts is in part because you shouldn't meddle with them directly. Use @SessionScoped components etc instead.
I don't understand the part of "more and more CurrentSomethingContexts", what is your scenario?
-
8. Weld issue: Unsatisfied dependencies for type [HttpSession]
witoldsz Jan 25, 2011 8:07 AM (in response to nickarls)Nicklas Karlsson wrote:
I don't understand the part of "more and more CurrentSomethingContexts", what is your scenario?
Well, I don't know yet, just anything I would like to temporarily store in a session, but maybe I am looking in a wrong direction.
Your rant would be very on-the-mark if CDI would be a web framework.
Maybe you are right.
The fact that CDI doesn't provide producers for any Servlet artifacts is in part because you shouldn't meddle with them directly.
Hmm, I cannot agree with you, because my application code (at least it's business part) does not meddle with HttpSession directly, but through producer which provides me WebUser object in run-time, it's API is not tied to HttpSession in any way. I treat producers/providers like configuration artifacts even though they are written in Java (thanks God not in .xml or alike).
Thanks for your time,
Witold Szczerba
-
9. Weld issue: Unsatisfied dependencies for type [HttpSession]
nickarls Jan 25, 2011 8:12 AM (in response to witoldsz)You could make a session-scoped component that is backed by a HashMap...
-
10. Weld issue: Unsatisfied dependencies for type [HttpSession]
witoldsz Apr 26, 2011 10:50 AM (in response to nickarls)Nicklas Karlsson wrote:
You could make a session-scoped component that is backed by a HashMap...
Yes, this is what I meant few posts ago
[...] sooner or later I will need more and more CurrentSomethingContexts so I will end up with one generic CurrentContext with a HashMap inside, used by a number of producers...
Thanks,
Witold Szczerba