You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Sauthier <Gu...@objectweb.org> on 2008/01/16 17:09:01 UTC
ClassLoader.getResources() not overrided
Hi team
I've just noticed that the ContentClassLoader do not override the
ClassLoader.getResources(String) method.
It only override the ClassLoader.getResource(String method). Notice the
final 's', one of theses methods is returning an Enumeration, not the
other one.
Moreover, the ISearchPolicy, that is used under the hood to find
resources have a findResources(String):Enumeration method :)
I expect getResources() to list resources available to the bundle (using
OSGi constraints), not only "local" resources, which is the current
behavior.
This is probably something forgotten :)
Can you enlight me ? Is this normal, or not ?
Cheers
--Guillaume
Re: ClassLoader.getResources() not overrided
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Rob Walker wrote:
>
>> I think, the method should rather gather all enumerations and returned a
>> combined enumeration over all results ...
>>
>> WDYT ?
>>
>>
> Seems fine - my only comments from a quick re-read of the spec for
> Bundle.getResources would be to ensure we observe restrictions:
>
> * If the bundle state is INSTALLED - only it's own local resources
> should be searched and returned
> * If the state is RESOLVED or above - only imported packages in
> addition to local ones should be searched
Currently, it seems that we always try to resolve the module (trying to
be in the RESOLVED state). if there is an issue somewhere, there will be
an Exception and we will only look into local resources.
# comment
At this point, no boot-delegation packages are tried to search the
resource. Is this OK ?
# /comment
If the bundle is RESOLVED, then we try to load the resources in this order :
1. bootdelegation packages
2. modules imports
3. local resources
4. dynamic import
When you say that only imported packages (in addition to the local ones)
should be seached, you exclude dynamic imported packages ?
Regards
--Guillaume
>
>
> I'd guess our current approach does observe these - but just exits
> early on a first hit, and doesn't continue into imported packages.
>
> -- Rob
>
>
Re: ClassLoader.getResources() not overrided
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Rob,
Am Donnerstag, den 17.01.2008, 10:59 +0200 schrieb Rob Walker:
> > I think, the method should rather gather all enumerations and returned a
> > combined enumeration over all results ...
> >
> > WDYT ?
> >
> >
> Seems fine - my only comments from a quick re-read of the spec for
> Bundle.getResources would be to ensure we observe restrictions:
>
> * If the bundle state is INSTALLED - only it's own local resources
> should be searched and returned
> * If the state is RESOLVED or above - only imported packages in
> addition to local ones should be searched
>
>
> I'd guess our current approach does observe these - but just exits early
> on a first hit, and doesn't continue into imported packages.
That's the essence of my tons of words :-)
Regards
Felix
Re: ClassLoader.getResources() not overrided
Posted by Rob Walker <ro...@ascert.com>.
> I think, the method should rather gather all enumerations and returned a
> combined enumeration over all results ...
>
> WDYT ?
>
>
Seems fine - my only comments from a quick re-read of the spec for
Bundle.getResources would be to ensure we observe restrictions:
* If the bundle state is INSTALLED - only it's own local resources
should be searched and returned
* If the state is RESOLVED or above - only imported packages in
addition to local ones should be searched
I'd guess our current approach does observe these - but just exits early
on a first hit, and doesn't continue into imported packages.
-- Rob
Re: ClassLoader.getResources() not overrided
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Richard,
Am Donnerstag, den 17.01.2008, 10:20 -0500 schrieb Richard S. Hall:
> Felix Meschberger wrote:
> >>>
> >> Certainly you can do that for your own project, but I am not sure how
> >> easily it could be integrated into Felix...this is a case where we could
> >> use #ifdef, I guess. :-)
> >>
> >
> > With a bit of hackery: Have a factory method creating the
> > ContentClassLoader instances, which decides at runtime, whether to
> > create a pre-5 ContentClassLoader or a 5+ ContentClassLoader. But I will
> > certainly advocate for such a solution here :-)
> >
>
> I assume you meant to say, "...will certainly NOT advocate..."
Oops. Of course, my brains were faster than my fingers once again ;-)
Regards
Felix
Re: ClassLoader.getResources() not overrided
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Felix Meschberger wrote:
> Hi,
>
> Am Mittwoch, den 16.01.2008, 13:37 -0500 schrieb Richard S. Hall:
>
>> Guillaume Sauthier wrote:
>>
>>> After a bit of thinking, I was wondering if a possible solution could
>>> be to have the ability to change the ContentClassLoader implementation.
>>>
>>> If something like this was present, I could have my own JDK5 only
>>> ContentClassLoader that extends ContentClassLoader and override the
>>> getResources method.
>>>
>>> What do you think ?
>>> May I start to create a patch for that ?
>>>
>> Certainly you can do that for your own project, but I am not sure how
>> easily it could be integrated into Felix...this is a case where we could
>> use #ifdef, I guess. :-)
>>
>
> With a bit of hackery: Have a factory method creating the
> ContentClassLoader instances, which decides at runtime, whether to
> create a pre-5 ContentClassLoader or a 5+ ContentClassLoader. But I will
> certainly advocate for such a solution here :-)
>
I assume you meant to say, "...will certainly NOT advocate..."
> But reconsidering the initial problem mentioned by Guillaume: Only local
> resources returned. I am not sure why Guillaume mentions the
> ContentClassLoader, because the main accessor to resource Enumeration is
> the Bundle.getResources method. So I dug into how Bundle.getResources is
> actually implemented down to the
> org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findResources() method. And then, something stroke me in this method:
>
> Instead of returning a combined enumeration of all resources found, the
> method aborts upon first success:
>
> * If an Enumeration is returned as per the boot delegation, this is
> returned ignoring the
> wires and bundle
> * If an Enumeration is returned in a wire, this is returned ignoring
> any other wires and
> the bundle
> * Then the bundle is searched and returned if found
> * Finally dynamic imports are returned tested
>
> I think, the method should rather gather all enumerations and returned a
> combined enumeration over all results ...
>
> WDYT ?
>
Yes, I think you are correct.
-> richard
> Regards
> Felix
>
>
>> -> richard
>>
>>
>>> Thanks
>>> --Guillaume
>>>
>>> Guillaume Sauthier wrote:
>>>
>>>> Thanks for your input Felix
>>>> That was not the answer I was expecting :)
>>>>
>>>> Anyway, do you have any idea about how to workaround this problem ?
>>>>
>>>> Thanks
>>>> --Guillaume
>>>>
>>>>
>>>> Felix Meschberger wrote:
>>>>
>>>>> Hi Guillaume,
>>>>>
>>>>> The problem with this method is, that upto and including Java 1.4 it is
>>>>> marked final. It is not final anymore starting with Java 5.. So, the
>>>>> ContentClassLoader cannot overwrite.
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>> Am Mittwoch, den 16.01.2008, 17:09 +0100 schrieb Guillaume Sauthier:
>>>>>
>>>>>
>>>>>> Hi team
>>>>>>
>>>>>> I've just noticed that the ContentClassLoader do not override the
>>>>>> ClassLoader.getResources(String) method.
>>>>>> It only override the ClassLoader.getResource(String method). Notice
>>>>>> the final 's', one of theses methods is returning an Enumeration,
>>>>>> not the other one.
>>>>>> Moreover, the ISearchPolicy, that is used under the hood to find
>>>>>> resources have a findResources(String):Enumeration method :)
>>>>>>
>>>>>> I expect getResources() to list resources available to the bundle
>>>>>> (using OSGi constraints), not only "local" resources, which is the
>>>>>> current behavior.
>>>>>>
>>>>>> This is probably something forgotten :)
>>>>>> Can you enlight me ? Is this normal, or not ?
>>>>>>
>>>>>> Cheers
>>>>>> --Guillaume
>>>>>>
>>>>>>
>>>>>
>>>>>
>
>
Re: ClassLoader.getResources() not overrided
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Guillaume Sauthier wrote:
> 1. In R4SearchPolicyCore.findResources(String), when traversing the
> boot delegation packages, you placed the following comment:
> // If this is a java.* package, then always terminate the
> // search; otherwise, continue to look locally if not found.
>
> Do we have to respect this with the compound enumeration ?
> So far, I don't think so, nobody export java.* packages...
No one should be exporting java.*, so it should be okay to terminate at
that point.
> 2. At the end, you throw a ResourceNotFoundException, if the 'urls'
> variable is null.
> Is this still needed ?
It probably isn't strictly necessary, since null is a valid response.
-> richard
> BTW, I'm not at all sure that it was working correctly, because 'urls'
> may have been assigned to null by only the last IWire.getResources()
>
> Thanks
> --Guillaume
>>
>> -> richard
>>
>>>
>>> Thanks
>>> --Guillaume
>>>
>>
>
Re: ClassLoader.getResources() not overrided
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Richard S. Hall wrote:
> Guillaume Sauthier wrote:
>> After a bit of digging, instead of using a Factory, with a Java5
>> compiled ContentClassLoader, that add a lot of burden (I know, I've
>> tried that :) ), maybe it could be easier and more elegant to simply
>> have the ContentClassLoader.findResources(String) method implemented
>> using the ISearchPolicy to find the resources instead of just asking
>> the IContentLoader for local resources.
>>
>> BTW, this scenario will work if the R4SearchPolicyCore return a
>> compund enumeration of ALL the found resources.
>
> That might work, assuming we make the modification that Felix
> mentioned to aggregate all enumerations.
I'm working on that :)
I will submit a patch shortly.
BTW, I've got a couple of questions:
1. In R4SearchPolicyCore.findResources(String), when traversing the boot
delegation packages, you placed the following comment:
// If this is a java.* package, then always terminate the
// search; otherwise, continue to look locally if not found.
Do we have to respect this with the compound enumeration ?
So far, I don't think so, nobody export java.* packages...
2. At the end, you throw a ResourceNotFoundException, if the 'urls'
variable is null.
Is this still needed ?
BTW, I'm not at all sure that it was working correctly, because 'urls'
may have been assigned to null by only the last IWire.getResources()
Thanks
--Guillaume
>
> -> richard
>
>>
>> Thanks
>> --Guillaume
>>
>
Re: ClassLoader.getResources() not overrided
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Guillaume Sauthier wrote:
> After a bit of digging, instead of using a Factory, with a Java5
> compiled ContentClassLoader, that add a lot of burden (I know, I've
> tried that :) ), maybe it could be easier and more elegant to simply
> have the ContentClassLoader.findResources(String) method implemented
> using the ISearchPolicy to find the resources instead of just asking
> the IContentLoader for local resources.
>
> BTW, this scenario will work if the R4SearchPolicyCore return a
> compund enumeration of ALL the found resources.
That might work, assuming we make the modification that Felix mentioned
to aggregate all enumerations.
-> richard
>
> Thanks
> --Guillaume
>
Re: ClassLoader.getResources() not overrided
Posted by "Richard S. Hall" <he...@ungoverned.org>.
We should probably start a JIRA issue on this and if we get a patch, we
should probably run it by the Spring guys, since I know they are pretty
dependent on resource handling.
-> richard
Guillaume Sauthier wrote:
>
>>
>>> But reconsidering the initial problem mentioned by Guillaume: Only
>>> local
>>> resources returned. I am not sure why Guillaume mentions the
>>> ContentClassLoader, because the main accessor to resource
>>> Enumeration is
>>> the Bundle.getResources method.
>> In fact, I'm not using Bundle.getResources().
>> The problem occurs in a non-OSGi library that use directly
>> ClassLoader API.
>> So, as it's running in OSGi, it use a ContentClassLoader
>> implementation, but as getResources() is not overridden, we only use
>> classic ClassLoader search mechanism.
>> Last thing, I cannot change the lib to make it use OSGi ...
>>>
>
> After a bit of digging, instead of using a Factory, with a Java5
> compiled ContentClassLoader, that add a lot of burden (I know, I've
> tried that :) ), maybe it could be easier and more elegant to simply
> have the ContentClassLoader.findResources(String) method implemented
> using the ISearchPolicy to find the resources instead of just asking
> the IContentLoader for local resources.
>
> BTW, this scenario will work if the R4SearchPolicyCore return a
> compund enumeration of ALL the found resources.
>
> Thanks
> --Guillaume
>
Re: ClassLoader.getResources() not overrided
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
>
>> But reconsidering the initial problem mentioned by Guillaume: Only local
>> resources returned. I am not sure why Guillaume mentions the
>> ContentClassLoader, because the main accessor to resource Enumeration is
>> the Bundle.getResources method.
> In fact, I'm not using Bundle.getResources().
> The problem occurs in a non-OSGi library that use directly ClassLoader
> API.
> So, as it's running in OSGi, it use a ContentClassLoader
> implementation, but as getResources() is not overridden, we only use
> classic ClassLoader search mechanism.
> Last thing, I cannot change the lib to make it use OSGi ...
>>
After a bit of digging, instead of using a Factory, with a Java5
compiled ContentClassLoader, that add a lot of burden (I know, I've
tried that :) ), maybe it could be easier and more elegant to simply
have the ContentClassLoader.findResources(String) method implemented
using the ISearchPolicy to find the resources instead of just asking the
IContentLoader for local resources.
BTW, this scenario will work if the R4SearchPolicyCore return a compund
enumeration of ALL the found resources.
Thanks
--Guillaume
Re: ClassLoader.getResources() not overrided
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Felix Meschberger wrote:
> Hi,
>
> Am Mittwoch, den 16.01.2008, 13:37 -0500 schrieb Richard S. Hall:
>
>> Guillaume Sauthier wrote:
>>
>>> After a bit of thinking, I was wondering if a possible solution could
>>> be to have the ability to change the ContentClassLoader implementation.
>>>
>>> If something like this was present, I could have my own JDK5 only
>>> ContentClassLoader that extends ContentClassLoader and override the
>>> getResources method.
>>>
>>> What do you think ?
>>> May I start to create a patch for that ?
>>>
>> Certainly you can do that for your own project, but I am not sure how
>> easily it could be integrated into Felix...this is a case where we could
>> use #ifdef, I guess. :-)
>>
>
> With a bit of hackery: Have a factory method creating the
> ContentClassLoader instances, which decides at runtime, whether to
> create a pre-5 ContentClassLoader or a 5+ ContentClassLoader. But I will
> certainly advocate for such a solution here :-)
>
Yep, I was thinking about a solution like this :)
> But reconsidering the initial problem mentioned by Guillaume: Only local
> resources returned. I am not sure why Guillaume mentions the
> ContentClassLoader, because the main accessor to resource Enumeration is
> the Bundle.getResources method.
In fact, I'm not using Bundle.getResources().
The problem occurs in a non-OSGi library that use directly ClassLoader API.
So, as it's running in OSGi, it use a ContentClassLoader implementation,
but as getResources() is not overridden, we only use classic ClassLoader
search mechanism.
Last thing, I cannot change the lib to make it use OSGi ...
> So I dug into how Bundle.getResources is
> actually implemented down to the
> org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findResources() method. And then, something stroke me in this method:
>
> Instead of returning a combined enumeration of all resources found, the
> method aborts upon first success:
>
> * If an Enumeration is returned as per the boot delegation, this is
> returned ignoring the
> wires and bundle
> * If an Enumeration is returned in a wire, this is returned ignoring
> any other wires and
> the bundle
> * Then the bundle is searched and returned if found
> * Finally dynamic imports are returned tested
>
> I think, the method should rather gather all enumerations and returned a
> combined enumeration over all results ...
>
> WDYT ?
>
Yes, that would be my expected behavior.
Thanks
--Guillaume
> Regards
> Felix
>
>
>> -> richard
>>
>>
>>> Thanks
>>> --Guillaume
>>>
>>> Guillaume Sauthier wrote:
>>>
>>>> Thanks for your input Felix
>>>> That was not the answer I was expecting :)
>>>>
>>>> Anyway, do you have any idea about how to workaround this problem ?
>>>>
>>>> Thanks
>>>> --Guillaume
>>>>
>>>>
>>>> Felix Meschberger wrote:
>>>>
>>>>> Hi Guillaume,
>>>>>
>>>>> The problem with this method is, that upto and including Java 1.4 it is
>>>>> marked final. It is not final anymore starting with Java 5.. So, the
>>>>> ContentClassLoader cannot overwrite.
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>> Am Mittwoch, den 16.01.2008, 17:09 +0100 schrieb Guillaume Sauthier:
>>>>>
>>>>>
>>>>>> Hi team
>>>>>>
>>>>>> I've just noticed that the ContentClassLoader do not override the
>>>>>> ClassLoader.getResources(String) method.
>>>>>> It only override the ClassLoader.getResource(String method). Notice
>>>>>> the final 's', one of theses methods is returning an Enumeration,
>>>>>> not the other one.
>>>>>> Moreover, the ISearchPolicy, that is used under the hood to find
>>>>>> resources have a findResources(String):Enumeration method :)
>>>>>>
>>>>>> I expect getResources() to list resources available to the bundle
>>>>>> (using OSGi constraints), not only "local" resources, which is the
>>>>>> current behavior.
>>>>>>
>>>>>> This is probably something forgotten :)
>>>>>> Can you enlight me ? Is this normal, or not ?
>>>>>>
>>>>>> Cheers
>>>>>> --Guillaume
>>>>>>
>>>>>>
>>>>>
>>>>>
>
>
>
Re: ClassLoader.getResources() not overrided
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 16.01.2008, 13:37 -0500 schrieb Richard S. Hall:
> Guillaume Sauthier wrote:
> > After a bit of thinking, I was wondering if a possible solution could
> > be to have the ability to change the ContentClassLoader implementation.
> >
> > If something like this was present, I could have my own JDK5 only
> > ContentClassLoader that extends ContentClassLoader and override the
> > getResources method.
> >
> > What do you think ?
> > May I start to create a patch for that ?
>
> Certainly you can do that for your own project, but I am not sure how
> easily it could be integrated into Felix...this is a case where we could
> use #ifdef, I guess. :-)
With a bit of hackery: Have a factory method creating the
ContentClassLoader instances, which decides at runtime, whether to
create a pre-5 ContentClassLoader or a 5+ ContentClassLoader. But I will
certainly advocate for such a solution here :-)
But reconsidering the initial problem mentioned by Guillaume: Only local
resources returned. I am not sure why Guillaume mentions the
ContentClassLoader, because the main accessor to resource Enumeration is
the Bundle.getResources method. So I dug into how Bundle.getResources is
actually implemented down to the
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findResources() method. And then, something stroke me in this method:
Instead of returning a combined enumeration of all resources found, the
method aborts upon first success:
* If an Enumeration is returned as per the boot delegation, this is
returned ignoring the
wires and bundle
* If an Enumeration is returned in a wire, this is returned ignoring
any other wires and
the bundle
* Then the bundle is searched and returned if found
* Finally dynamic imports are returned tested
I think, the method should rather gather all enumerations and returned a
combined enumeration over all results ...
WDYT ?
Regards
Felix
>
> -> richard
>
> >
> > Thanks
> > --Guillaume
> >
> > Guillaume Sauthier wrote:
> >> Thanks for your input Felix
> >> That was not the answer I was expecting :)
> >>
> >> Anyway, do you have any idea about how to workaround this problem ?
> >>
> >> Thanks
> >> --Guillaume
> >>
> >>
> >> Felix Meschberger wrote:
> >>> Hi Guillaume,
> >>>
> >>> The problem with this method is, that upto and including Java 1.4 it is
> >>> marked final. It is not final anymore starting with Java 5.. So, the
> >>> ContentClassLoader cannot overwrite.
> >>>
> >>> Hope this helps.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>> Am Mittwoch, den 16.01.2008, 17:09 +0100 schrieb Guillaume Sauthier:
> >>>
> >>>> Hi team
> >>>>
> >>>> I've just noticed that the ContentClassLoader do not override the
> >>>> ClassLoader.getResources(String) method.
> >>>> It only override the ClassLoader.getResource(String method). Notice
> >>>> the final 's', one of theses methods is returning an Enumeration,
> >>>> not the other one.
> >>>> Moreover, the ISearchPolicy, that is used under the hood to find
> >>>> resources have a findResources(String):Enumeration method :)
> >>>>
> >>>> I expect getResources() to list resources available to the bundle
> >>>> (using OSGi constraints), not only "local" resources, which is the
> >>>> current behavior.
> >>>>
> >>>> This is probably something forgotten :)
> >>>> Can you enlight me ? Is this normal, or not ?
> >>>>
> >>>> Cheers
> >>>> --Guillaume
> >>>>
> >>>
> >>>
> >>>
> >>
> >
Re: ClassLoader.getResources() not overrided
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Guillaume Sauthier wrote:
> After a bit of thinking, I was wondering if a possible solution could
> be to have the ability to change the ContentClassLoader implementation.
>
> If something like this was present, I could have my own JDK5 only
> ContentClassLoader that extends ContentClassLoader and override the
> getResources method.
>
> What do you think ?
> May I start to create a patch for that ?
Certainly you can do that for your own project, but I am not sure how
easily it could be integrated into Felix...this is a case where we could
use #ifdef, I guess. :-)
-> richard
>
> Thanks
> --Guillaume
>
> Guillaume Sauthier wrote:
>> Thanks for your input Felix
>> That was not the answer I was expecting :)
>>
>> Anyway, do you have any idea about how to workaround this problem ?
>>
>> Thanks
>> --Guillaume
>>
>>
>> Felix Meschberger wrote:
>>> Hi Guillaume,
>>>
>>> The problem with this method is, that upto and including Java 1.4 it is
>>> marked final. It is not final anymore starting with Java 5.. So, the
>>> ContentClassLoader cannot overwrite.
>>>
>>> Hope this helps.
>>>
>>> Regards
>>> Felix
>>>
>>> Am Mittwoch, den 16.01.2008, 17:09 +0100 schrieb Guillaume Sauthier:
>>>
>>>> Hi team
>>>>
>>>> I've just noticed that the ContentClassLoader do not override the
>>>> ClassLoader.getResources(String) method.
>>>> It only override the ClassLoader.getResource(String method). Notice
>>>> the final 's', one of theses methods is returning an Enumeration,
>>>> not the other one.
>>>> Moreover, the ISearchPolicy, that is used under the hood to find
>>>> resources have a findResources(String):Enumeration method :)
>>>>
>>>> I expect getResources() to list resources available to the bundle
>>>> (using OSGi constraints), not only "local" resources, which is the
>>>> current behavior.
>>>>
>>>> This is probably something forgotten :)
>>>> Can you enlight me ? Is this normal, or not ?
>>>>
>>>> Cheers
>>>> --Guillaume
>>>>
>>>
>>>
>>>
>>
>
Re: ClassLoader.getResources() not overrided
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
After a bit of thinking, I was wondering if a possible solution could be
to have the ability to change the ContentClassLoader implementation.
If something like this was present, I could have my own JDK5 only
ContentClassLoader that extends ContentClassLoader and override the
getResources method.
What do you think ?
May I start to create a patch for that ?
Thanks
--Guillaume
Guillaume Sauthier wrote:
> Thanks for your input Felix
> That was not the answer I was expecting :)
>
> Anyway, do you have any idea about how to workaround this problem ?
>
> Thanks
> --Guillaume
>
>
> Felix Meschberger wrote:
>> Hi Guillaume,
>>
>> The problem with this method is, that upto and including Java 1.4 it is
>> marked final. It is not final anymore starting with Java 5.. So, the
>> ContentClassLoader cannot overwrite.
>>
>> Hope this helps.
>>
>> Regards
>> Felix
>>
>> Am Mittwoch, den 16.01.2008, 17:09 +0100 schrieb Guillaume Sauthier:
>>
>>> Hi team
>>>
>>> I've just noticed that the ContentClassLoader do not override the
>>> ClassLoader.getResources(String) method.
>>> It only override the ClassLoader.getResource(String method). Notice
>>> the final 's', one of theses methods is returning an Enumeration,
>>> not the other one.
>>> Moreover, the ISearchPolicy, that is used under the hood to find
>>> resources have a findResources(String):Enumeration method :)
>>>
>>> I expect getResources() to list resources available to the bundle
>>> (using OSGi constraints), not only "local" resources, which is the
>>> current behavior.
>>>
>>> This is probably something forgotten :)
>>> Can you enlight me ? Is this normal, or not ?
>>>
>>> Cheers
>>> --Guillaume
>>>
>>
>>
>>
>
Re: ClassLoader.getResources() not overrided
Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Thanks for your input Felix
That was not the answer I was expecting :)
Anyway, do you have any idea about how to workaround this problem ?
Thanks
--Guillaume
Felix Meschberger wrote:
> Hi Guillaume,
>
> The problem with this method is, that upto and including Java 1.4 it is
> marked final. It is not final anymore starting with Java 5.. So, the
> ContentClassLoader cannot overwrite.
>
> Hope this helps.
>
> Regards
> Felix
>
> Am Mittwoch, den 16.01.2008, 17:09 +0100 schrieb Guillaume Sauthier:
>
>> Hi team
>>
>> I've just noticed that the ContentClassLoader do not override the
>> ClassLoader.getResources(String) method.
>> It only override the ClassLoader.getResource(String method). Notice the
>> final 's', one of theses methods is returning an Enumeration, not the
>> other one.
>> Moreover, the ISearchPolicy, that is used under the hood to find
>> resources have a findResources(String):Enumeration method :)
>>
>> I expect getResources() to list resources available to the bundle (using
>> OSGi constraints), not only "local" resources, which is the current
>> behavior.
>>
>> This is probably something forgotten :)
>> Can you enlight me ? Is this normal, or not ?
>>
>> Cheers
>> --Guillaume
>>
>
>
>
Re: ClassLoader.getResources() not overrided
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Guillaume,
The problem with this method is, that upto and including Java 1.4 it is
marked final. It is not final anymore starting with Java 5.. So, the
ContentClassLoader cannot overwrite.
Hope this helps.
Regards
Felix
Am Mittwoch, den 16.01.2008, 17:09 +0100 schrieb Guillaume Sauthier:
> Hi team
>
> I've just noticed that the ContentClassLoader do not override the
> ClassLoader.getResources(String) method.
> It only override the ClassLoader.getResource(String method). Notice the
> final 's', one of theses methods is returning an Enumeration, not the
> other one.
> Moreover, the ISearchPolicy, that is used under the hood to find
> resources have a findResources(String):Enumeration method :)
>
> I expect getResources() to list resources available to the bundle (using
> OSGi constraints), not only "local" resources, which is the current
> behavior.
>
> This is probably something forgotten :)
> Can you enlight me ? Is this normal, or not ?
>
> Cheers
> --Guillaume