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.
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?
Then we stop using the preferred classes mechanism by default.
This will allow us to prevent codebase annotation loss.
But to do so we need to define the platform, so all nodes are consistent.
Any ideas?
Regards,
Peter.
