Skip to main content

NullPointerException from within GlassFish 3.1.2.2 when deploying small .ear file with EJBs

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
5 replies [Last post]
ljnelson
Offline
Joined: 2003-08-04

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

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ljnelson
Offline
Joined: 2003-08-04

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 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

hzhang_jn
Offline
Joined: 2005-07-22

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 > 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

ljnelson
Offline
Joined: 2003-08-04

I cannot reproduce it consistently, but I can reproduce it.

What I've noticed is that if I redeploy my app several times (and it will
fail redeployment several times, because there are too many ambiguous @EJB
references in it), I will get different output many times.

The output for the most part is helpful: it is telling me about various EJB
references that are going unfilled.

Then every once in a while instead of giving me the output, it gives me a
NullPointerException with the stack I posted.

What's interesting is that the output when I get it is not predictable:
sometimes it tells me about one EJB reference (of many) that is causing the
problem; another time it tells me about another EJB reference that is
causing the problem. It's like it's processing the EJBs in the .ear file
in a random order.

What I'm wondering (and obviously I'll check this) is if there is just one
ejb-jar.xml in the mix that might be triggering the NPE. Still, the random
deployment order kind of surprised me--I'm sure it's legal but it is kind
of interesting. Is it multithreaded in the background?

Best,
Laird

On Fri, Jul 26, 2013 at 1:16 PM, Hong Zhang wrote:

> 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 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
>
>
>

--
http://about.me/lairdnelson

hzhang_jn
Offline
Joined: 2005-07-22

Hi, Laird
No, it's single threaded, but its possible that there is not a
fixed order when processing the EJBs inside the EJB jar, I will let
people who are more familiar with EJB component comment on that.

Thanks,

- Hong

On 7/26/2013 5:57 PM, Laird Nelson wrote:
> I cannot reproduce it consistently, but I can reproduce it.
>
> What I've noticed is that if I redeploy my app several times (and it
> will fail redeployment several times, because there are too many
> ambiguous @EJB references in it), I will get different output many times.
>
> The output for the most part is helpful: it is telling me about
> various EJB references that are going unfilled.
>
> Then every once in a while instead of giving me the output, it gives
> me a NullPointerException with the stack I posted.
>
> What's interesting is that the output when I get it is not
> predictable: sometimes it tells me about one EJB reference (of many)
> that is causing the problem; another time it tells me about another
> EJB reference that is causing the problem. It's like it's processing
> the EJBs in the .ear file in a random order.
>
> What I'm wondering (and obviously I'll check this) is if there is just
> one ejb-jar.xml in the mix that might be triggering the NPE. Still,
> the random deployment order kind of surprised me--I'm sure it's legal
> but it is kind of interesting. Is it multithreaded in the background?
>
> Best,
> Laird
>
>
>
> On Fri, Jul 26, 2013 at 1:16 PM, Hong Zhang > wrote:
>
> 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
>> > 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
>
>
>
>
> --
> http://about.me/lairdnelson

mvatkina
Offline
Joined: 2005-04-04

I don't think the EJB deployer had been reached yet. The NPE is caused
by the null EJB class name...

-marina

On 7/29/13 6:20 AM, Hong Zhang wrote:
> Hi, Laird
> No, it's single threaded, but its possible that there is not a
> fixed order when processing the EJBs inside the EJB jar, I will let
> people who are more familiar with EJB component comment on that.
>
> Thanks,
>
> - Hong
>
> On 7/26/2013 5:57 PM, Laird Nelson wrote:
>> I cannot reproduce it consistently, but I can reproduce it.
>>
>> What I've noticed is that if I redeploy my app several times (and it
>> will fail redeployment several times, because there are too many
>> ambiguous @EJB references in it), I will get different output many times.
>>
>> The output for the most part is helpful: it is telling me about
>> various EJB references that are going unfilled.
>>
>> Then every once in a while instead of giving me the output, it gives
>> me a NullPointerException with the stack I posted.
>>
>> What's interesting is that the output when I get it is not
>> predictable: sometimes it tells me about one EJB reference (of many)
>> that is causing the problem; another time it tells me about another
>> EJB reference that is causing the problem. It's like it's processing
>> the EJBs in the .ear file in a random order.
>>
>> What I'm wondering (and obviously I'll check this) is if there is
>> just one ejb-jar.xml in the mix that might be triggering the NPE.
>> Still, the random deployment order kind of surprised me--I'm sure
>> it's legal but it is kind of interesting. Is it multithreaded in the
>> background?
>>
>> Best,
>> Laird
>>
>>
>>
>> On Fri, Jul 26, 2013 at 1:16 PM, Hong Zhang > > wrote:
>>
>> 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
>>> > 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
>>
>>
>>
>>
>> --
>> http://about.me/lairdnelson
>