Robert,
I can imagine your situation. There must be something changed in weld or
weld-gf integration layer in 3.1.2 for it to behave differently. If you
can put together a test case, then someone can tell you what exactly
caused this difference in behavior, but I would not call it a bug yet
based on information available so far. More over, that's not the root
cause. The root cause is really that imq APIs are not available as OSGi
bundles unlike other technologies included in GlassFish. I guess it's
too late to fix that in 3.1.2. Here are some of your options:
Option 1: Inline dependencies
If you inline and it pulls in everything that's needed, then there is no
other choice but to inline all the dependencies. This will increase your
bundle size dramatically, but that aside have you verified it to be working?
Option 2: Embed jars
Again you have to embed all jars required. Same as #1 I suppose.
Option 3: Don't use imq APIs
Can't you use just Java SE JMX APIs to extract information from imq
mbeans? Why do you have to depend on imq APIs? At the very least, you
should be able to use the constants from imq APIs and since constants
are always inlined by the compiler, your bundle won't need to import any
imq packages. I think I mentioned about this earlier as well.
Option 4: Create a separate bundle out of all imq jars and make it
export packages which you can then import from your bundle.
Thanks,
Sahoo
On Friday 20 January 2012 10:09 PM, Robert Weeks wrote:
> Hello Sahoo -
> ________________________________________
>
>
> 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
>
>
> Just this one.
>
>
> 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, \
>
>
> Correct - which is a little confusing to me as well - because I couldn't find where those are exported - but they sure have been working in 3.1.1.
>
>
>
> 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.
>
>
> This is what I am thinking somehow - that it was able to see classloader from somewhere since did/does work fine in 3.1.1.
>
>
>
>
> 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.
>
>
> This is definitely not as easy as this for this information. Dependencies that these inlined classes now need can grow astronomical as well.
>
> Some of the issues I have been having with this - say for example using just the above if I have all of the libs in the path:
>
> imq.jar,imqjmx.jar,imqxm.jar,imqjmsra.jar
>
> Is the dependencies that these then need to be able to included.
>
> For example - I have it now to where I can get the bundle to run in 3.1.1 again with the includes (using the above jars added to classpath):
> Private-Package: \
> com.sun.jms.*;-split-package:=merge-last,\
> !com.sun.messaging.jmq.admin.apps.*,\
> !com.sun.messaging.jmq.jmsserver.*,\
> com.sun.messaging.*;-split-package:=merge-last
>
> (which the ! removals were causing issues wanting to load in beans that required other classes - sigh - as well as main classes in com.sun.messaging itself are needed for this).
>
> Now - when upgrading to weld 1.1.4 - or trying in 3.1.2 - I still get issue with it now looking for other things it can't find that are not in these classes - such as:
>
>
> [#|2012-01-20T11:15:40.289-0500|INFO|glassfish3.1.1|org.jboss.weld.ClassLoading|_ThreadID=19;_ThreadName=Thread-3;|WELD-000119 Not generating any bean definitions from com.sun.messaging.jmq.admin.bkrutil.BrokerAdminConn because of underlying class loading error|#]
>
> [#|2012-01-20T11:15:40.295-0500|INFO|glassfish3.1.1|org.jboss.weld.ClassLoading|_ThreadID=19;_ThreadName=Thread-3;|catching
> org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.messaging.jmq.admin.bkrutil.BrokerAdminConn
> ....
> Caused by: java.lang.NoClassDefFoundError: com/sun/messaging/jmq/admin/apps/console/event/AdminEvent
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
>
> which is part of imqbroker.jar (ugh - so another jar to balance classes to pull in) - ugh.
>
> But can see the loops this is putting me in. I just need to find the right combination of inlining and what not to import, etc. to make work.
>
> I just think all of this is really off base just to be able to get the JMX information from the AdminConnectionFactory from the embedded server from an osgi bundle. Doing all of this bloats the bundle from like< 200K to 2M+. Crazy...
>
> Thanks.
>
>
>
>
>
>
>
>
> 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
>