At first hand, if there is a difference in javax.activation.datahandler package version (JVM vs Sling), you can restrict that to use only the version needed by third-part library to work properly.
Best wishes, On 08/10/2018 03:06 AM, Jörg Hoh wrote: > Hi, > > We run an OSGI-based application with Apache Sling, and there we use the > org.apache.sling.javax.activation bundle (see [1] for the reason why it has > been introduced). Now we are required to update a third-party library, > which started to use the javax.activation.datahandler package; 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. > > Is there a way that we can modify/rewrap this 3rd-party library in a way, > that it loads javax.activation always directly from the JVM (system bundle) > instead from the sling bundle? Just like a fragment attached to the system > bundle would do, but only visible and valid for this specific 3rd party > library? > > The other way would be to remove sling.javax.activation from our > application and replace it by a fragment bundle, but that might have a lot > of consequences we want to avoid. > > Jörg > > > [1] https://issues.apache.org/jira/browse/SLING-2835 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
