Accessing an EJB by name from a servlet init method fails in collapsed ear if is specified for the servlet

[afryer <ap...@hotmail.com>]

I have a war file that contains 2 jar files in WEB-INF/lib, one for entity
beans and one for stateless session ejbs (ie. collapsed ear file).

I am deploying this war file to tomcat + openejb.  In one of my servlets, I
want to access one of the stateless session ejbs in the init() method of the
servlet.  So in my web.xml I have the following declaration where the
stateless session EJB (com.pokersquid.poker.ejbs.PaymentSettingLocal) is
contained in one of the jar files in WEB-INF/lib...

< !-- fragment of web.xml -->

<ejb-local-ref>
  <ejb-ref-name>PaymentSettingLocal</ejb-ref-name>
  <ejb-ref-type>Session</ejb-ref-type>
  <local>com.pokersquid.poker.ejbs.PaymentSettingLocal</local>
</ejb-local-ref>

Now if I don't specify the <load-on-startup> value on my servlet, everything
works fine.  It CAN access the ejb by doing a name lookup on
"java:comp/env/PaymentSettingLocal" because the servlet is only initialized
when the first request for it happens, which is after all the ejbs have been
initialized and named in the jndi tree.

The problem occurs when I want to specify
<load-on-startup>1</load-on-startup> for the servlet.  In that case, there
is nothing in the jndi tree at that point.  It looks like the jndi is only
populated AFTER the container creates servlets.

I have verified this by creating a servlet that prints out the jndi tree in
its init() method and also in the doGet() method.  If i configure this
servlet to load-on-startup, the init() method prints out nothing, but when I
subsequently call the doGet method, the jndi tree IS populated with the
names I have configured using <ejb-local-ref> in the web.xml.

Therefore my question is, should it be possible to access an EJB from the
init() method of a servlet when the servlet is configured to
load-on-startup?  



--
View this message in context: http://openejb.979440.n4.nabble.com/Accessing-an-EJB-by-name-from-a-servlet-init-method-fails-in-collapsed-ear-if-load-on-startup-is-spet-tp3604528p3604528.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Accessing an EJB by name from a servlet init method fails in collapsed ear if is specified for the servlet

[afryer <ap...@hotmail.com>]

I just tested the snapshot build with my app, and you did fix it.  Nice work.

--
View this message in context: http://openejb.979440.n4.nabble.com/Accessing-an-EJB-by-name-from-a-servlet-init-method-fails-in-collapsed-ear-if-load-on-startup-is-spet-tp3604528p3780272.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Accessing an EJB by name from a servlet init method fails in collapsed ear if is specified for the servlet

[David Blevins <da...@gmail.com>]

FYI, I think I just fixed this last night in trunk (4.0.0-SNAPSHOT).  I Published new binaries to the nexus snapshot repo.

Grab the latest build from here:

  http://openejb.staging.apache.org/dyn/latest.cgi


-David

On Aug 7, 2011, at 9:02 PM, afryer wrote:

> Can you refer me to the spec where it says the environment naming context
> should not be accessible in callbacks like @PostConstruct?  I'm searching
> through the javaee_platform_6_0-fr-spec.pdf and servlet-3_0-pfd-spec.pdf and
> can't find mention of that.  In fact i think it says @PostConstruct gets
> called when after the class constructor and after all resources have been
> injected, implying that the environment naming context would be populated at
> that point.  Although its possible i'm missing something because I haven't
> read the spec with a fine tooth comb and it doesn't seem to explicitely
> detail the lifecycle, my impression is that the environment should be
> populated before the servlet init method is called.
> 
> javaee_platform-6_0-fr-spec.pdf...
> 
> 
>> *EE.5.3.4 Java EE Product Provider’s Responsibilities*
>> The Java EE Product Provider has the following responsibilities:
>> ...
>> •Implement the java:comp, java:module, java:app and java:global
>> environment naming contexts, and provide them to the application component
>> instances at runtime. The naming context must include all the entries
>> declared by the Application Component Provider, with their values supplied
>> in the deployment descriptor or set by the Deployer. The environment
>> naming context must allow the Deployer to create subcontexts if they are
>> needed by an application component. Certain entries in the naming context
>> may have to be initialized with the values of other entries, specifically
>> when the “lookup” facility is used. In this case, it is an error if there
>> are any circular dependencies between entries. Similarly, it is an error
>> if looking up the specified JNDI name results in a resource whose type is
>> not compatible with the entry being created. The deployment tool may allow
>> the deployer to correct either of these classes of errors and continue the
>> deployment.
>> 
> 
> --
> View this message in context: http://openejb.979440.n4.nabble.com/Accessing-an-EJB-by-name-from-a-servlet-init-method-fails-in-collapsed-ear-if-load-on-startup-is-spet-tp3604528p3726049.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Accessing an EJB by name from a servlet init method fails in collapsed ear if is specified for the servlet

[afryer <ap...@hotmail.com>]

Can you refer me to the spec where it says the environment naming context
should not be accessible in callbacks like @PostConstruct?  I'm searching
through the javaee_platform_6_0-fr-spec.pdf and servlet-3_0-pfd-spec.pdf and
can't find mention of that.  In fact i think it says @PostConstruct gets
called when after the class constructor and after all resources have been
injected, implying that the environment naming context would be populated at
that point.  Although its possible i'm missing something because I haven't
read the spec with a fine tooth comb and it doesn't seem to explicitely
detail the lifecycle, my impression is that the environment should be
populated before the servlet init method is called.

javaee_platform-6_0-fr-spec.pdf...


> *EE.5.3.4 Java EE Product Provider’s Responsibilities*
> The Java EE Product Provider has the following responsibilities:
> ...
> •Implement the java:comp, java:module, java:app and java:global
> environment naming contexts, and provide them to the application component
> instances at runtime. The naming context must include all the entries
> declared by the Application Component Provider, with their values supplied
> in the deployment descriptor or set by the Deployer. The environment
> naming context must allow the Deployer to create subcontexts if they are
> needed by an application component. Certain entries in the naming context
> may have to be initialized with the values of other entries, specifically
> when the “lookup” facility is used. In this case, it is an error if there
> are any circular dependencies between entries. Similarly, it is an error
> if looking up the specified JNDI name results in a resource whose type is
> not compatible with the entry being created. The deployment tool may allow
> the deployer to correct either of these classes of errors and continue the
> deployment.
> 

--
View this message in context: http://openejb.979440.n4.nabble.com/Accessing-an-EJB-by-name-from-a-servlet-init-method-fails-in-collapsed-ear-if-load-on-startup-is-spet-tp3604528p3726049.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Accessing an EJB by name from a servlet init method fails in collapsed ear if is specified for the servlet

[Jean-Louis MONTEIRO <je...@gmail.com>]

Hi,

I probably need to check, but the Environment Naming Context should not be
accessible (as per the spec).

It's actually the case in callbacks like @PostConstruct and I my humble
opinion it should be the same for load-on-startup.

Hope it helps.
Jean-Louis



--
View this message in context: http://openejb.979440.n4.nabble.com/Accessing-an-EJB-by-name-from-a-servlet-init-method-fails-in-collapsed-ear-if-load-on-startup-is-spet-tp3604528p3627460.html
Sent from the OpenEJB User mailing list archive at Nabble.com.