felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: OSGi-aware resource loading
Date Tue, 03 Sep 2013 18:53:39 GMT

Le 3 sept. 2013 à 12:49, Robert Munteanu <robert@lmn.ro> a écrit :

> On Tue, Sep 3, 2013 at 1:42 AM, Nicolas Lalevée
> <nicolas.lalevee@hibnet.org> wrote:
>> 
>> Le 2 sept. 2013 à 18:15, Murad Mamedov <mail@muradm.net> 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
>>> <nicolas.lalevee@hibnet.org>wrote:
>>> 
>>>> 
>>>> Le 2 sept. 2013 à 10:34, Christian Schneider <chris@die-schneider.net>
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 <heavy@ungoverned.org>
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: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>> 
>>>>> Open Source Architect
>>>>> http://www.talend.com
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> 
> 
> -- 
> Sent from my (old) computer
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message