Re: Another question about codebases and jar versions

Logan, Patrick wrote:

>> In this case I would want to be able to sent an old codebase
>> annotation to the client, which might result in them not getting the
>> bug-fix but if the bug is not hindering them at least it would help
>> them to continue.
>
> Is there a typical way to do this?

Not that I'm aware of Patrick. I've been playing with one idea as it is
possible to have greater control over the codebase annotations
associated with classes by implementing a more advanced
RMIClassLoaderSpi than what is currently available as part of
net.jini.loader.pref.PreferredClassProvider.

In short the idea is that you have some context information you can
utilize (in combination with the Class object) to decide what the
codebase annotation must be.

Assuming this context information would identify the client proxy making
the request you can stick the proper annotation to objects marshalled
(the return value) for a remote method call.

The problem however is that there is currently no way to attach context
information to a remote method invocation. With the customizable Jini
ERI protocol stack you could write this as part of a new invocation
layer, but I think if this needs to work in an environment where you
have to establish trust it has to become a default feature [1].

This mechanism would have another advantage assuming that location (IP
address or something else) could also be part of the context [2] you can
also serve different codebase based on that information. There are
situations where this might be beneficial.

I didn't expect to bring these thoughts to the surface at this time as I
haven't done experimental work on this subject (so oversight is likely),
although if there are people out there who have dismissed similar ideas,
have other ideas or have an opinion please let it know as it might save
me some time in the future if this turns out to be an idea not worth
pursuing or when there are other or better ways to tackle some of the
problems.


[1] there is a bootstrap mechanism that allows you to establish trust
for custom parts of the protocol stack, but when the trusted parts
required for boostrapping don't provide the proper context information
trust verifiers will be sent that likely fail due to the (historical)
parts to be verified hanging out in a different class loader than the
verifier just received.

[2] I realize that there is net.jini.io.context.ClientHost you can
obtain from the ServerContext but that one doesn't necessarily
correlates with the location from where the invocation takes place, e.g.
in case when you proxy your remote method invocations.

> Or is there a conventional way to get a client with old objects to
> fail and take some app-specific upgrade measures?

Not that I'm aware of. But now that you ask for it, the same context
information could be utilized to decide at the server side that it has
no use to perform any remote method invocation from that proxy in the
future and to throw an exception that would mark that proxy/service useless.

Note however that all this requires a lot of sophistication at the
backend to keep track of whether version upgrades are compatible and
some good thinking of the developer, but there are cases where this
might be worth it. In case of the typical grid application that runs for
a few hours and is brought down it is probably of no use, but an
environment where you have services running for months and for which you
sometimes have to upgrade services (in a 'compatible' way) it might be
beneficial.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]