cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Date Wed, 17 Aug 2005 21:15:07 GMT
Daniel Fagerstrom wrote:

> Niclas Hedhman wrote:
>
>> On Wednesday 17 August 2005 22:09, Daniel Fagerstrom wrote:
>>
>>>> And BTW, unless I missed something I haven't seen an explicit
>>>> reference to the "bundle:" protocol in the OSGi specs, at least in R3.
>>>
>>>
>>> Didn't found it either, maybe it is Knopflerfish specific. But even 
>>> if it is, the OSGi api have no direct ways for accessing a resource 
>>> from any bundle, you must specify from what bundle you want to read 
>>> a resource. Maybe there is a way to do it in some more indirect way.
>>
>>
>> It is probably a protocol available to be 'installed' at your own 
>> leisure (i.e. the core beauty of OSGi). I have not bothered with it.
>
>
> Don't know, but I would assume that all OSGi implementation would need 
> something like the bundle: protocol (although the name and syntax 
> might not be standardized). Say that you have two bundles A and B that 
> both contain the resource "foo.xml". If you use "URL 
> getResource(String)" at the Bundle object of the A bundle the 
> resulting URL must contain a reference to the A bundle to not confuse 
> it with "foo.xml" from the B bundle.


Sure, but that's for the Bundle.getResource() method. What we're talking 
about here is ClassLoader.getResource() which follows a different 
resolution scheme and returns an URL that is resolved through the 
bundle's classpath and points to the actual resource in a jar file or 
class directory in the target bundle, e.g. 
"jar://file://path/to/bundle-repo/foo-bundle/lib.jar!/path/to/resource".

>> I think quite a fair bit in Cocoon should use URLs and custom 
>> protocols, and implement those through the OSGi URL service mechanism.
>
>
> Yes, that would remove the need to depend on the Source interface in 
> blocks and make it possible to use external libraries that requires 
> java.net.URL.


Yup. Being able to use the standard java.net.URL class instead of the 
SourceResolver will be a very nice thing. The only problem is the 
infiamous SourceResolver.resolve() that has no equivalent on 
URLConnection and which is needed for only one protocol, but an 
important one which is "cocoon:"...

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message