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 Mon, 10 Mar 2014 06:08:53 GMT
Actually it is even worse. Since RMIClassProvider API is stateless the client 
has only one list of URLs at a time...

Regards,

On Sunday, March 09, 2014 10:54:57 PM Michał Kłeczek wrote:
> 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
-- 
Michał Kłeczek
XPro Sp. z o. o.
ul. Borowskiego 2
03-475 Warszawa
Polska

Mime
View raw message