Hi, Laird
It's hard to tell if it's a duplicate of issue 16547 or not with
what you described. Please open a new issue with the test case if you
find a way to reproduce the problem consistently.
Thanks,
- Hong
On 7/26/2013 2:50 PM, Laird Nelson wrote:
> 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
> <mailto: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