You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by David Bosschaert <da...@gmail.com> on 2015/04/21 15:23:32 UTC
javax.activation.DataHandler in OSGi
Hi all,
Apologies for posting to the Karaf list as this is not really a Karaf
issue, but I this list may contain people that might have come across
this issue as well.
I have some code that runs in OSGi that uses
javax.activation.DataHandler. As this is javax... you should be able
to provide your own bundle providing these classes. So I have a bundle
that provides an alternative javax.activation.DataHandler. Now it
turns out that this class has a dependency on
java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
code is kicked in from DataHandler, but then DataFlavor tries to load
some classes too, in my case it tries to load DataHandler again. The
code in DataFlavor tries to load classes from the System Classloader
first, so it finds the javax.activation.DataHandler in the JRE and
loads that -> boom LinkageError.
I was wondering whether there are any 'fixed' versions of
javax.activation that don't expose this behaviour and work properly in
a modular environment like OSGi.
Many thanks,
David
Re: javax.activation.DataHandler in OSGi
Posted by Bram Pouwelse <br...@pouwelse.com>.
Hi David,
If you want to be able to deploy a framework that isn't prepared you can
create a fragment bundle containing the javax.activation api with the
system bundle as fragment host. You still won't be able to swap
implementations at runtime as the framework needs to be restarted to
refresh such a fragment bundle.
Regards,
Bram
On Wed, Apr 22, 2015 at 9:33 AM David Bosschaert <da...@gmail.com>
wrote:
> Hi all,
>
> Thanks for the additional suggestions. I guess the unfortunate thing
> is for all of them that the JRE or framework configuration needs to be
> changed before it works...
>
> Just curious, is anyone aware of a modified/alternate version of
> javax.activation that does not suffer from this problem? I know
> similar things were done in the past in the Geronimo and ServiceMix
> projects...
>
> Thanks again,
>
> David
>
> On 22 April 2015 at 08:22, Freeman Fang <fr...@gmail.com> wrote:
> > Hi David,
> >
> > Could you put that activation bundle into the endorsed dir so that all
> > activation class and java.awt.datatransfer.DataFlavor could be loaded
> from
> > system class loader to avoid this problem? That's what Karaf do
> currently,
> > you can see org.apache.servicemix.specs.activation-api-1.1-2.4.0.jar in
> > $KARAF_HOME/lib/endorsed.
> >
> > －－－－－－－－－－－－－
> > Freeman(Yue) Fang
> >
> > Red Hat, Inc.
> > FuseSource is now part of Red Hat
> >
> >
> >
> > On 2015-4-21, at 下午9:23, David Bosschaert wrote:
> >
> > Hi all,
> >
> > Apologies for posting to the Karaf list as this is not really a Karaf
> > issue, but I this list may contain people that might have come across
> > this issue as well.
> >
> > I have some code that runs in OSGi that uses
> > javax.activation.DataHandler. As this is javax... you should be able
> > to provide your own bundle providing these classes. So I have a bundle
> > that provides an alternative javax.activation.DataHandler. Now it
> > turns out that this class has a dependency on
> > java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
> > code is kicked in from DataHandler, but then DataFlavor tries to load
> > some classes too, in my case it tries to load DataHandler again. The
> > code in DataFlavor tries to load classes from the System Classloader
> > first, so it finds the javax.activation.DataHandler in the JRE and
> > loads that -> boom LinkageError.
> >
> > I was wondering whether there are any 'fixed' versions of
> > javax.activation that don't expose this behaviour and work properly in
> > a modular environment like OSGi.
> >
> > Many thanks,
> >
> > David
> >
> >
>
Re: javax.activation.DataHandler in OSGi
Posted by David Bosschaert <da...@gmail.com>.
Hi all,
Thanks for the additional suggestions. I guess the unfortunate thing
is for all of them that the JRE or framework configuration needs to be
changed before it works...
Just curious, is anyone aware of a modified/alternate version of
javax.activation that does not suffer from this problem? I know
similar things were done in the past in the Geronimo and ServiceMix
projects...
Thanks again,
David
On 22 April 2015 at 08:22, Freeman Fang <fr...@gmail.com> wrote:
> Hi David,
>
> Could you put that activation bundle into the endorsed dir so that all
> activation class and java.awt.datatransfer.DataFlavor could be loaded from
> system class loader to avoid this problem? That's what Karaf do currently,
> you can see org.apache.servicemix.specs.activation-api-1.1-2.4.0.jar in
> $KARAF_HOME/lib/endorsed.
>
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
> On 2015-4-21, at 下午9:23, David Bosschaert wrote:
>
> Hi all,
>
> Apologies for posting to the Karaf list as this is not really a Karaf
> issue, but I this list may contain people that might have come across
> this issue as well.
>
> I have some code that runs in OSGi that uses
> javax.activation.DataHandler. As this is javax... you should be able
> to provide your own bundle providing these classes. So I have a bundle
> that provides an alternative javax.activation.DataHandler. Now it
> turns out that this class has a dependency on
> java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
> code is kicked in from DataHandler, but then DataFlavor tries to load
> some classes too, in my case it tries to load DataHandler again. The
> code in DataFlavor tries to load classes from the System Classloader
> first, so it finds the javax.activation.DataHandler in the JRE and
> loads that -> boom LinkageError.
>
> I was wondering whether there are any 'fixed' versions of
> javax.activation that don't expose this behaviour and work properly in
> a modular environment like OSGi.
>
> Many thanks,
>
> David
>
>
Re: javax.activation.DataHandler in OSGi
Posted by Freeman Fang <fr...@gmail.com>.
Hi David,
Could you put that activation bundle into the endorsed dir so that all activation class and java.awt.datatransfer.DataFlavor could be loaded from system class loader to avoid this problem? That's what Karaf do currently, you can see org.apache.servicemix.specs.activation-api-1.1-2.4.0.jar in $KARAF_HOME/lib/endorsed.
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
On 2015-4-21, at 下午9:23, David Bosschaert wrote:
> Hi all,
>
> Apologies for posting to the Karaf list as this is not really a Karaf
> issue, but I this list may contain people that might have come across
> this issue as well.
>
> I have some code that runs in OSGi that uses
> javax.activation.DataHandler. As this is javax... you should be able
> to provide your own bundle providing these classes. So I have a bundle
> that provides an alternative javax.activation.DataHandler. Now it
> turns out that this class has a dependency on
> java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
> code is kicked in from DataHandler, but then DataFlavor tries to load
> some classes too, in my case it tries to load DataHandler again. The
> code in DataFlavor tries to load classes from the System Classloader
> first, so it finds the javax.activation.DataHandler in the JRE and
> loads that -> boom LinkageError.
>
> I was wondering whether there are any 'fixed' versions of
> javax.activation that don't expose this behaviour and work properly in
> a modular environment like OSGi.
>
> Many thanks,
>
> David
Re: javax.activation.DataHandler in OSGi
Posted by David Bosschaert <da...@gmail.com>.
No, this doesn't work. The DataFlavor class explicitly uses the System
Classloader to load classes. If that fails then it uses the TCCL.
Because the javax.activation.DataHandler is also part of the JDK
(since Java 6) it finds it in the JRE and that's where the
LinkageError occurs. I have a workaround for the moment, simply using
the javax.activation classes from the JRE, but it's limiting me from
providing an alternative javax.activation implementation going
forward.
Thanks,
David
On 21 April 2015 at 14:45, Jamie G. <ja...@gmail.com> wrote:
> Can you manually set the class path in your bundle to pick up your
> classes first?
>
> I know that's a bit of a hack around, but if it works at least you can
> continue on...
>
> Cheers,
> Jamie
>
> On Tue, Apr 21, 2015 at 11:13 AM, David Bosschaert
> <da...@gmail.com> wrote:
>> I guess what I'm looking for is a bundle that I can install in an OSGi
>> framework without having to change any startup properties etc...
>>
>> On 21 April 2015 at 14:39, Jamie G. <ja...@gmail.com> wrote:
>>> Great question.
>>>
>>> Can you override/replace it via the karaf etc/jre.properties file?
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Tue, Apr 21, 2015 at 10:53 AM, David Bosschaert
>>> <da...@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> Apologies for posting to the Karaf list as this is not really a Karaf
>>>> issue, but I this list may contain people that might have come across
>>>> this issue as well.
>>>>
>>>> I have some code that runs in OSGi that uses
>>>> javax.activation.DataHandler. As this is javax... you should be able
>>>> to provide your own bundle providing these classes. So I have a bundle
>>>> that provides an alternative javax.activation.DataHandler. Now it
>>>> turns out that this class has a dependency on
>>>> java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
>>>> code is kicked in from DataHandler, but then DataFlavor tries to load
>>>> some classes too, in my case it tries to load DataHandler again. The
>>>> code in DataFlavor tries to load classes from the System Classloader
>>>> first, so it finds the javax.activation.DataHandler in the JRE and
>>>> loads that -> boom LinkageError.
>>>>
>>>> I was wondering whether there are any 'fixed' versions of
>>>> javax.activation that don't expose this behaviour and work properly in
>>>> a modular environment like OSGi.
>>>>
>>>> Many thanks,
>>>>
>>>> David
Re: javax.activation.DataHandler in OSGi
Posted by ch...@kiffer.ltd.uk.
He'll probably need to do that in the bootclasspath <sigh/>
At one time I actually believed that javax.* packages would always be
"extra", meaning that 1) no java.* class would depend on a javax.* class
and 2) therefore you could safely put all the javax.* classes into one or
more jar-files in the ext/ directory. And then ...
java.security.cert.X509CertSelector turned out to have a reference to
javax.security.auth.x500.X500Principal. java.awt refers to all manner of
stuff (and vice versa). Total dependency spaghetti.
No wonder project jigsaw is taking so long ...
> Can you manually set the class path in your bundle to pick up your
> classes first?
>
> I know that's a bit of a hack around, but if it works at least you can
> continue on...
>
> Cheers,
> Jamie
>
> On Tue, Apr 21, 2015 at 11:13 AM, David Bosschaert
> <da...@gmail.com> wrote:
>> I guess what I'm looking for is a bundle that I can install in an OSGi
>> framework without having to change any startup properties etc...
>>
>> On 21 April 2015 at 14:39, Jamie G. <ja...@gmail.com> wrote:
>>> Great question.
>>>
>>> Can you override/replace it via the karaf etc/jre.properties file?
>>>
>>> Cheers,
>>> Jamie
>>>
>>> On Tue, Apr 21, 2015 at 10:53 AM, David Bosschaert
>>> <da...@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> Apologies for posting to the Karaf list as this is not really a Karaf
>>>> issue, but I this list may contain people that might have come across
>>>> this issue as well.
>>>>
>>>> I have some code that runs in OSGi that uses
>>>> javax.activation.DataHandler. As this is javax... you should be able
>>>> to provide your own bundle providing these classes. So I have a bundle
>>>> that provides an alternative javax.activation.DataHandler. Now it
>>>> turns out that this class has a dependency on
>>>> java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
>>>> code is kicked in from DataHandler, but then DataFlavor tries to load
>>>> some classes too, in my case it tries to load DataHandler again. The
>>>> code in DataFlavor tries to load classes from the System Classloader
>>>> first, so it finds the javax.activation.DataHandler in the JRE and
>>>> loads that -> boom LinkageError.
>>>>
>>>> I was wondering whether there are any 'fixed' versions of
>>>> javax.activation that don't expose this behaviour and work properly in
>>>> a modular environment like OSGi.
>>>>
>>>> Many thanks,
>>>>
>>>> David
>
Re: javax.activation.DataHandler in OSGi
Posted by "Jamie G." <ja...@gmail.com>.
Can you manually set the class path in your bundle to pick up your
classes first?
I know that's a bit of a hack around, but if it works at least you can
continue on...
Cheers,
Jamie
On Tue, Apr 21, 2015 at 11:13 AM, David Bosschaert
<da...@gmail.com> wrote:
> I guess what I'm looking for is a bundle that I can install in an OSGi
> framework without having to change any startup properties etc...
>
> On 21 April 2015 at 14:39, Jamie G. <ja...@gmail.com> wrote:
>> Great question.
>>
>> Can you override/replace it via the karaf etc/jre.properties file?
>>
>> Cheers,
>> Jamie
>>
>> On Tue, Apr 21, 2015 at 10:53 AM, David Bosschaert
>> <da...@gmail.com> wrote:
>>> Hi all,
>>>
>>> Apologies for posting to the Karaf list as this is not really a Karaf
>>> issue, but I this list may contain people that might have come across
>>> this issue as well.
>>>
>>> I have some code that runs in OSGi that uses
>>> javax.activation.DataHandler. As this is javax... you should be able
>>> to provide your own bundle providing these classes. So I have a bundle
>>> that provides an alternative javax.activation.DataHandler. Now it
>>> turns out that this class has a dependency on
>>> java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
>>> code is kicked in from DataHandler, but then DataFlavor tries to load
>>> some classes too, in my case it tries to load DataHandler again. The
>>> code in DataFlavor tries to load classes from the System Classloader
>>> first, so it finds the javax.activation.DataHandler in the JRE and
>>> loads that -> boom LinkageError.
>>>
>>> I was wondering whether there are any 'fixed' versions of
>>> javax.activation that don't expose this behaviour and work properly in
>>> a modular environment like OSGi.
>>>
>>> Many thanks,
>>>
>>> David
Re: javax.activation.DataHandler in OSGi
Posted by David Bosschaert <da...@gmail.com>.
I guess what I'm looking for is a bundle that I can install in an OSGi
framework without having to change any startup properties etc...
On 21 April 2015 at 14:39, Jamie G. <ja...@gmail.com> wrote:
> Great question.
>
> Can you override/replace it via the karaf etc/jre.properties file?
>
> Cheers,
> Jamie
>
> On Tue, Apr 21, 2015 at 10:53 AM, David Bosschaert
> <da...@gmail.com> wrote:
>> Hi all,
>>
>> Apologies for posting to the Karaf list as this is not really a Karaf
>> issue, but I this list may contain people that might have come across
>> this issue as well.
>>
>> I have some code that runs in OSGi that uses
>> javax.activation.DataHandler. As this is javax... you should be able
>> to provide your own bundle providing these classes. So I have a bundle
>> that provides an alternative javax.activation.DataHandler. Now it
>> turns out that this class has a dependency on
>> java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
>> code is kicked in from DataHandler, but then DataFlavor tries to load
>> some classes too, in my case it tries to load DataHandler again. The
>> code in DataFlavor tries to load classes from the System Classloader
>> first, so it finds the javax.activation.DataHandler in the JRE and
>> loads that -> boom LinkageError.
>>
>> I was wondering whether there are any 'fixed' versions of
>> javax.activation that don't expose this behaviour and work properly in
>> a modular environment like OSGi.
>>
>> Many thanks,
>>
>> David
Re: javax.activation.DataHandler in OSGi
Posted by "Jamie G." <ja...@gmail.com>.
Great question.
Can you override/replace it via the karaf etc/jre.properties file?
Cheers,
Jamie
On Tue, Apr 21, 2015 at 10:53 AM, David Bosschaert
<da...@gmail.com> wrote:
> Hi all,
>
> Apologies for posting to the Karaf list as this is not really a Karaf
> issue, but I this list may contain people that might have come across
> this issue as well.
>
> I have some code that runs in OSGi that uses
> javax.activation.DataHandler. As this is javax... you should be able
> to provide your own bundle providing these classes. So I have a bundle
> that provides an alternative javax.activation.DataHandler. Now it
> turns out that this class has a dependency on
> java.awt.datatransfer.DataFlavor, a java.awt class! The DataFlavor
> code is kicked in from DataHandler, but then DataFlavor tries to load
> some classes too, in my case it tries to load DataHandler again. The
> code in DataFlavor tries to load classes from the System Classloader
> first, so it finds the javax.activation.DataHandler in the JRE and
> loads that -> boom LinkageError.
>
> I was wondering whether there are any 'fixed' versions of
> javax.activation that don't expose this behaviour and work properly in
> a modular environment like OSGi.
>
> Many thanks,
>
> David