felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-383) getResource()/getResources() called on "/"
Date Sun, 30 Sep 2007 18:56:50 GMT

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


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.

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

View raw message