DOh! Replied to wrong address....
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: Robert Weeks
Sent: Friday, January 20, 2012 3:29 PM
To: sanjeeb.sahoo_at_oracle.com
Subject: RE: Upgrading from 3.1.1 -> 3.1.2 - weld/com.sun.messaging issues?
Hey Sahoo -
________________________________________
From: Sahoo [sanjeeb.sahoo_at_oracle.com]
Sent: Friday, January 20, 2012 12:43 PM
To: users_at_glassfish.java.net
Cc: Robert Weeks
Subject: Re: Upgrading from 3.1.1 -> 3.1.2 - weld/com.sun.messaging issues?
Robert,
...
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:
> Yea - that would have been awesome - if using jms embedded or something - be able to export those to the classpath or something similar. But that would have helped for sure.
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?
> We have this way working in both now - 3.1.1 w/weld-1.1.4 and 3.1.2 - the beans.xml file was the key for me here.
I put all the main imq jars in the build classpath, and what we were seeing as a lot of the dependencies in the logs and ClassNotFoundExceptions were from weld scanning those classes for eligible beans, and needing the dependencies those needed to run.
Adding the following the the beans.xml file:
<weld:scan>
<weld:exclude name="com.sun.messaging.**"></weld:exclude>
<weld:exclude name="com.sun.jms.**"></weld:exclude>
</weld:scan>
made these issue go away.
I think there is still an issue that 3.1.1 allowed this - but was good to see this come out and get it working.
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.
> I was a little leary on this (using the url to attach to it) - in that we are moving to a distributed model - and figured using the factory would be a better alternative. If we need to pare down, or have a single node for jms calls will probably go this route. Just thought would be best since embedded.
Option 4: Create a separate bundle out of all imq jars and make it
export packages which you can then import from your bundle.
> I actually started going this route - having a central imq bundle to export these - and for some reason had some conflicts with the libraries that were in there (surprisingly) - so didn't stick with this one for that long.
Thanks again for responding. Hopefully this helps our other issue we were having with weld exporting older libraries that were conflicting with some of our other bundles.
:)