Le 2 sept. 2013 à 18:15, Murad Mamedov <[email protected]> a écrit :
> Hello, I'm newbie here, but using OSGi for long time. > > From my understanding of your problem: > - you expect some bundles to have build.xml > - you are a build system that does somethings with those bundles. > If above is true, I would start BundleListener and listen bundle events. Of > course, on startup of build system you will need to get the initial list of > bundles your self. > Once BundleListener gets event on installed bundle, I would check if it is > my bundle (has build.xml for example) and keep it in private map (ex: > taskName -> Bundle). > This will be faster and more dynamic, better than traversing over bundles > every time. The thing is that I don't expect a "build" bundle to only have a build.xml at a precise location. I could be anywhere, named in any way. For instance there can be a bundle in which there would be a common-build-java.xml and a common-build-resources.xml, in anther bundle a common-build-webapp.xml which is importing the former ones, and my main build.xml is just importing the later one. I would really like the build files to behave like Java classes in this OSGi environment. > But I'm still not sure if you can access actual ClassLoader of that bundle > even if you have it and for example instantiate some class from there. > You have to depend (import somethings from it) on that bundle, but as far > as I understand you expect unknown user ant tasks to be around in unknown > user bundles. > Is it possible to get actual class loader of some bundle and do something > with it? Well, I don't need a classloader per se. To make a build file load an Ant task, I need something to load a class, so Bundle#loadClass() is fine. And to make a build file import another one, I need something to load a resource, so Bundle#findEntries() is fine too. > Using services could be a better option for this problem in my opinion. Could you elaborate on that ? I know a little bit about services but not enough to understand what kind of solution you are thinking of. cheers, Nicolas > > Regards, > Murad > > > > On Mon, Sep 2, 2013 at 5:59 PM, Nicolas Lalevée > <[email protected]>wrote: > >> >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
