Re: Another question about codebases and jar versions
Mark Brouwer <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
Logan, Patrick wrote: > If the URL *is* changed, e.g. has a new digest if it is httpmd, or if > the URL per se or the jar file name has the version explicitly in it, > then the class loader *will* download the new jar. No a new class loader will be created for that annotation, meaning that classes defined in that new loader are not equal to those in the class loader associated with the old URL. I hope this helps in redefining your questions. In general this is the behavior you want. There is however a use case where this is nasty. Assume I have a transaction server and clients that are in the middle of a two phase commit transaction. I find out about a bug in the transaction service. I'm going to bring the service down to fix it to bring it up at a later date. 1) the fix is at the backend, no mobile code involved. I bring the service up with the same codebase annotation, no problem the clients can continue to use the service with their smart proxy; 2) the fix is in the mobile code. I bring the service up with a new codebase annotation because I want to propagate the change in the network. Well the current client will have a problem, for they are still able to communicate with the backend (assuming persistent connections), however marshalled objects arriving at their proxy will be created in a new class loader resulting in type conflict. 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. This was a very quick scribbling as I'm on my way out, so sorry if things are unclear in the above. -- 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]