3 Replies Latest reply on May 5, 2014 8:29 AM by John Ament

    @Inject @SessionScoped into @Statless session bean

    Frank Cornelis Apprentice

      Hi,

       

      I have an EAR where I @Inject within its EJB JAR a @SessionScoped CDI object (that has been initiated previously within its WAR) within a @Stateless EJB session bean.

      Sometimes I get the wrong (a new I suppose) @SessionScoped CDI instance. AFAIK this should work?

      Anyone else experiencing similar issues?

       

      Kind Regards,
      Frank.

        • 1. Re: @Inject @SessionScoped into @Statless session bean
          John Ament Master

          No, that should not work.  Each module within an EAR is considered its own deployment.  BeanManager is local within that component.

           

          EAR is simply a way to group multiple deployments together.  Your session scope is only active within the context it was created, jumping to another deployment will start its own session scope.

           

          Most people w/ CDI find it easier to have a WAR w/ all archives in WEB-INF/lib.  Do you need 2 WAR files?

          • 2. Re: @Inject @SessionScoped into @Statless session bean
            Frank Cornelis Apprentice

            If each module within the EAR is considered its own deployment, then why do you get a CDI error during deployment when you have in each WAR a bean with the same @Named("foobar") annotation?

            So according to you, a @SessionScoped bean within the EJB JAR will result in a different instance for both the WAR and EJB JAR within the same HTTP session? That's weird. If you access (via JACC) the HTTP session from within the EJB JAR, you do get the active HTTP session as seen by the WAR.

             

            I need different WARs for security reasons (end-user portal, admin portal, WS webapp).

            • 3. Re: @Inject @SessionScoped into @Statless session bean
              John Ament Master

              Hmm... why do you get issues with the same @Named? I have no idea.  That should work, and I would think should be a bug against WF if it's actually happening.  What I'd recommend that you do is not use an EJB-JAR but instead just put your CDI objects into a enterprise app library.