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