On 8/28/2011 3:18 AM, Peter Firmstone wrote:
Over time I've given this serious contemplation.
Remember some time ago we discussed service api and dependencies? Dennis has a
really well presented page that highlites the dependency relationship between
service compontents:
http://www.rio-project.org/tutorial/service/service-intro.html
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.
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.
> 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. We
need to have delayed unmarshalling to really solve that problem I feel.
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
Any ideas?
Regards,
Peter.
