Re: Another question about codebases and jar versions

Mark Brouwer wrote:
> 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?
>

Hmmm, what would be a conventional way?

I have been thinking about this a while and think I've got a relatively
simple mechanism that services and client could use to achieve this with
minimal disruption to client and/or service and a relatively simple
programming model.

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

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