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/10/03 18:15:50 UTC

[jira] Commented: (FELIX-383) getResource()/getResources() called on "/"

    [ 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.