river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: River-436 - need some explanation of preferred class provider
Date Sun, 09 Mar 2014 21:54:57 GMT
The whole point of my example is that the client has no knowledge of Util 
interface - it is simply not interested in it.

The problem is not that the client cannot plug-in RMIClassProvider 
dynamically. It is just that with current format of codebase annotation the 
client cannot do anything. It simply does not have enough data to decide what 
to do - just two lists of URLs without any dependency information encoded.

Regards,

On Sunday, March 09, 2014 02:33:03 PM Gregg Wonderly wrote:
> All you have to provide in the client is a class loading implementation that
> knows about Util and pins it into a parent class loader from the class
> loaders that proxies load.  I netbeans, this happens because meta data
> declares that such a relationship exists.  In OSGi, this happens because
> meta data declares that such a relationship exists.  All you have to do, is
> create meta data that specifies that such a relationship exists, and then
> plug in a River-336 compatible class loading implementation in your client.
> 
> My point is no that River-336 provides the answer, but rather it provides a
> mechanism that an application can use.  Not every application has such a
> need, and not every known implementation uses the same model.  Thus, there
> isn’t a single answer that can exist ahead of time.
> 
> If you want to use OSGi, plug it in.  If you want to use Netbeans, plug it
> in.   If you want to use both at the same time, work it out and plug it in.
>  There is room for a single standard to eventually win.  But, there isn’t a
> single standard that is standing alone right now that I see.
> 
> Gregg Wonderly

-- 
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska
Mime
View raw message