Lookup to java:comp/EJBContext during postconstruction

[marius.bogoevici]

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?

[jaikiran]

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?

[jaikiran]

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.

[jaikiran]

https://jira.jboss.org/jira/browse/EJBTHREE-2038