I think that while it is an approach that could work it has some problems: 1. It requires processing of jar files. Actually the same problem is with PREFERRED.LIST - there is no way one can use third party off-the-shelf jars (eg. from Maven Central). It is doable of course but it makes thing _tedious_
2. Although it does not change the format of annotations it _does_ introduce yet-another-standard that everybody has to understand. While it is not bad per-se - it is _fixed_ - no way you can change it without changing all the services/clients (BTW - I do not really like the distinction between services and clients - the only real difference between them is that services announce themselves in lookup services. From the security and code downloading perspective there is no difference) It would be really good if you take into account River-436. While it is - again - a new standard, it strives to standardize in such a way that no more changes in the standard are going to be needed :) It simply makes creating a proper ClassLoader hierarchy/graph/whatever the responsibility of the _service_ (the entity that provides code). From the downloading entity it is irrelevant _how_ classes are created as long as it can use it (securely of course). There is one default implementation of a ClassProvider in my patch that shows: a) how to provide other custom implementations b) that the approach makes it possible (and in practice quite trivial) to exchange hierarchies of ClassLoaders and (partially due to limitations in hierarchical class loading) solve class loading issues presented in this thread. Regards, On Thursday 13 of March 2014 22:40:52 Peter wrote: > 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.klec...@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
