commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject Re: [discovery] Use of ClassLoader in ClassFinder
Date Fri, 28 Jun 2002 17:46:40 GMT
More thoughts.  First, regarding order of loaders, I propose the following
based on feedback:

thread context loader
caller's class loader
SPI's class loader
ServiceFinder's class loader
System class loader

the only diff from Costins sequence is the addition of the 'ServiceFinder's
class loader.  Now, to eliminate redundancy, I'm going to walk the parents
of each classloader and if I see that one of the above is also an ancestor
of another lower in the above list, then I'm going to remove the duplicate
loader from the list.


>> In some cases we may want to force the discovery of a certain
>> implementation set by container, for example if tomcat runs the apps in
>> a sandbox and wants to force a certain trusted logger, even if the app
>> includes an implementation ( in this case the impl. in WEB-INF/lib
>> may not have the permissions - it's safer to grand it to a trusted
>> logger under control ).
>>
>

I don't agree with this statement.

I don't have a long background working with J2EE environments, Tomcat,
etc... So there may be some history that backs that up.. in which case I
welcome the education.

I'm of the opinion that container should either support what is deployed,
or error out.  In this case, if the permissions are not granted then the
deployer is responsible for resolving the conflict by either removing the
offending piece of code, or granting the permissions.  If, on the other
hand, WE are introducing a conflict that is either contrary to standard
function, or not resolvable, then help me understand that...

>To meet this need, we might want to make the discovery order configurable,
>but then we're going to have the fun chicken-and-egg problem of how the
>discovery algorithm discovers its own configuration settings ...

I'm strongly against configuration for this... simple simple simple
It may be that my ideals will have to break down in the face of reality,
but until then...

>> Costin
>>
>>

>Craig

Richard


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.
org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
org>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message