Re: Article on removing codebase property
Calum Shaw-Mackay <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
Perhaps we might do well putting some of this information on the serverside thread, and see what the author thinks about PreferredClassLoader over his approach? --Calum On 20/02/07, Gregg Wonderly <[email protected]> wrote: > > > Calum Shaw-Mackay wrote: > > Any thoughts? > > > > http://www.theserverside.com/news/thread.tss?thread_id=44288 > > The main issue, is making the client utilize an unchanging codebase so that you > can update the content without having to worry about changing the codebase spec > on the server deployment and/or codesource security specs used by the client. > > I utilize the class dependency tools to build a composite jar for my services > -dl.jars. I do include jsk-dl.jar explicitly in the codebase. And, there are a > couple of larger jars that I sometimes include in Class-Path: meta data too. > > There are multiple ways that exist to day to minimize changes in your > build/deployment as your service evolves. > > As Dan said, we've essentially "solved" that problem. What we need to really > work on is some better handling of failover and such. I have an HTTP server in > the startnow project which I haven't deployed, but which I started work on, and > have done some testing with. It is, in fact a service. It provides facilities > for a service to ask "who can serve jar XYZ.jar" when that service is building > its codebase. > > It might be more interesting for the client to ask this question so that > failover is very close to the event that needs to mediate the failure. But, I > thought it would be less pain and security configuration for the client if the > server made that decision as the codebase annotation is queried for at > marshalling time. > > Gregg Wonderly > -------------------------------------------------------------------------- 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]