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 <hong.hz.zhang_at_oracle.com
>> <mailto:hong.hz.zhang_at_oracle.com>> 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
>>> <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
>>
>>
>>
>>
>> --
>> http://about.me/lairdnelson
>