Hi Ray,
According to the spec the bootdelegation packages should be delegated to
the parent classloader even before the Import-Package is checked. As I
understand it, the bootdelegation should only be used for packages that
are not explicitly imported, but should be available on the classpath
(e.g. JDK internal stuff like sun.*). When your bundle has an explicit
Import-Package to the package, my guess is that the package should be
exported by the system bundle, rather then bootdelegated, meaning that
you use the org.osgi.framework.system.packages.extra instead?
Tim
On 08/06/2014 09:18 AM, Raymond Auge 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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é*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect
*Liferay, Inc.*
<http://www.liferay.com/> (@Liferay)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.*
<http://www.liferay.com/> (@Liferay)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.*
<http://www.liferay.com/> (@Liferay)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.*
<http://www.liferay.com/> (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
<mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
<mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com/> (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Tim Verbelen
Department of Information Technology
Broadband Communication Networks (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
T: +32 9 33 14940 ; T Secr: +32 9 33 14900
F: +32 9 33 14899
E: [email protected]
W : www.ibcn.intec.UGent.be
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
