river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: River-436 - need some explanation of preferred class provider
Date Fri, 07 Mar 2014 17:50:38 GMT
Okay, I don’t have to reply to all of the exchanges I missed, but I really want to make it
clear, that my class loading changes in River-336, do in fact fix ALL CLASSLOADING ISSUES!
 The reason I “scream” that out, is because it encapsulates every single way that class
loading occurs.  If you don’t have a preferred list in your jar, then preferred class loader
is going to always “ask” the parent to load the class, and the call into the River-336
provided code can delegate loading in whatever mechanism is appropriate for the “platform”
that the client wants to use.

This makes it possible to get the class form wherever is needed, and puts the client in complete
control of how class loader resolution occurs, as well as how class objects are loaded into
class loaders as “owners” of the classes.

Just because the methods have names indicating “parent” or other hierarchal relationships
doesn’t mean that the actions taken there have to create any sort of hierarchy.

Gregg Wonderly

On Mar 7, 2014, at 10:32 AM, Michał Kłeczek <michal.kleczek@xpro.biz> wrote:

> Sure there is a need for code downloading for JERI proxies. You seem to assume 
> no custom endpoint implementations.
> There is really no difference between dynamic proxy and "normal" object.
> Regards,
> On Friday, March 07, 2014 09:32:04 AM Greg Trasuk wrote:
>> Now, dynamic proxies are a different story, and JERI already uses the
>> dynamic proxy mechanism.  There’s no need, for example to download an
>> implementation class for an object that is directly exported - you only
>> really need the service interface to be available locally.
>> Cheers,
>> Greg Trasuk
> -- 
> Michał Kłeczek
> XPro Sp. z o. o.
> ul. Borowskiego 2
> 03-475 Warszawa
> Polska<Michał Kłeczek (XPro).vcf>

View raw message