> 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.
