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