river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: River-436 - need some explanation of preferred class provider
Date Sat, 15 Mar 2014 05:14:36 GMT
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 <gregg@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.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

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