Mathieu, But where do you "receive" this URL from? It sounds like you have some kind of classpath scanner... is that how you were handling extensibility in your pre-OSGi code?
What Stuart is saying (and I strongly agree with) is that in OSGi we have a better way to handle this whole problem, called the Extender Model. Rather than trying to adapt your existing classpath scanning technique (which is fragile and hits this problem that resources URLs are actually just logical URIs) you should adopting the extender model because it does fit exactly with your requirements. If you want to read up on the extender model, check out Chapter 8 of my (free!) book at http://neilbartlett.name/blog/osgibook Regards Neil On Tue, Apr 28, 2009 at 10:26 AM, Triquoit Mathieu <[email protected]> wrote: > OK but I receive something like : bundle://140.0:1/org/mtr/resources. The > package org.mtr.resources contains properties files and I would like to load > these files. Is there a URL Converter or something like that ? > > Thanks, > > 2009/4/27 Stuart McCulloch <[email protected]> > >> 2009/4/27 Triquoit Mathieu <[email protected]> >> >> > Dear, >> > >> > I am currently migrating an application to the OSGi concepts... and I >> have >> > a >> > problem. In a general module (which could be a kind of framework), the >> > application dynamically loads properties files. >> > >> > To do that, it receives a path and loops on the URLs, check the protocol >> to >> > load the properties file (by example : if (protocol == file) ... else if >> > (protocol == jar) { <loop on the jar entry> } >> > >> > Now I receive the bundle protocol. How can I deal with that ? I would >> like >> > to do the same as for the jar (so open the Connection on the URL and >> > receive >> > something like a JarFile and loop on the JarEntry), is it possible ? >> >> >> I'm not sure that the "bundle:" protocol is actually part of the OSGi spec, >> but you could simply open the connection and see if the returned input >> stream is an instance of InflaterInputStream (or one of it's sub-classes) >> >> you can then pass the stream onto the relevant class to read entries, etc. >> >> you might also want to consider other ways you could achieve the same >> results that fit better with the OSGi model, for example you could have an >> extender bundle that sits and watches for bundles being started/installed >> and then either uses manifest entries (or the OSGi resource APIs) to look >> for relevant property files inside the bundles and act on them >> appropriately >> >> that's the approach taken in Spring-DM and other such frameworks >> >> Thank you in advance, >> > Best regards, >> > Mathieu >> > >> >> -- >> Cheers, Stuart >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
