JNDI / Classpath problem in glassfish

Question

I am in the process of converting a large J2EE app (called AeApp below) from EJB 2 to EJB 3 (all stateless session beans, using glassfish 2.1.1), and running out of ideas.

The first EJB I converted (let's call it Foo) ran without major problems (it was the only one in its ejb-module and I could completely replace the deployment descriptor with annotations) and the app ran fine. But after converting the second one (let's call it Bar, one of several in a different ejb-module) there is a weird combination of problems:

• AeApp deploys without errors (nothing in the logs either). In the log, I get initialize messages for both Foo and Bar, but further messages about method permissions and JNDI name only for Foo:

  [#|2010-05-10T12:26:13.234+0200|FINE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=25;_ThreadName=Thread-2821;ClassName=com.sun.enterprise.security.application.EJBSecurityManager;MethodName=initialize;_RequestID=1801c4ff-90fe-4406-aaac-219c669be8c1;|Codebase (module id for ejb Foo) = null|#]
  [#|2010-05-10T12:26:11.625+0200|FINE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=25;_ThreadName=Thread-2821;ClassName=com.sun.enterprise.security.application.EJBSecurityManager;MethodName=initialize;_RequestID=1801c4ff-90fe-4406-aaac-219c669be8c1;|Codebase (module id for ejb Bar) = null|#]
  [#|2010-05-10T12:26:13.234+0200|FINE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=25;_ThreadName=Thread-2821;ClassName=com.sun.enterprise.security.application.EJBSecurityManager;MethodName=fooMethod;_RequestID=1801c4ff-90fe-4406-aaac-219c669be8c1;|JACC DD conversion: EJBMethodPermission ->(Foo fooMethod,Remote,java.lang.Long,java.util.Locale)protected by role -> FOOUSER|#]
  [#|2010-05-10T12:26:19.312+0200|INFO|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=httpWorkerThread-14848-1;|**RemoteBusinessJndiName: com.example.Foo; remoteBusIntf: com.example.Foo|#]
  

• There is an error when looking up Bar via JNDI

• When looking at the JNDI tree in the glassfish admin console, Bar is not present at all.
• The other EJBs in the same module do appear, as does Foo.
• There are exceptions in the logs concerning Foo, but these already appeared when it was still working.

Any ideas what could cause this or how to diagnose it further? The beans are pretty straightforward:

@Stateless(name = "Foo")
@RolesAllowed("FOOUSER")
@TransactionAttribute(TransactionAttributeType.SUPPORTS)
public class FooImpl extends BaseBean implements Foo {

I'm also having some problems with the deployment descriptor for Bar: I'd like to eliminate it, but glassfish doesn't seem to like having a bean appear only in sun-ejb-jar.xml, or having some beans in a module declared in the descriptor and others use only annotations.

Edit: The structure of the EAR is like this:

AeApp.ear
    AeApp.war
    Foo.jar (Foo.class and FooImpl.class present here)
    Bar.jar (Bar.class and BarImpl.class present here, also BaseBean.class)
    (some more EJB module JARs)
    (lots of library JARs)

AeApp.ear does not (and AFAIK never had, even when it was working) a META-INF/MANIFEST.MF. Its application.xml looks like this:

<application>
  <description>AE EAR</description>
  <display-name>AE EAR</display-name>
  <module><ejb>Foo.jar</ejb></module>
  <module><ejb>Bar.jar</ejb></module>
  <module><ejb>Baz.jar</ejb></module>
  <module><ejb>Doh.jar</ejb></module>
  <module><web>
      <web-uri>AeApp.war</web-uri>
      <context-root>/</context-root>
  </web></module>
</application>

Answer 1

I haven't seen the exact error messages you posted before, but they look to me, as if "foo-ejb.jar" is missing from bar's META-INF/MANIFEST.MF Class-Path attribute. It's possible to get bar compiled by using other means to put Foo into its classpath, but that won't work when running the application.

But I agree with Pascal, we may really need more information about your project's structure. A really short description (or maybe diagram) about which jars you have, which of the relevant classes (Foo/Bar/FooImpl/BaseBean/..) are in which jar, how they are related + their annotations would probably be enough.

Answer 2

After some trial and error, I narrowed down the problem, and a colleague brought me on the right track. The problem was not with classpaths or the EJBs themselves. It was much dumber.

My ejb-jar.xml had a EJBv2 DOCTYPE. That caused glassfish to silently ignore the EJBs using only annotations, and fail to put them into the JNDI tree when they were declared in the deployment descriptor. All I had to do is replace this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd"&gt;
     <ejb-jar>

With this:

<?xml version="1.0" encoding="UTF-8"?>
     <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" 
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0" 
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
                                  http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"&gt;