Hmm… *if* that is the case then I *might* agree with you. I’d like to know who
actually depends on these packages, ultimately?
I think it would be worth going back to the beginning. If you neither import
the com.sun.apache.* packages, nor bootdelegate them either, exactly how does
the system fail? If it’s a NCDFE/CNFE, then from which class/classloader does
this originate?
Neil
On 6 August 2014 at 12:05:27, Felix Meschberger ([email protected]) wrote:
Hi
Except, that reality sometimes bytes you (at least I have been bitten…)
Your bundle imports the javax.xml factories and just calls those factories.
Turns out that classloader circumstances caused a the bootdelegation of
com.sun.* to be required such that the factories could actually load the actual
classes, e.g. DocumentBuilderFactory loading the DocumentBuilder.
While the javax.xml dependency is the one the bundle uses and declares, the
com.sun implementation package "dependency" is unknown and transparent to the
bundle - and the bundle must not care at all.
… maybe I am missing a point.
Regards
Felix
Am 06.08.2014 um 12:07 schrieb BJ Hargrave <[email protected]>:
What Neil said...
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Neil Bartlett <[email protected]>
To: Raymond Auge <[email protected]>, OSGi Developer Mail List
<[email protected]>
Date: 2014/08/06 03:33
Subject: Re: [osgi-dev] JDK xml implementation classes
Sent by: [email protected]
Hi Ray,
I would caution against using bootdelegation this way, as tempting as it might
be. If you do this then the dependency on those XML packages is essentially
hidden. For example, if you give the bundle to somebody else, how are they
supposed to know that the packages are needed as a dependency? They will not
find out until they get runtime errors like NCDFE/CNFE.
It really is better to allow the packages to be imported into the bundle that
uses them, and then arrange for them to be exported by the system bundle. This
can be done with org.osgi.framework.system.packages.extra, or with a system
bundle fragment. Alternatively on some JREs you might need to supply them from
a separate bundle.
Regards,
Neil
On 6 August 2014 at 08:18:46, Raymond Auge ([email protected]) wrote:
HAZZAAA!!!
Ok, my assumption was correct. Apparently, packages already declared in
Import-Package cannot be ignored by the framework and therefore cannot be
supplied via bootdelegation.
However, when removing the packages from the imports, they are loaded via
bootdelegation if available.
- Ray
On Wed, Aug 6, 2014 at 12:12 AM, Raymond Auge <[email protected]> wrote:
Does it matter that the bundle is declaring these imports?
Will this cause the bootdelegation to fail (perhaps because the framework must
enforce the imports with real provided packages)?
I guess the only way to find out is to hack the manifest of the bundle...
- Ray
On Wed, Aug 6, 2014 at 12:03 AM, Raymond Auge <[email protected]> wrote:
Sadly, it's not working for me. I'm using equinox btw.
I'll keep trying though as I feel more confident that this is the correct
approach.
On Tue, Aug 5, 2014 at 11:58 PM, Raymond Auge <[email protected]> wrote:
Yes it is :) I will test this.
Thank you
- Ray
On Tue, Aug 5, 2014 at 11:55 PM, Felix Meschberger <[email protected]> wrote:
Hi Ray
We are using
org.osgi.framework.bundle.parent=framework
If this is what you were referring to.
Regards
Felix
Am 06.08.2014 um 08:51 schrieb Raymond Auge <[email protected]>:
Thank you Felix.
Do you know which mode of the framework classloader is required for
bootdelegation to work when embedded?
I tried the bootdelegation earlier, but I didn't not succeed. However, I am
running embedded so that may play into my issue.
Sincerely,
- Ray
On Tue, Aug 5, 2014 at 11:42 PM, Felix Meschberger <[email protected]> wrote:
Hi
I think this bundle is just wrong: It is declared to not depend on com.sun
classes and the com.sun.org.apache classes are repackagings to not collide with
the official (and potentially newer versions) of these classes.
And yes, we also generally do a boot delegation to com.sun.* and sun.* for the
sake of supporting the javax.xml factories to be able to get to the
implementation details.
Regards
Felix
Am 06.08.2014 um 02:24 schrieb Raymond Auge <[email protected]>:
An example of a osgi bundle which requires such packages is:
javax.servlet.jsp.jstl [1]
While I can certainly export all these packages from the system bundle by hand,
I'm wondering there's any mechanism which might simplify the task, and the
maintenance of such over time.
[1] http://search.maven.org/#browse%7C-1002239558
On Tue, Aug 5, 2014 at 5:16 PM, Raymond Auge <[email protected]> wrote:
Is it wrong to use
org.osgi.framework.bootdelegation=com.sun.org.apache.*
- Ray
On Tue, Aug 5, 2014 at 5:08 PM, Raymond Auge <[email protected]> wrote:
Specifically, I'm talking about
com.sun.org.apache.*
On Tue, Aug 5, 2014 at 5:03 PM, Raymond Auge <[email protected]> wrote:
What's the best approach to allowing use of the com.sun.* xml packages provided
by Java SE?
There's a huge number of packages there and listing them out is tedious!
Note that the problem is not direct use of container classes, but because the
way the XML factories/providers handle creating impls.
Someone must have tackled this before.
Thoughts?
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
