|[equinox-dev] Differences in classloading between standard activators and Declarative Services|
I have a quick question about a possible difference I am noticing between the way classes are loaded in standard Equinox activators and the DS SCR in equinox 3.4.I20071023-0800.
Specifically, when transitioning to DS, I have started running into exceptions that I see commonly when Swing cannot acquire the L&F classes it needs. I have solved these problems in the standard activator scenario by:
1) Making sure that bundles that introduce new L&F classes export those classes
2) Having the bundles that wind up triggering these Swing look-ups include DynamicImport-Package: * in their manifest.
What seems to be the case is that the SCR is not honoring that DynamicImport-Package statement, because when I switch to those services being started via DS, I run into the errors again. Those errors look like this:
UIDefaults.getUI() failed: no ComponentUI class for: javax.swing.JMenuItem…
To restate the difference clearly, the same services started via OSGi activator do not produce the errors, where the DS start-up does.
Any insight or suggestions for a better solution to the Swing L&F issues would be appreciated.
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.