cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Date Wed, 17 Aug 2005 19:36:41 GMT
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.

> Since a protocol is a Service, I assume that the ServiceFactory mechanism 
> would also work, in which case a protocol could "extract" context information 
> from the "requesting bundle" and use that to tailor the resulting connection, 
> including retrieving resources from with that client bundle.
> 
> I have not tested this for URLs but using something along those line in a 
> Log4J bundle, where the "default config" for a bundle is retrieved from the 
> requesting bundle.

Ok.

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

/Daniel

Mime
View raw message