Robert,
How many bundles are involved here to reproduce the error? Is it just
one bundle which has following BCP:
Bundle-ClassPath: .,lib/imq.jar,lib/imqjmx.jar,lib/imqxm.jar
It seems to me that this bundle does not contain
com.sun.messaging.jms.ra.ManagedConnection.class
and other ra related classes which is probably why you are having to
optionally import the ra packages as shown below:
com.sun.messaging.jms.ra;resolution:=optional, \
com.sun.messaging.jms.ra.util;resolution:=optional, \
You have a problem with your bundle metadata. These packages are *not*
optional as you have now found out. What surprises me is that how it
worked in 3.1.1. There is no bundle exporting these packages, so I
expected them to fail earlier as well. Those packages exist in
imqjmsra.jar which comes as part of imq rar. Bundles can't see classes
from rars - not in any release of GlassFish. Perhaps it was a bug in
previous Weld which delegated class loading to our common class loader
which could load classes from rar.
I have asked our Weld engineers to tell us if something like this
changed, but you really need to package the recursive closure of your
dependencies in your bundle excluding the ones you know are available by
other bundles. What sort of issues did you face when you asked bnd to
inline dependencies? It should be really simple to configure bnd to
inline dependencies: just add all imq related jars to classpath and add
an instruction like:
Private-Package: com.sun.messaging.jms.*
# The above may be sufficient actually.
Import-Package: !com.sun.messaging.jms.*, *
This should cause all com.sun.messaging.jms.* classes needed by your
bundle to be part of your bundle.
Thanks,
Sahoo
On Thursday 19 January 2012 10:46 PM, Robert Weeks wrote:
> Hey Sahoo -
>
> This is the same bundle I had talked about a few weeks ago - getting the com.sun.messaging information into our bundle to utilize the JMX resources we need to monitor the JMS destinations in our app (which are created from many different bundles).
>
> I am not exporting any of this - I am including the jars and using Bundle-ClassPath to get these accesses (I did try to inline the classes using the classpath and PrivatePackage - but that was not helping at all - and caused more issues it seemed than doing this):
>
> Include-Resource: conf=src/conf,META-INF/beans.xml=src/META-INF/beans.xml,lib=lib
> Bundle-ClassPath: .,lib/imq.jar,lib/imqjmx.jar,lib/imqxm.jar
>
> Now - I am importing quite a bit from here - including the com.sun.messaging stuff from above (albeit optional on some). Example:
>
> com.sun.messaging.jms.ra;resolution:=optional, \
> com.sun.messaging.jms.ra.util;resolution:=optional, \
>
> Since they are needed for some of the above. We do @Inject a few things in some of our bundle classes (these are straight jar bundles btw - in autodeploy/bundles) - thus the need for beans.xml.
>
> If I try and pull the imqjmsra jar out of the rar it comes out of (in glassfish/mq/lib) - and add it here - it adds a slew of other dependencies needed to claim.
>
> Why is this ok/available the way it is in 3.1.1 and not now? Has something changed in the path that weld is given? I would think that imqjmsra would be available for that being in embedded mode. Is this not the case anymore?
>
> Thanks for the response.
>
>
>
> But the thing that is different here again is - this works fine in 3.1.1. But in 3.1.2 - no.
>
>
>
> Robert Weeks
> Lead Developer - Framework and UI
> EXTENSION, INC.
> Email: rweeks_at_ext-inc.com
> Office: 260-797-0200 x4228
> General: 877-207-3753
> www.OpenTheRedBox.com
>
> ________________________________________
> From: Sahoo [sanjeeb.sahoo_at_oracle.com]
> Sent: Thursday, January 19, 2012 11:56 AM
> To: users_at_glassfish.java.net
> Cc: Robert Weeks; users_at_glassfish.dev.java.net
> Subject: Re: Upgrading from 3.1.1 -> 3.1.2 - weld/com.sun.messaging issues?
>
> Hi Robert,
>
> Have you embedded imqjmsra.jar or some such imq library in your bundle?
> What packages is your bundle exporting then? The fact that Weld is able
> to load com.sun.messaging.jmq.jmsclient.JMSXAQueueSessionImpl, but not
> its dependency like com.sun.messaging.jms.ra.ManagedConnection makes me
> think that your bundle is perhaps exporting
> com.sun.messaging.jmq.jmsclient package but not
> com.sun.messaging.jms.ra. If this is not the correct guess, I am afraid
> you have to give us a more concrete example to find out what's going on.
>
> Thanks,
> Sahoo
> On Thursday 19 January 2012 08:54 PM, Robert Weeks wrote:
>> Hello -
>>
>> I was just experimenting on getting our bundles/apps to run in the latest 3.1.2 - and saw an issue that first arose when we were trying to upgrade weld to 1.1.4 in GlassFish 3.1.1 to help another issue we were having.
>>
>> When deploying one of our apps there, came across an issue with weld and classloading of certain com.sun.messaging libraries - some of which come from imqjmsra it seems - but we didn't have this issue in 3.1.1 at all.
>>
>> Since seeing the same issue in 3.1.1 with the weld update - I am wondering if anyone else is seeing issues like this as well. Seems some of the jms embedded libs aren't available to weld/cdi anymore?
>>
>> The bundle in question does have ejb's in it (timer, mdb, singleton) as well as utilizes some of the imq libraries for JMX monitoring of remote destinations.
>>
>> Some of the issues we are seeing:
>>
>> [#|2012-01-19T10:03:10.591-0500|INFO|glassfish3.1.2|org.jboss.weld.ClassLoading|_ThreadID=18;_ThreadName=Thread-3;|WELD-000119 Not generating any bean definitions from com.sun.messaging.jmq.jmsclient.JMSXAQueueSessionImpl because of underlying class loading error|#]
>>
>> [#|2012-01-19T10:03:10.592-0500|INFO|glassfish3.1.2|org.jboss.weld.ClassLoading|_ThreadID=18;_ThreadName=Thread-3;|catching
>> org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.messaging.jmq.jmsclient.JMSXAQueueSessionImpl
>> at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152)
>> at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86)
>> at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115)
>> at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171)
>> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336)
>> ...
>> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.messaging.jmq.jmsclient.XAQueueSessionImpl
>> at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152)
>> at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:139)
>> ...
>> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.messaging.jmq.jmsclient.XASessionImpl
>> at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152)
>> ...
>> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.messaging.jmq.jmsclient.UnifiedSessionImpl
>> at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152)
>> at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:139)
>> at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118)
>> Caused by: java.lang.NoClassDefFoundError: Lcom/sun/messaging/jms/ra/ManagedConnection;
>> at java.lang.Class.getDeclaredFields0(Native Method)
>> at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
>> at java.lang.Class.getDeclaredFields(Class.java:1743)
>> ...
>>
>> and so on.
>>
>> Thanks for any insight.