10 Replies Latest reply on Apr 26, 2011 10:50 AM by witoldsz

    Weld issue: Unsatisfied dependencies for type [HttpSession]

    witoldsz

      Hi there,

      I have an application which deploys and runs fine on Glassfish 3.0.1. I am investigating a migration to a new version of Glassfish or brand new JBoss 6 and found an issue with the new version of the Weld. The problem is:

      Error occurred during deployment: Exception while loading the app:

      WELD-001408 Unsatisfied dependencies for type [HttpSession] with qualifiers [@Default] at injection point [[parameter 1] of [method] @Produces @Dependent public pl.assetwell.demo.service.impl.WebUserProvider.currentUser(HttpSession)].

       

      The WebUserProvider:

      @ApplicationScoped 
      public class WebUserProvider {
        @Produces 
        @Dependent 
        public WebUser currentUser(HttpSession httpSession) { 
          return (WebUser) httpSession.getAttribute("user");
        }
      } 

       

      And in my business logic, when I need user, I use the above like this:

       

      @Inject Instance webUserProvider; 
      ...
      WebUser user = webUserProvider.get();

       

       

      At the beginning, I wanted to inject WebUser directly into my business logic beans, allowing CDI to proxy it, so I wouldn't need to manually pull the instance from Instance, but unfortunately Weld complained it cannot proxy my WebUser class. I worked it around, but the new problem with HttpSession being an unsatisfied dependency seems to be a major problem to me. It seems strange that it works with Weld used in GF 3.0 and stops working in GF 3.1 and JBoss 6.

      Can you help me with this issue? Is this a bug?

       

      Thanks,

      Witold Szczerba

       

      P.S.

      I have asked the same question of Glassfish mqiling list, but it has been several days with no answer, so I have tried new JBoss and I can see the same problem. This is why I am asking here since JBoss is the one who stands behind Weld. The project is still in very very young stage, I am not even sure if it will launch at all, so I am jumping from application server to application server evaluating how does Java EE 6 works here and there.

        • 1. Re: Weld issue: Unsatisfied dependencies for type [HttpSession]
          nickarls

          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

            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

              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

                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

                  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

                    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

                      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

                        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

                          You could make a session-scoped component that is backed by a HashMap...

                          • 10. Weld issue: Unsatisfied dependencies for type [HttpSession]
                            witoldsz

                            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