You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jörg Hoh <jh...@googlemail.com.INVALID> on 2018/08/10 09:06:41 UTC
"partial fragment bundles"?
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
--
Cheers,
Jörg Hoh,
http://cqdump.wordpress.com
Twitter: @joerghoh
Re: "partial fragment bundles"?
Posted by Eduardo Garcia <gc...@cibinetonline.com>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: "partial fragment bundles"?
Posted by Robert Munteanu <ro...@apache.org>.
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 <
> rombert@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-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: "partial fragment bundles"?
Posted by Jörg Hoh <jh...@googlemail.com.INVALID>.
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.
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.
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 <
rombert@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Jörg Hoh,
http://cqdump.wordpress.com
Twitter: @joerghoh
Re: "partial fragment bundles"?
Posted by Robert Munteanu <ro...@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org