river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River-436 - need some explanation of preferred class provider
Date Mon, 10 Mar 2014 08:27:37 GMT
Gregg,

Sim's RiverClassLoading work in trunk is based on your work on River-336.

This could be backported to the 2.2 branch.

Hopefully qa-refactor will get some interested reviewers when it stabilises for merging with
trunk.

I'm bogged down with paid work presently, so haven't had much time to focus on qa-refactor's
remaining issues.  ServiceDiscoveryManager is still failing a couple of tests and there are
tests for Reggie that expect listeners to be notified in the same order that listeners register,
forcing me to make the notifier's executor single threaded to comply.  When the executor is
multi threaded, each listener is notified with events arriving in the correct order, but the
order between listeners is asynchronous, causing test failure.  Personally I think there's
something wrong with expecting listeners to be notified in order of registration, but users
will be able to configure their executors to be multi threaded if they wish.

Regards,

Peter.

----- Original message -----
> 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
> 
> On Mar 7, 2014, at 12:17 PM, Michał Kłeczek <michal.kleczek@xpro.biz>
> wrote:
> 
> > Greg, please look at my example in the first message of this thread.
> > And tell my how the client can decide what ClassLoader should load Util
> > interface assuming it does not have it in it's classpath.
> > 
> > Regards,
> > 7 mar 2014 18:51 "Gregg Wonderly" <gregg@wonderly.org> napisał(a):
> > 
> > > 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>
> > > 
> > > 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message