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)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
