So, for example, lets saw that you might add the permission class, ClassLoaderDomainPermission with the object name being the domain. Anytime that a jar is loaded, if that URL/Codesource doesn’t have an associated instance of ClassLoaderDomainPermission(“domain”), a security exception is thrown. If security passes, then a recursive map of PreferredClassLoader instances is consulted/constructed using String.split(domain,”.”) elements. Finally a new PreferredClassLoader is created with the URL of the jar file and the last PreferredClassLoader found/constructed in that path as it’s parent. Now, you have the ability to create your hierarchy. Clearly, there are some resolution items to manage in terms of getting all of the jars being visible in all of the parent domains. But, that’s really not a huge deal since the existing annotation can provide multiple jar files that can be inspected and homed into their respective domains.
Gregg Wonderly On Mar 10, 2014, at 11:35 AM, Gregg Wonderly <gr...@wonderly.org> wrote: > 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 >> -- >> Michał Kłeczek >> XPro Sp. z o. o. >> ul. Borowskiego 2 >> 03-475 Warszawa >> Polska
