Le 2 sept. 2013 à 10:34, Christian Schneider <[email protected]> a écrit :
> I think it would be a bad idea to rely on an URI scheme. After all it is not > specified in the OSGi standard. > Can't you simply forward the bundle or classloader together with the URL? The URL is pointing to a build file which I want to "run" within its bundle just like a java class would do. When running it will probably need to load resources, and I want this loading to follow the OSGi visibility rules. So I would need the classloader which "owns" that resource, and I don't have it, the OSGi framework has. Nicolas > > Christian > > On 02.09.2013 10:13, Nicolas Lalevée wrote: >> Le 1 sept. 2013 à 22:28, Richard S. Hall <[email protected]> a écrit : >> >>> I'm pretty sure this isn't possible for resources, like it is for classes. >>> >>> The OSGi spec doesn't mandate the format of bundle resource URLs, which is >>> what you would need if you wanted to determine from which bundle a looked >>> up resource comes. >>> >>> Not sure about other frameworks, but this is fairly easy to determine from >>> a resource URL in the Felix framework, since this host is the bundle id + >>> revision id. >> I can do an if(felix) in my code to optimize. In the long term can I rely on >> this URL scheme ? >> >> Nicolas >> >> >>> -> richard >>> >>> On 9/1/13 11:31 , Nicolas Lalevée wrote: >>>> Hi, >>>> >>>> Maybe my issue has already been addressed several time, so here is the >>>> actual question: how can I get the bundle/classloader which *owns* the URL >>>> which I looked up through classloader.getResource(file) ? >>>> >>>> If it's not clear, here is my context. >>>> >>>> I am experimenting a build system where some Ant build files and Ant task >>>> would be managed like as OSGi bundles. So I can do a modularisation of >>>> build files and jars of Ant Tasks. >>>> >>>> At some point a build file (within a bundle) will have to load some other >>>> Ant script (through the bundle wiring). For that I simply get the >>>> classloader of the current classloader and do a >>>> classloader.getResource("/path/other/build.xml"). So far so good. >>>> But when running that other build file, I would need its classloader to do >>>> some other import of build.xml file. But I only have the resolved URL, not >>>> the bundle which is containing the resolved script. Which java code, it's >>>> simple, from the resolved class I can get its classloader. But I cannot do >>>> that for a script which as been resolved as an URL. >>>> >>>> Here is what I have manage to do so far but I find it not pretty: >>>> >>>> URL buildUrl = currentClassLoader.getResource(buildFile); >>>> ClassLoader buildClassLoader = null; >>>> for (Bundle bundle : allBundles) { >>>> BundleWiring wiring = bundle.adapt(BundleWiring.class); >>>> int i = buildFile.lastIndexOf('/'); >>>> String path = buildFile.substring(0, i); >>>> String name = buildFile.substring(i + 1); >>>> List<URL> entries = wiring.findEntries(path, name, 0); >>>> if (!entries.isEmpty() && containsUrls(entries, buildUrl)) { >>>> buildClassLoader = wiring.getClassLoader(); >>>> break; >>>> } >>>> } >>>> if (buildClassLoader == null) { >>>> throw new RuntimeException("WTF! Unable to find the classloader of >>>> the build file " + buildFile); >>>> } >>>> >>>> It is working but it doesn't sound nice. Is there an API I didn't found >>>> which allows to look for a resource and its bundle or classloader ? I >>>> would prefer an OSGi API, but if it's a Felix one I don't mind. >>>> >>>> Nicolas >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
