Le 3 sept. 2013 à 12:49, Robert Munteanu <[email protected]> a écrit :
> On Tue, Sep 3, 2013 at 1:42 AM, Nicolas Lalevée > <[email protected]> wrote: >> >> 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. > > You could add them to the manifest of the providing bundle, using the > Provide-Capability header [1], for instance > > Provide-Capability: build.file; location=/common-build-java.xml I like this header. But since here I manage files and not abstract concept, I can stick with the Import/Export Package headers. This would just require the common build files to be in their custom packages, just like Java classes. Nicolas > > Robert > > >> >> 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. > > [1]: http://wiki.osgi.org/wiki/Provide-Capability > >> >>> 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] >> > > > > -- > Sent from my (old) computer > > --------------------------------------------------------------------- > 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]
