Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4E5B2DC9.10508@zeus.net.au>
Date: Mon, 29 Aug 2011 16:12:25 +1000
From: Peter Firmstone <peter.firmstone@zeus.net.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
 rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Usability - "The Platform"
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> >  I think a number of the usability issues relate to our not having defined the
> >  platform and recognising how this relates to deployment.
>
> Practically, there is, in fact, a platform.  It is the classes in
> jsk-platform.jar.  Now, is that specified formally, in a way that people can
> also draw conclusions, easily about what they can and can't do?  I'd say no.  I
> think that there are things missing from the platform, that should be in it,
> now.  ServiceUI, for example, and every single Entry implementation that is in
> the River source, should be in the platform, instead of in jsk-lib.jar etc.

Yes, I agree, the ConstrainableLookupLocator is missing too, reducing 
the number of jar files would reduce confusion I think too.
> >  Firstly we need to address codebase annotation loss, preferred classes is a
> >  partial solution, however I think we can completely solve this problem by only
> >  allowing the platform (which we need to clarify) and the service api to inhabit
> >  the classpath.
> >
> >  All nodes would then have an almost identical classpath, although some nodes may
> >  contain different service api. (The proxy can download additional service api
> >  missing on the client, it depends on, since the client won't need to access
> >  these classes directly anyway, they can be loaded by the proxy ClassLoader).
>   >
> >  Applications and server side service implementations could have their own
> >  classpath, not visible to proxy's, forcing cooperating parties to interract
> >  using only the platform and service api. Should we modifiy and standardise
> >  ServiceLoader for this purpose?
>
> There are many classes, that our platform classes, which are defined as
> implementation of platform interfaces.  Those need to be able to be overridden
> as part of a platform upgrade, bug fix etc.

Ok, so you would use preferred classes in that case, but we still need 
to avoid codebase annotation loss.

The problem with package versioning, is classes don't all come from the 
same jar file, so classes in one package may originate from different 
versions.  We can only restrict package scope by signing the jar files.  
We could sign each releases jar files using a unique certificate for 
each release.

We'd need our own classloader to load the platform in, instead of the 
application ClassLoader, then the proxy, application and service 
ClassLoaders would need to be child loaders.

Then the proxy could load the preferred classes, if the platform was a 
different version.

Also when objects have been resolved by the platform, we loose the 
original codebase url annotation, so we'd need to be able lookup the 
codebase by it's checksum, similar to Mike Warres' Codebase service, 
because we've lost the original location of the codebase.

Whether the codebase service uses maven or some other mechanism, would 
depend on the codebase service implementation, we'd have to abstract it 
so we don't end up depending on Maven.

>   >  Then we stop using the preferred classes mechanism by default.
>
> We need to be able to assert, "YOU MUST USE MY VERSION OF THIS CLASS" in some
> way.  The PreferredClassProvider/PreferredClassLoader is one way that this is
> possible.  If we don't provide that functionality, I think we will be really
> making things difficult.
>
> >  This will allow us to prevent codebase annotation loss.
>
> Codebase annotation loss happens if a remote reference is passed around.
Yes, buy only if class loading resolves it in the application 
ClassLoader.  So we might need a boot jar that loads the platform in a 
child classloader, so we gain full control over annotation loss.

>    We
> need to have delayed unmarshalling to really solve that problem I feel.

You blazed a trail with delayed unmarshalling Gregg, so we're 
implementing this years later...

After discussing it with Dan, I'm happy with the StreamServiceRegistrar 
as an interface that extends ServiceRegistrar (maintaining backward 
compatibility) for delayed unmarshalling, the intent is to delay 
unmarshalling of the service proxy only, while allowing clients to 
perform some local entry based filtering first.  The stream part is to 
allow the client to only process a limited number of proxy's one at a 
time, once it decides it needs to unmarshall.  Clients would have to use 
instanceof to determine if they've got a StreamServiceRegistrar.

Reggie still needs to be modified to support it.

> >  But to do so we need to define the platform, so all nodes are consistent.
>
> I'm not convinced that this is "necessary".  There may be installations where it
> is obviously advantageous, if not necessary.  But, to say that 100% of the time,
> it is "required", or "best design", I'm not sure.
>
> Gregg

Cheers,

Peter.