[
https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532171
]
Richard S. Hall commented on FELIX-383:
---------------------------------------
Starting to see some of the complications? :-)
Let's verify what we are talking about. Assume we have this situation:
Bundle-ClassPath: a.jar, b.jar
Assume a.jar contains resourceA.txt and resource AB.txt and b.jar contains
resourceB.txt and resourceAB.txt.
>From the user's perspective, a bundle is a single JAR file, so they might do
>something like:
bundle.getResources("resourceAB.txt");
And get back:
bundle://5:1/resourceAB.txt
bundle://5:2/resourceAB.txt
Where 5 = bundle ID and the port portion of the URL is the base 1 index of
bundle class path. Now since the user assumes that the bundle is one JAR file
he makes the assumption he can calculate the URL of resourceA.txt from either
one of these URLs. The first would result in the correct URL; however, if the
user chose to construct the URL from the second, it would not be incorrect.
We have two choices at this point: 1) the resource access fails or 2) we
initiate another bundle class path search for the resource (effectively
invoking Bundle.getResource() again).
I think 2 is the least problematic. If I understand correctly, I think Equinox
also does something similar.
So this first part is a discussion about what to do when constructing URLs from
other URLs. If, on the other hand, you call Bundle.getResources() you will get
the correct enumeration that follows all class path entries. That is not an
issue here.
However, there is another issue, which is what to return for "/". Again, this
is problematic, because there really isn't a single "/" to return for either
Bundle.getResource() or getResources(). We would just be forced to choose one
root, i.e., one bundle class path entry or use "-1" to signify that we search
the complete bundle class path for the first one found (using "-1" is
reasonably equivalent to what we propose above where we search the bundle class
path in case of a failure to find).
These issues are the same for both getResource() and getResources(). All bundle
resource URLs will contain some index into the bundle class path. If you
construct a URL from any resource URL you are likely to be searching the wrong
bundle class path entry, which is why we propose starting the search from
scratch if the original resource is not found.
> getResource()/getResources() called on "/"
> ------------------------------------------
>
> Key: FELIX-383
> URL: https://issues.apache.org/jira/browse/FELIX-383
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: 1.0.0
> Reporter: Costin Leau
>
> Moving from an email conversation to a JIRA issue to allow easier tracking.
> >> getResource/getResources called on "/".
> >> >>
> >> >> bundle.getResource("/") returns null while bundle.getResources("/")
> >> >> returns an empty enumeration.
> >> >>
> >> >> On equinox they return an actual URL to the root of the bundle,
> >> >> respectively a list of URLs on root for all attached bundles. I'm not
> >> >> sure what's the exact behaviour in this area as the spec seems to be
> >> >> unclear on it and that's why I'm asking.
> >> >>
> >> >> For practical reasons, getResource on root is useful when doing pattern
> >> >> matching against a classpath resource - i.e. /org/**/MyClass.class
> >> >>
> > >
> > > This is still in my inbox from before...I did some initial
> > > experimentation with it and was never happy enough with it to commit it.
> > > I know it seems like an easy thing, but it really isn't since a bundle
> > > with a class path with embedded JARs and directories doesn't really have
> > > a single "/" root. This is something that I will still give more thought
> > > to...I assume that your situation could be resolved by just treating "/"
> > > as the root of the physical bundle, right? Or are you expecting to find
> > > content from embedded class path entries too?
> > >
> For getResource() only one classpath has to be chosen and the root of
> the physical bundle seems like a good choice since that one will always
> be present.
> Things are different when using getResources() since there, the embedded
> libraries and fragments root folders can be returned for example.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
