> In your case it looks like the API is needed on the outside of the OSGi > Framework, because it’s on the classpath of the webapp. This means you have > to export it from the system bundle by setting the > org.osgi.framework.system.packages.extra property. If you do this you can > remove the copy that exists in the bundle, and allow that bundle to import the > API. Exactly, the API is needed outside of OSGI. Setting the extra property within Weblogic felix system bundle did not help. I know the extra property is respected since I had to put some javax.xml packages there in order to make the osgi bundles work that use javax.xml stuff.
> i don’t fully understand your scenario, but bear in mind that an OSGi > application > nearly always consists of multiple bundles. Ok, let me try to explain further. We have a legacy osgi application that we want to use without big changes to it in our Weblogic infrastructure (yes, sure, we can always start it the old fashion way as a standalone application). To achieve this, I wrapped the entire osgi application into a *.war web application. That war contains a main activator bundle that configures all the osgi bundles of the osgi application. Besides that, some weblogic configuration files that tell weblogic to look for the main activator in all the bundles that are put to its osgi-lib folder. Like this, the application boots up and functions normally. Within the very same web application, I do have a java servlet that accesses the osgi application by the way oracle built that osgi bridge in Weblogic: https://docs.oracle.com/middleware/1212/wls/WLPRG/osgi.htm#WLPRG778 This serves as the only entry point I can get outside of the osgi application. You do this by the following code: Bundle bundle = null; try { Context initCtx = new InitialContext(); bundle = (Bundle) initCtx.lookup("java:app/osgi/Bundle"); } catch .... This is the old fashion way to do this, today we use @Resource(lookup = "java:app/osgi/Bundle") Bundle bundle; Which does all the stuff automatically. So to me it seems like we have those classloaders in the game: 1) One Main Weblogic classloader that boots the server 2) One Webapplication Classloader that boots the non-osgi part of the war application, like the servlet 3) One Felix Classloader that boots up the osgi framework 4) One main activator bundle classloader that configures the other osgi bundles 5) One classloader for each osgi bundles, but those are handled by felix and should not cause issues The main problem is to access from classloader 2) the stuff in 4) and 5) even though the extra property is set on 3) to export the classes. I also tried to load all those osgi bundles into the 1) classloader by putting them into the osgi-lib folder of the weblogic server installation. This worked in a way where the libs were found and the application boots up, however the linkage error still happened. Maybe it's just not possible, since the weblogic documentation states: "One specific OSGi bundle from the chosen framework instance can be used in the application classloader hierarchy." So far I am out of ideas. If you are interested in this problem more deep we could also do some teamviewer session. I would love to solve this problem and understand the stuff behind the scenes. This message may contain legally privileged or confidential information and is therefore addressed to the named persons only. The recipient should inform the sender and delete this message, if he/she is not named as addressee. The sender disclaims any and all liability for the integrity and punctuality of this message. The sender has activated an automatic virus scanning, but does not guarantee the virus free transmission of this message.
