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 Thu, 13 Mar 2014 12:40:52 GMT
Gregg,

I like your domain explanation.

Each domain belongs to a service and services may use different codebase annotation / provisioning
mechanisms.  While the client owns the local domain, this allows some control by the service
over it's own domain concerns.

Although, I'd be tempted to make the parent, or global domain the api domain and place the
application in a child domain, to reduce visibility of application classes to the service
implementations / domains.

Cheers,

Peter.



----- Original message -----
> My point is that you have to formalize it in a way that you can then
> recognize.   For both OSGi and Netbeans and many platforms, the knowledge
> is hardcode into a relationship between the platforms class loading
> mechanism, and the jar content.
> 
> I don’t want to always use OSGi.   I don’t want to always use Netbeans. 
> I want to use the appropriate mechanism for where the ‘client’ lives,
> not for ‘how the service is constructed’.     This is why
> PreferredClassLoader has been working so well.   It’s something that the
> ‘client’ dictates and the ‘service jar’ has to standardize on.   So, now
> that you have something ‘new’ that you want to implement, in terms of a
> client standard (a common client jar that is not in the clients class
> path), you are going to have to provide a way for that to work.
> 
> One way that comes to mind, is to take River-336 concepts and go just a
> bit further by adding the notion of a “domain” for class loader
> hierarchy.   Imagine that every jar could have an additional meta-inf
> property called “Domain”, which would be prepended by the URL’s path,
> without the jar file name, that it was loaded from.   This would then
> create a class loading relationship in a graph described by the ‘.’
> separated components.
> 
> http://server1/jars/Util.jar => Domain=app
> http://server1/jars/service1.jar => Domain=app.service1
> http://server1/jars/service2.jar => Domain=app.service2
> http://server1/jars/service3.jar => Domain=app.service3
> http://server1/jars/service4.jar => Domain=app.service4
> 
> would produce a graph of class loaders with ‘app’ at the parent so that
> everything in Util.jar or any other associated libraries would be there,
> and the services would have a parent reference to them.
> 
> You could add a security permission associated with Domain
> creation/access so that other services that you had not authorized at
> server1, could not glue themselves into the class loader hierarchy.
> 
> This kind of mechanism lets the app developer designate exactly what
> they want to have happen and control it from the service where it should
> be controlled.
> 
> Gregg
> 
> On Mar 10, 2014, at 1:08 AM, Michał Kłeczek <michal.kleczek@xpro.biz>
> wrote:
> 
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message