Hi, I had problems with XML parsing before with older technologies (that use the Factory classes). That is why I created a bundle <http://search.maven.org/#artifactdetails%7Corg.everit.osgi.bundles%7Corg.everit.osgi.bundles.org.apache.xmlcommons.full%7C1.4.1-20140713%7Cbundle> that contains all of the implementations and API from apache xml-commons: Xalan, Xerces, ... By using this bundle in your runtime, you will not have problems with Factories if you want to parse XML.
I started to use OSGi in the way that I add only those packages from the JDK that is really necessary. I use bundles for every package where it is possible. E.g.: I created a bundle <http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.everit.osgi.bundles%22%20AND%20a%3A%22org.everit.osgi.bundles.javax.sql%22> that contains javax.sql packages and I do not use it from the JDK. E.g.: To run a jetty container and have persistence based on Querydsl and Liquibase, only the following packages must be defined in system.packages: javax.imageio, javax.naming, javax.naming.spi, javax.net, javax.net.ssl, javax.management, javax.management.modelmbean, javax.management.remote, javax.security.auth, javax.security.cert, org.ietf.jgss, javax.crypto, javax.crypto.spec, javax.naming.ldap, javax.security.auth.callback, javax.security.auth.login, javax.security.auth.x500 In my experience, if we use technologies from bundles instead of JDK (like JAXB), only a few packages must be listed from the JDK. Some of them is not even used in OSGi at runtime (like javax.naming) but they are imported with resolution:=required in the jetty bundles. Hopefully with JEP-200 <http://openjdk.java.net/jeps/200> and JEP-201 <http://openjdk.java.net/jeps/201>, it will be easy to re-package parts of the JDK so all of them can be used from OSGi bundles. Regards, *Zsoldos Balázs* On Wed, Aug 6, 2014 at 9:38 AM, Neil Bartlett <[email protected]> wrote: > 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é* <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 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OSGi Developer Mail List >>>>>> [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] >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> [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 > > > _______________________________________________ > 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
