Hi, Marcus
Yes, the problem was caused by packaging the ejb jar inside the
client jar. When loading the appclient jar in the appclient container,
we will parse/validate the deployment descriptors packaged inside the
client jar, and the parsing/validating the ejb descriptor will trigger
loading of the ejb class and then the loading of the referenced resource
adapter class which caused the NoClassDefFoundError.
Unfortunately, the ejb jar was not packaged in the client jar by
mistake, this was something we did to support backward compatibility. In
the early 9.0 days, the retrieved client jar had all kinds of
unnecessary contents if the client was deployed as part of the ear. And
that caused a lot of problem. So we spent quite some time trying to
clean it up. We did remove the ejb jar from the client jar in the first
round because we thought it's not needed and that caused quite a few
existing applications to break. Those applications were packaged
incorrectly, the ejb interfaces were not packaged as part of the
original client jar while the client needs to access the EJB. They were
relying on the ejb jar packaged in the retrieved client jar to run.
Though those applications were packaged incorrectly, they did run with
the previous versions. So we made the decision to keep the ejb jar
inside the client jar to maintain the backward compatibility.
Now we can see this approach caused some trouble, the case you
described and also we have some previous complaints of packaging ejb jar
inside the client jar causing big footprint and low performance. So the
client jar packaging is definitely something we will address in the next
major release (v3). For the v2 release, we probably cannot change the
packaging (again, due to backward compatibility), but we will try to
figure out a way to solve the case you described. Either somehow make
the referenced connector class available in the appclient container, or
somehow avoid loading ejb class in the application client container. I
will discuss the options with Tim once he comes back from the vacation
next week. We will keep you posted.
Thanks,
- Hong
Sahoo wrote:
> Trying to load EJB class in ACC for no good reason is actually a bug.
> ACC needs to be smarter in identifying what to exclude during its
> processing. I don't remember exactly, but I might have already file a
> bug for this in the past.
>
> Markus,
>
> Can you run verifier against the entire ear file and tell us if there
> is any missing dependency? If that were the case, it would have shown
> up while deploying the ear file itself, so I am confused. May be there
> is a packaging issue which is why some class is not being copied to
> Client.jar, as Tim was hinting.
>
> Thanks,
> Sahoo
>
> Jagadish Prasath Ramu wrote:
>
>> As part of validation, DOL loads the ejb-class & looks for a particular
>> method.
>> One of the ejb methods uses "KernelConnection" which is not available
>> for the classloader and hence this exception.
>>
>>
>> On Fri, 2008-05-30 at 09:07 +0200, Markus Karg wrote:
>>
>>
>>> I do not use a deployment descriptor at all.
>>>
>>> -----Original Message-----
>>> From: Jagadish.Ramu_at_Sun.COM [mailto:Jagadish.Ramu_at_Sun.COM] Sent:
>>> Freitag, 30. Mai 2008 09:02
>>> To: users_at_glassfish.dev.java.net
>>> Cc: Hong Zhang
>>> Subject: RE: Re: Why does the Client Container try to load a
>>> resourceadapter'sConnection class?
>>>
>>> Seems like application is being validated and as part of it, DOL
>>> (deployment object library) loads the ejb descriptors that in-turn is
>>> trying to load the class.
>>> CC-ing Hong for help.
>>>
>>> Do you have any reference of rar-class in ejb descriptors ?
>>> eg: resource-ref
>>> Thanks,
>>> -Jagadish
>>>
>>>
>>> On Thu, 2008-05-29 at 14:09 +0200, Markus Karg wrote:
>>>
>>>
>>>> Here it is.
>>>> "de/quipsy/connector/kernel/api/outbound/KernelConnection" is part
>>>> of the custom interface of the resource adapter.
>>>>
>>>> java.lang.reflect.InvocationTargetException
>>>> at
>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>> at
>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
>>>> at
>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
>>>> Source)
>>>> at java.lang.reflect.Constructor.newInstance(Unknown Source)
>>>> at
>>>> com.sun.enterprise.appclient.jws.boot.JWSACCMain.run(JWSACCMain.java:221)
>>>>
>>>> at
>>>> com.sun.enterprise.appclient.jws.boot.JWSACCMain.main(JWSACCMain.java:182)
>>>>
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at com.sun.javaws.Launcher.executeApplication(Unknown Source)
>>>> at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
>>>> at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
>>>> at com.sun.javaws.Launcher.run(Unknown Source)
>>>> at java.lang.Thread.run(Unknown Source)
>>>> Caused by: java.lang.RuntimeException:
>>>> java.lang.NoClassDefFoundError:
>>>> de/quipsy/connector/kernel/api/outbound/KernelConnection
>>>> at
>>>> com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:487)
>>>>
>>>> ... 15 more
>>>> Caused by: java.lang.NoClassDefFoundError:
>>>> de/quipsy/connector/kernel/api/outbound/KernelConnection
>>>> at java.lang.Class.getDeclaredMethods0(Native Method)
>>>> at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
>>>> at java.lang.Class.getDeclaredMethods(Unknown Source)
>>>> at
>>>> com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:263)
>>>>
>>>> at
>>>> com.sun.enterprise.deployment.EjbDescriptor.visit(EjbDescriptor.java:2058)
>>>>
>>>> at
>>>> com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:734)
>>>>
>>>> at
>>>> com.sun.enterprise.deployment.Application.visit(Application.java:1754)
>>>> at
>>>> com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:470)
>>>>
>>>> at
>>>> com.sun.enterprise.deployment.archivist.ApplicationArchivist.open(ApplicationArchivist.java:246)
>>>>
>>>> at
>>>> com.sun.enterprise.appclient.AppClientInfo.populateDescriptor(AppClientInfo.java:477)
>>>>
>>>> at
>>>> com.sun.enterprise.appclient.AppClientInfo.completeInit(AppClientInfo.java:171)
>>>>
>>>> at
>>>> com.sun.enterprise.appclient.AppClientInfoFactory.buildAppClientInfo(AppClientInfoFactory.java:149)
>>>>
>>>> at
>>>> com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:366)
>>>>
>>>> ... 15 more
>>>> Caused by: java.lang.ClassNotFoundException:
>>>> de.quipsy.connector.kernel.api.outbound.KernelConnection
>>>> at
>>>> com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:737)
>>>>
>>>> at
>>>> com.sun.enterprise.loader.EJBClassLoader.findClass(EJBClassLoader.java:627)
>>>>
>>>> at java.lang.ClassLoader.loadClass(Unknown Source)
>>>> at java.lang.ClassLoader.loadClass(Unknown Source)
>>>> at java.lang.ClassLoader.loadClassInternal(Unknown Source)
>>>> ... 28 more
>>>>
>>>> -----Original Message-----
>>>> From: Jagadish.Ramu_at_Sun.COM [mailto:Jagadish.Ramu_at_Sun.COM] Sent:
>>>> Donnerstag, 29. Mai 2008 12:16
>>>> To: users_at_glassfish.dev.java.net
>>>> Subject: Re: Why does the Client Container try to load a resource
>>>> adapter'sConnection class?
>>>>
>>>> Can you post the exception stack traces?
>>>>
>>>> Thanks,
>>>> -Jagadish
>>>>
>>>>
>>>> On Thu, 2008-05-29 at 11:53 +0200, Markus Karg wrote:
>>>>
>>>>
>>>>> My EAR contains three modules:
>>>>>
>>>>>
>>>>>
>>>>> * ResourceAdapter, providing a custom interface
>>>>>
>>>>> * EJB-JAR, containing a session bean that accesses the resource
>>>>> adapter's customer interface internally; also providing EJB 2.1
>>>>> Compatibility View
>>>>>
>>>>> * Application Client, using EJB 2.1 Compatibility View of the session
>>>>> bean
>>>>>
>>>>>
>>>>>
>>>>> The application client has NO references to any part of the resource
>>>>> adapter. He is completely unaware of its existence. Neither is any
>>>>> class or interface of the resource adapter beeing passes to the
>>>>> client
>>>>> by the session bean, or accepted by the session bean as beeing passed
>>>>> from the client.
>>>>>
>>>>>
>>>>>
>>>>> The validator has 0 errors, 0 warnings, 0 infos. Also I can deploy
>>>>> and
>>>>> startup the server without any problem.
>>>>>
>>>>>
>>>>>
>>>>> But when I click on "Launch" to run the client using Web Start, then
>>>>> Web Start shows me a nice exception that it is unable to locate
>>>>> one of
>>>>> the classes contained in the custom interface of the ResourceAdapter.
>>>>> In the stack trace there is only com.* and java.* stuff mentioned,
>>>>> but
>>>>> none of my own classes.
>>>>>
>>>>>
>>>>>
>>>>> As soon as I added a copy of all classes of the custom interface into
>>>>> my client JAR, it starts up very well (and certainly never uses that
>>>>> class).
>>>>>
>>>>>
>>>>>
>>>>> Can somebody explain, why the client container wants to load that
>>>>> class? It obviously is never referenced anywhere in the client!
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Markus
>>>>>
>>>>>
>>>>>
>>>>> QUIPSY QUALITY GmbH & Co. KG
>>>>>
>>>>> Ein Unternehmen der MES-Gruppe
>>>>>
>>>>> Stuttgarter Strasse 23
>>>>>
>>>>> D-75179 Pforzheim
>>>>>
>>>>> Tel: 07231-9189-52
>>>>>
>>>>> Fax: 07231-9189-59
>>>>>
>>>>> www.quipsy.de
>>>>>
>>>>> karg_at_quipsy.de
>>>>>
>>>>> Registergericht Mannheim HRA 701214
>>>>>
>>>>> Geschäftsführer: Nils Schroeder
>>>>>
>>>>>
>>>>>
>>>>> Diese E-Mail enthält persönliche, vertrauliche und vor Weitergabe
>>>>> geschützte Informationen und ist ausschließlich für den vorgesehenen
>>>>> o.g. Empfänger (Adressaten) bestimmt. Falls Sie diese E-Mail
>>>>> versehentlich erhalten haben und nicht der vorgesehene Empfänger
>>>>> sind,
>>>>> bitten wir Sie, die E-Mail und deren Anhänge nicht aufzubewahren,
>>>>> nicht zu vervielfältigen, nicht zu nutzen und nicht weiterzugeben.
>>>>> Bitte informieren Sie uns als Absender über diesen Zustellungsfehler
>>>>> und löschen Sie die E-Mail.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>