3 Replies Latest reply on Mar 10, 2010 5:44 AM by jaikiran pai

    Lookup to java:comp/EJBContext during postconstruction

    Marius Bogoevici Expert

      I will just refer to the problem indicated in http://seamframework.org/Community/TheMessageDrivenBeanSagaContinues

       

      While a CDI problem per se, it seems like doing this:

       

      @MessageDriven(activationConfig={       @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),       @ActivationConfigProperty(propertyName="destination",     propertyValue="queue/testQueue")   }) public class MilkMan implements MessageListener {    @PostConstruct    public void doAfterConstruction()    {       try       {          Context context = ((Context) new InitialContext().lookup("java:comp/EJBContext"));       }       catch (NamingException e)       {          e.printStackTrace();       }    }    @Inject Control control;    public void onMessage(Message message)    {       try       {          control.setMessageDelivered(((TextMessage) message).getText().equals(EJBTest.MESSAGE));       }       catch (JMSException e)       {          throw new RuntimeException(e);       }    } }

       

      will cause the deployment to fail, since doing that lookup from within the postconstructor does not get all the expected interceptors applied. Of course, this is not how exactly we intent to use this from Weld, but doing injection of resources during postconstruction has a similar effect.

       

      Now, I would really like to know whether this assessment is corect and if that is something that is essentially expected to happen given the circumstances. If this is expected behaviour, then I think that we could work around this by treating EJBContext distinctly when injecting resources, but if not, then what would you think that would be the appropriate solution for doing a correct lookup for the purposes of CDI/Weld integration?

        • 1. Re: Lookup to java:comp/EJBContext during postconstruction
          jaikiran pai Master

          marius.bogoevici wrote:

           


          public class MilkMan implements MessageListener

          {

           

             @PostConstruct

             public void doAfterConstruction()

             {

                try

                {

                   Context context = ((Context) new InitialContext().lookup("java:comp/EJBContext"));

                }

                catch (NamingException e)

                {

                   e.printStackTrace();

                }

             }


           

          }

           

           

           

          Now, I would really like to know whether this assessment is corect and if that is something that is essentially expected to happen given the circumstances. If this is expected behaviour, then I think that we could work around this by treating EJBContext distinctly when injecting resources, but if not, then what would you think that would be the appropriate solution for doing a correct lookup for the purposes of CDI/Weld integration?

          It shouldn't fail. If it's failing, then it's a bug (looks like similar to the one we just fixed for EAP-4.x version). And i don't think it's specific to the EJBContext. I guess it will fail for anything under java:comp for that bean. Can you give a quick try by looking up something else under java:comp from within the @Postconstruct of MDB?

          • 2. Re: Lookup to java:comp/EJBContext during postconstruction
            jaikiran pai Master

            jaikiran wrote:

            And i don't think it's specific to the EJBContext. I guess it will fail for anything under java:comp for that bean. Can you give a quick try by looking up something else under java:comp from within the @Postconstruct of MDB?

            Looked at that stacktrace again and it indeed appears to be specific to java:comp/EJBContext

             

             

            Caused by: java.lang.NullPointerException
                 at org.jboss.ejb3.EJBContextFactory.getObjectInstance(EJBContextFactory.java:57)
                 at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
                 at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1483)
                 at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1500)
            
            
            

             

             

            It appears that the AbstractPool invokes the postconstruct after popping the context from the thread local stack:

             

            protected BeanContext<?> create(Class[] initTypes, Object[] initValues)
               {
                  BeanContext ctx;
                  ctx = createBeanContext();
                  container.pushContext(ctx);
                  try
                  {
                     container.injectBeanContext(ctx);
            
                     ctx.initialiseInterceptorInstances();
            
                  }
                  finally
                  {
                     container.popContext();
                  }
            
                  container.invokePostConstruct(ctx, initValues);
            
                  // the init method only applies to stateful session beans
            
                  ++createCount;
            
                  return ctx;
               }
            

             

             

            The fix looks simple enough. I'll file a JIRA for this.