[
https://issues.apache.org/jira/browse/FELIX-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall closed FELIX-2940.
----------------------------------
Resolution: Duplicate
This is a duplicate of FELIX-2935. I will close this issue and report back
using the other issue. Your explanation is correct, as I determined with more
investigation on the other issue. Thanks for reporting this.
> JARs with unusual zip entry order can result in duplicate entries of
> Bundle.getEntryPaths()
> -------------------------------------------------------------------------------------------
>
> Key: FELIX-2940
> URL: https://issues.apache.org/jira/browse/FELIX-2940
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.2.0
> Reporter: Sander Dahlberg
> Priority: Minor
>
> The root entry paths of the org.apache.felix.shell.tui-1.2.0 bundle contains
> two META-INF/ entries, when obtained through bundle.getEntryPaths("/").
> This is caused by two facts:
> 1) The shell tui artifact both contains the META-INF/ and
> META-INF/MANIFEST.MF entries, but in the 'wrong' order.
> > jar -tf org.apache.felix.shell-1.2.0.jar
> META-INF/MANIFEST.MF
> META-INF/
> etc.
> 2) EntryFilterEnumeration's findNext method first synthesizes a "META-INF/"
> entry while examining "META-INF/MANIFEST.MF" and returns it, while on next
> invocation of findNext() the "META-INF/" entry is examined and returned again.
> AFAIKS the easiest fix would be in findNext(): check that a zip entry under
> examination is not synthesized before. As synthesized directory entries are
> maintained in the m_dirEntries map, adding the restriction to the
> if-statement on line 201 that entryName should not exist in that map would
> probably suffice.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
