On Mon, 2018-08-13 at 16:20 +0200, Jörg Hoh wrote: > Hi Robert, > > this 3rd party library is a bit complicated ... from what I > understood it > hasn't been developed with OSGI in mind (but rather for application > server > use), and fiddles around with classloaders etc. I was told that the > this > library internally internally loads classes from the JVM, effectivly > ignoring the OSGI classloader partially.
(usually this is a recipe for lost of fun :-) ) > > Our idea is allow this bundle (we packaged the library into a single > bundle) to use the javax.activation classes from the JVM directly, > and > ignore the sling bundle for it; all the other bundles are supposed to > use > the sling bundle though. This would have the least impact to the rest > of > the system. That may or may not be advisable. The JVM will flat out reject two classes with the same name but different classloaders being available in the same class space, e.g. Bundle A -> imports javax.activation from System Bundle (with fragment) BUndle B -> imports javax.activation from Sling's bundle At this time Bundle A and Bundle B cannot exist in the same class space. This may be why the resolver has favoured the exports from the system bundle, via the fragment you introduced. If the library is a low-level one that is referenced from many other bundles then this is pretty much expected. Robert > > Today we tried to export the JVM classes by fragment bundle with the > export > statement "javax.activation;version=0.0.1" and import this version > from the > bundle; while this made the bundle use the fragment as we intended, > all > other bundles were now using this fragment as well (which was not our > plan). > > Do you see any other option we can try? > > > > > > > > > > > Am Mo., 13. Aug. 2018 um 11:05 Uhr schrieb Robert Munteanu < > romb...@apache.org>: > > > Hi Jörg, > > > > On Fri, 2018-08-10 at 11:06 +0200, Jörg Hoh wrote: > > > and it turns > > > it that this library uses both the JVM-provided classes as well > > > as > > > the > > > classes provided by the sling bundle, thus failing to run > > > properly. > > > > What error do you get? Is it the cheerful uses constraints > > violation? > > One possible problem is that the packages exported by the Sling are > > not > > substitutable with the ones exported by the JVM, thus leading to > > inconsistent class spaces. > > > > One possible solution is to tweak the packages exported by the JVM > > so > > that they are substitutable with the ones form the Sling bundle. > > > > But that leads me to the question - do you export javax.activation > > from > > both the system bundle and the Sling bundle? > > > > Thanks, > > > > Robert > > > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
