river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Jones <peter.jo...@sun.com>
Subject Re: PreferredClassProvider performs 'unlucky' caching?
Date Mon, 13 Aug 2007 22:04:32 GMT
On Wed, Aug 08, 2007 at 04:57:10PM +0200, Mark Brouwer wrote:

> I ask to check whether it was deliberate to put an entry in the map
> for the class loader found through findOriginLoader or that it was
> an optimization to prevent from calling findOriginLoader each time.

I'm pretty sure that it was a deliberate optimization (it exists in
the earliest version of PreferredClassProvider.java that I can find,
from 2000).  I think that findOriginLoader was believed or at least
suspected to be a potentially expensive operation.  This caching (of
findOriginLoader results) is not required by the spec, and the current
spec doesn't accommodate possibilities opened by RIVER-147, so I think
that this caching can reasonably be considered a detail of the present

> If my understanding is correct I would like to create an issue and
> modify the code to prevent from caching loaders found through
> findOriginLoader.  Please your opinion.

It would seem useful to understand the performance impact.  But if the
RIVER-147 hook is allowed to return different results from different
invocations with the same arguments (as a function of time or some
other context), then it would seem that something must be done about
this caching.

> [1] Seven upcoming allows services to share a common class loader
> while each having their own unique codebase annotation and security
> policy.  The codebase annotation and security policy are chosen
> based on the SecurityContext the services operates under. This
> allows intra service communication (through static constructs) while
> with respect to the security policy effective and mobile code they
> each act as an isolated entity.

Talk of simultaneously having "isolated security policy" and
"intra-service communication through static constructs" makes me
nervous.  Do you mean that the code of one service can invoke static
methods of another service's classes?  Wouldn't that allow the second
service's code to execute with the first service's security policy?
Or do you mean something different than I'm assuming?

-- Peter

View raw message