Uh oh, Heisenbug.
Upped the log level for javax.enterprise.system.tools.admin to FINER and
ran the same deployment command again on the same app, no change, and this
time it told me exactly what was wrong (no NullPointerException; simple
case of two EJB implementations being present for a single business
interface).
Dropped the log level back to INFO and again, no NPE. Same app, same
command. Hmmm. I'll see if I can reproduce this on fresh appserver start,
too.
Best,
Laird
On Fri, Jul 26, 2013 at 11:44 AM, Laird Nelson <ljnelson_at_gmail.com> wrote:
> I'm deploying an ear file containing a few EJB jars on GlassFish 3.1.2.2.
> These EJB jars have ejb-jar.xml files in them. It is entirely possible
> that some of these ejb-jar.xml files are not correctly put together (fair
> warning).
>
> Upon doing this I immediately get (snipped for (some!) brevity):
>
> [#|2013-07-26T11:31:48.959-0700|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=19;_ThreadName=Thread-5;|Exception
> while deploying the app [foo-ear-1.0-SNAPSHOT] : Error processing
> EjbDescriptor
> *java.lang.NullPointerException*
> at
> com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.convertToResourceName(APIClassLoaderServiceImpl.java:304)
> at
> com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:295)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at
> com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:235)
> at
> com.sun.enterprise.deployment.EjbDescriptor.visit(EjbDescriptor.java:2578)
> at
> com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:734)
> at com.sun.enterprise.deployment.Application.visit(Application.java:1765)
> at
> com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:830)
> at
> com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:277)
> at
> com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
> at
> org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:175)
> at
> org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:94)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:827)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:769)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
>
> |#]
>
>
> This looks suspiciously similar to
> https://java.net/jira/browse/GLASSFISH-16547, but isn't the same thing
> (libraries are in the lib directory of the enclosing .ear file, app is
> otherwise spec-compliant).
>
> Obviously I'll check my (not authored by me) ejb-jar.xml overrides, but
> wanted to raise the NPE problem here. Are there known issues with NPEs
> when an invalid ejb-jar.xml is encountered? Should I file a new bug, or
> should GLASSFISH-16547 be reopened?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>
--
http://about.me/lairdnelson