> On 25 Aug 2016, at 10:40, Remo Liechti <[email protected]> wrote: > > >> Unless I have misunderstood you, that sounds like two places from which the >> type is loaded: the lib folder of the web application (i.e. the application >> classpath >> on which the OSGi Framework), and a bundle. That’s almost certainly the >> source >> of the conflict. > > Yes, you are right. The Class is loaded from within two classloaders. One is > the weblogic WebApp classloader, the other one is the one from Felix. > However, it's the same class file which is being loaded. There do not exsit > multiple version of the same class file in different jars on the classpath. > So if I understood you correctly - it does not matter if the class file is > the same, the fact that the class is loaded in two different classloader > alone is enough to create the LinkageError?
That’s correct. Bear in mind this is nothing to do with OSGi yet, it’s a core Java principle. The same class loader cannot be exposed to multiple definition of a class, even if those definitions are byte-for-byte identical. > So the only solution would be to use standard java types for passing params > to the API instead? Not at all. You can pass any type you like, as long as both sides are using the same definition of that type. Usually this is done by having a single export of the service API, and having both the consumer and the provider of the service import it. 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. > >> If you are in a bundle you can always get your own BundleContext — you do not >> need it to be supplied by JNDI. > > Agreed, but the goal is not to be within a bundle, we want to access the osgi > services outside from osgi in a j2ee web application, where we do not have an > own BundleContext. But maybe I'm just no deep enough into osgi to understand > this properly yet. > >> I don’t think that’s true. Declarative Services is just a bundle, so you can >> add it to >> any OSGi application. Weblogic doesn’t need to support it, or even know >> anything about it. > > We do not want to be in another bundle. We want to access the osgi > application from the outside. But so far it seems to me that this is > something which is not very common to do using regular osgi services but most > likely using some webservie/Rest or the like instead. i don’t fully understand your scenario, but bear in mind that an OSGi application nearly always consists of multiple bundles. > 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.
