You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Sahoo <sa...@oracle.com> on 2013/02/07 10:34:07 UTC
Difference between system.bundle getResource and loadClass
Why does ExtensionManager.getResourceByDelegation() does not search the
resource using the same algorithm as getClassByDelegation()?
Thanks,
Sahoo
Re: Difference between system.bundle getResource and loadClass
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/7/13 18:57 , Sahoo wrote:
> On Friday 08 February 2013 02:09 AM, Richard S. Hall wrote:
>>
>> On 2/7/13 09:20 , Richard S. Hall wrote:
>>> I think the issue is simply that the system bundle's class loader is
>>> always the class loader that loaded it (unlike bundles which can be
>>> configured to have a different parent) and it can never delegate to
>>> anyone else since it never imports, so all requests to it are
>>> serviced by its loading class loader.
>>
>> Responding to myself, I guess I thought you were asking why it is
>> different that normal bundles, but I see you were just talking about
>> the extension manager methods themselves...
>>
>> The only reason I can think of is that resources aren't always in
>> packages, so were were being a little more lenient with those, but
>> otherwise you could argue it should be done the same way.
> Right. I think we should change getResource method, since Felix
> implementation tries to stick to the spec as much as possible in
> default mode.
I'm not sure if the behavior of system bundle is clearly spec'ed in
these cases. For example, I'm not sure Equinox even does the filtering
we do on class delegation.
-> richard
>
> Sahoo
Re: Difference between system.bundle getResource and loadClass
Posted by Sahoo <sa...@oracle.com>.
On Friday 08 February 2013 02:09 AM, Richard S. Hall wrote:
>
> On 2/7/13 09:20 , Richard S. Hall wrote:
>> I think the issue is simply that the system bundle's class loader is
>> always the class loader that loaded it (unlike bundles which can be
>> configured to have a different parent) and it can never delegate to
>> anyone else since it never imports, so all requests to it are
>> serviced by its loading class loader.
>
> Responding to myself, I guess I thought you were asking why it is
> different that normal bundles, but I see you were just talking about
> the extension manager methods themselves...
>
> The only reason I can think of is that resources aren't always in
> packages, so were were being a little more lenient with those, but
> otherwise you could argue it should be done the same way.
Right. I think we should change getResource method, since Felix
implementation tries to stick to the spec as much as possible in default
mode.
Sahoo
Re: Difference between system.bundle getResource and loadClass
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/7/13 09:20 , Richard S. Hall wrote:
> I think the issue is simply that the system bundle's class loader is
> always the class loader that loaded it (unlike bundles which can be
> configured to have a different parent) and it can never delegate to
> anyone else since it never imports, so all requests to it are serviced
> by its loading class loader.
Responding to myself, I guess I thought you were asking why it is
different that normal bundles, but I see you were just talking about the
extension manager methods themselves...
The only reason I can think of is that resources aren't always in
packages, so were were being a little more lenient with those, but
otherwise you could argue it should be done the same way.
-> richard
>
> -> richard
>
> On 2/7/13 05:56 , Sahoo wrote:
>> No, I don't have a use case. Since we set framework loader as bundle
>> parent loader, I can't see how it can really affect us. I
>> accidentally bumped into that code and it didn't look correct to me,
>> so asked. It can actually affect some.
>>
>> Thanks,
>> Sahoo
>> On Thursday 07 February 2013 03:19 PM, Karl Pauls wrote:
>>> I don't think there is a real reason.
>>>
>>> IIRC, we just wanted the system bundle wiring not to expose classes
>>> that
>>> are not exported and hence, changed the getClassByDelegation. I
>>> guess you
>>> could argue we should do the same for getResourceByDelegation...
>>>
>>> Do you have a use case where that is causing problems?
>>>
>>> regards,
>>>
>>> Karl
>>>
>>>
>>> On Thu, Feb 7, 2013 at 10:34 AM, Sahoo <sa...@oracle.com>
>>> wrote:
>>>
>>>> Why does ExtensionManager.**getResourceByDelegation() does not
>>>> search the
>>>> resource using the same algorithm as getClassByDelegation()?
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>
>>>
>>
>
Re: Difference between system.bundle getResource and loadClass
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think the issue is simply that the system bundle's class loader is
always the class loader that loaded it (unlike bundles which can be
configured to have a different parent) and it can never delegate to
anyone else since it never imports, so all requests to it are serviced
by its loading class loader.
-> richard
On 2/7/13 05:56 , Sahoo wrote:
> No, I don't have a use case. Since we set framework loader as bundle
> parent loader, I can't see how it can really affect us. I accidentally
> bumped into that code and it didn't look correct to me, so asked. It
> can actually affect some.
>
> Thanks,
> Sahoo
> On Thursday 07 February 2013 03:19 PM, Karl Pauls wrote:
>> I don't think there is a real reason.
>>
>> IIRC, we just wanted the system bundle wiring not to expose classes that
>> are not exported and hence, changed the getClassByDelegation. I guess
>> you
>> could argue we should do the same for getResourceByDelegation...
>>
>> Do you have a use case where that is causing problems?
>>
>> regards,
>>
>> Karl
>>
>>
>> On Thu, Feb 7, 2013 at 10:34 AM, Sahoo <sa...@oracle.com> wrote:
>>
>>> Why does ExtensionManager.**getResourceByDelegation() does not
>>> search the
>>> resource using the same algorithm as getClassByDelegation()?
>>>
>>> Thanks,
>>> Sahoo
>>>
>>
>>
>
Re: Difference between system.bundle getResource and loadClass
Posted by Sahoo <sa...@oracle.com>.
No, I don't have a use case. Since we set framework loader as bundle
parent loader, I can't see how it can really affect us. I accidentally
bumped into that code and it didn't look correct to me, so asked. It can
actually affect some.
Thanks,
Sahoo
On Thursday 07 February 2013 03:19 PM, Karl Pauls wrote:
> I don't think there is a real reason.
>
> IIRC, we just wanted the system bundle wiring not to expose classes that
> are not exported and hence, changed the getClassByDelegation. I guess you
> could argue we should do the same for getResourceByDelegation...
>
> Do you have a use case where that is causing problems?
>
> regards,
>
> Karl
>
>
> On Thu, Feb 7, 2013 at 10:34 AM, Sahoo <sa...@oracle.com> wrote:
>
>> Why does ExtensionManager.**getResourceByDelegation() does not search the
>> resource using the same algorithm as getClassByDelegation()?
>>
>> Thanks,
>> Sahoo
>>
>
>
Re: Difference between system.bundle getResource and loadClass
Posted by Karl Pauls <ka...@gmail.com>.
I don't think there is a real reason.
IIRC, we just wanted the system bundle wiring not to expose classes that
are not exported and hence, changed the getClassByDelegation. I guess you
could argue we should do the same for getResourceByDelegation...
Do you have a use case where that is causing problems?
regards,
Karl
On Thu, Feb 7, 2013 at 10:34 AM, Sahoo <sa...@oracle.com> wrote:
> Why does ExtensionManager.**getResourceByDelegation() does not search the
> resource using the same algorithm as getClassByDelegation()?
>
> Thanks,
> Sahoo
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls