OK, after further review, this bundle actually extends and/or implements from these packages.
This use comes from to "xml" jstl tags. So, the reason I see no errors, is because we don't use these tags. On Wed, Aug 6, 2014 at 10:09 PM, Raymond Auge <[email protected]> wrote: > Hello All, > > I'm planning to file a bug report with the JSTL RI project to correct the > manifest (I've been having good luck with the Java EE maintainers recently). > > However, I want to make sure I report the issue correctly and so I'd like > to understand something I'm seeing when inspecting the bundle using bnd. > > I'm "patching" the original lib using the following bnd file: > > [trimmed] > Export-Package: org.apache.taglibs.standard.*;version=1.2.3 > Import-Package:\ > !com.sun.*,\ > org.apache.taglibs.standard.*;version=1.2.3 > Include-Resource: @lib/javax.servlet.jsp.jstl.jar > > After creation inspection with bnd print produces the following warnings: > > 1 : Unresolved references to [com.sun.org.apache.xalan.internal.res, > com.sun.org.apache.xml.internal.utils, com.sun.org.apache.xpath.internal, > com.sun.org.apache.xpath.internal.jaxp, > com.sun.org.apache.xpath.internal.objects] by class(es) on the > Bundle-Classpath[Jar:javax.servlet.jsp.jstl.jar]: > [org/apache/taglibs/standard/tag/common/xml/JSTLXPathFactory.class, > org/apache/taglibs/standard/tag/common/xml/JSTLXPathImpl.class] > > So it appears that the classes in question actually "use" these classes > (as opposed to them being produced by factories as was discussed earlier). > > Will this fail if those classes are ever accessed? I'm betting yes > (although I've seen no issues in practice). > > Secondly this bundle is actually built using the maven-bundle-plugin:1.4.3 > (which uses an an ancient version of bnd; 0.0.255) and the bundle does NOT > explicitly export these Java SE packages. > > The pom actually only contains: > > <Export-Package> > org.apache.taglibs.standard, > org.apache.taglibs.standard.extra.spath, > org.apache.taglibs.standard.functions, > org.apache.taglibs.standard.lang.jstl, > org.apache.taglibs.standard.lang.jstl.parser, > org.apache.taglibs.standard.lang.jstl.test, > org.apache.taglibs.standard.lang.jstl.test.beans, > org.apache.taglibs.standard.lang.support, > org.apache.taglibs.standard.resources, > org.apache.taglibs.standard.tag.common.core, > org.apache.taglibs.standard.tag.common.fmt, > org.apache.taglibs.standard.tag.common.sql, > org.apache.taglibs.standard.tag.common.xml, > org.apache.taglibs.standard.tag.el.core, > org.apache.taglibs.standard.tag.el.fmt, > org.apache.taglibs.standard.tag.el.sql, > org.apache.taglibs.standard.tag.el.xml, > org.apache.taglibs.standard.tag.rt.core, > org.apache.taglibs.standard.tag.rt.fmt, > org.apache.taglibs.standard.tag.rt.sql, > org.apache.taglibs.standard.tag.rt.xml, > org.apache.taglibs.standard.tei, > org.apache.taglibs.standard.tlv, > org.glassfish.jstl.integration > </Export-Package> > > So!!! What is really the (minimal) solution here? > > 1) Is it OK to simple add a negative package reference as I did to fix the > bundle: > > !com.sun.*, > > Or will this lead to potential problems if the using classes are every > used. > > 2) Should the classes actually be fixed to not use > those com.sun.* packages directly? > > I assume 2) to be the preferred solution. However, I'd like to offer > whatever minimal change might be most tolerable to the developers. > > Sincerely, > - Ray > > > > > > > On Wed, Aug 6, 2014 at 11:48 AM, Raymond Auge <[email protected]> > wrote: > >> There is one caveat to the above. >> >> I must use >> >> org.osgi.framework.bundle.parent=framework >> >> otherwise, I return to the same original problem. >> >> But I'm ok with setting this. >> >> - Ray >> >> >> On Wed, Aug 6, 2014 at 11:02 AM, Raymond Auge <[email protected]> >> wrote: >> >>> On Wed, Aug 6, 2014 at 4:27 AM, Neil Bartlett <[email protected]> >>> wrote: >>> >>>> 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? >>>> >>> >>> Actually, as it turns out when I "fix" the offending bundle so it does >>> not import the com.sun.* packages AND I do NOT bootdelegate those packages, >>> everything just works AND I remove the system bundle exports I had added to >>> satisfy those bad imports everything starts to work as it should. >>> >>> There were apparently side effects to other bundles using Java SE >>> provided xml parsing because of the exports. >>> >>> *Summary* >>> Fixing the "bad" bundle's imports and removing the system bundle exports >>> solved the problem for me. >>> >>> Thanks everyone! >>> - Ray >>> >>> >> >> >> -- >> *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
