You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Costin Leau (JIRA)" <ji...@apache.org> on 2007/09/30 17:40:50 UTC
[jira] Created: (FELIX-383) getResource()/getResources() called on
"/"
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.
[jira] Commented: (FELIX-383) getResource()/getResources() called
on "/"
Posted by "Costin Leau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540062 ]
Costin Leau commented on FELIX-383:
-----------------------------------
I've tested the snapshot and it seems to be working. Thanks!
Any idea on what's the ETA for 1.1 and when fragment support will be in?
Cheers,
Costin
> 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
> Assignee: Richard S. Hall
>
> 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.
[jira] Resolved: (FELIX-383) getResource()/getResources() called on
"/"
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall resolved FELIX-383.
-----------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
Ok, I have committed support for "/" URLs...we simply handle them as special cases. I still think this doesn't make much sense and it is not really correct, but it wasn't difficult to add. Costin, I deployed new snapshots, please close this issue if things look good.
> 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
> Assignee: Richard S. Hall
>
> 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.
[jira] Closed: (FELIX-383) getResource()/getResources() called on
"/"
Posted by "Costin Leau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Costin Leau closed FELIX-383.
-----------------------------
> 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
> Assignee: Richard S. Hall
>
> 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.
[jira] Commented: (FELIX-383) getResource()/getResources() called
on "/"
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531366 ]
Richard S. Hall commented on FELIX-383:
---------------------------------------
The issue at hand is that bundle resource URLs are supposed to be able to be used to build other resource URLs (either using a relative or absolute path). However, the difficulty is that any given resource URL actually refers to a given bundle class path index. For example, a bundle resource URL is constructed like this:
bundle://<bundle-id>:<class-path-idx>/path/to/resource
In this example the port portion of the URL refers to the index into the bundle's class path. It is necessary to do this since multiple resources can actually be reachable using the same path. The difficulty arises if you want to construct a URL to access class path index 1 with a resource URL from class path index 2, for example, which might happen since this scheme is opaque to the user. In such a scenario, it would not be possible to find the resource, since the port number would be 2, when in fact it should be 1.
I can only think of one half way reasonable approach to resolve this. We could first use the index to find the resource and if that succeeds, then we are done. On the other hand, if it fails, then we could just to a full bundle class path search for the resource and then the first one found on the bundle class path wins or if none exists, then it really doesn't exist.
This is not perfect, but I think it would at least give reasonable results in most cases. Comments?
> 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.
[jira] Commented: (FELIX-383) getResource()/getResources() called
on "/"
Posted by "Costin Leau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532152 ]
Costin Leau commented on FELIX-383:
-----------------------------------
Hmm - but if the constructed URLs can fail? Since getResources() returns URLs which point to different classpath roots, using each of these URLs will lead to a different classpath which might contain or not the items you are interested in.
For example you get bundle://1.1/ and bundle//1.2/
If you reuse the URL then you'll just be looking into classpath 1 rather then all classpath-es. So if you look for /foo/bar and you try in classpath1 you'll fail but if you try in classpath 2, you will find it for example.
The thing is getResources() is suppose to return a set of items which match a name while getResource() has to return only one item so in case of
getResources() I think it's okay if several URLs do not find the /foo/bar since they are actually different classpathes while in case of getResource()
the URL (only one) - it's a unified one.
How is this issue any different then a normal getResource("/foo") - what if I want to build another URL to /foo/bar using the previous URL 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.
[jira] Commented: (FELIX-383) getResource()/getResources() called
on "/"
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532197 ]
Richard S. Hall commented on FELIX-383:
---------------------------------------
Whether the resource exists in the bundle JAR, an embedded JAR, or an embedded directory doesn't really make a difference. The main issue is what is declared on the bundle class path and the order in which it is declared. So, Rob, as you end up concluding above, the bundle class path order determines what takes precedence over what (i.e., first one found on the bundle class path wins).
> 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.
[jira] Commented: (FELIX-383) getResource()/getResources() called
on "/"
Posted by "Rob Walker (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532174 ]
Rob Walker commented on FELIX-383:
----------------------------------
A good analysis ... and not wishing to complicate things - isn't there a 3rd possibility here:
- "resourceAB.txt" exists in the main bundle JAR, as well as (or instead of) an inner JAR.Presumably this would always take precedence if it occured in more than 1 place.
I wonder also if Classloader.getResource() has any convention we can follow here - strikes me that it must also deal with a case where a resource may occur at the same path in multiple JARs, and my guess is it searches them in classpath order if so.
In which case, I think my vote is with option (2) also
> 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.
[jira] Commented: (FELIX-383) getResource()/getResources() called
on "/"
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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.