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 <sanjeeb.sa...@oracle.com>
wrote:
Why does ExtensionManager.**getResourceByDelegation() does not
search the
resource using the same algorithm as getClassByDelegation()?
Thanks,
Sahoo