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
