Hi Mark, Not sure I understand exactly where you are going so how about one of my patent-pending dumb questions:
How is this different from me ensuring that each service I deploy has, in the same JVM an http server to serve the .jars on it's codebase? Essentially, that would mean that if I could reach the service, I could get it's .jars. If I can't do that, I have to go get some other service. Does it just come down to .jar caching in clients/other services for purposes of speed etc? Interesting, Dan. Mark Brouwer wrote: > One of the next features of Seven I'm working on is the ability of a > service to keep access to all download JAR files as seen be a service > during its life-time, including restarts of the service and/or container. > > This should lead to: > > - increased reliability of codebase annotations, especially handy when > persisting marshalled objects; > - faster startup times (also see Gregg's requirements for vhttp); > - less bandwidth usage; > - statistics about the usage of downloadable code by a service; > - if you ever want to move a service from one container to another > you can move its downloadable code dependencies with it. > > This works because Seven uses specialized jar protocol handlers that are > used for all the class loaders created by PreferredClassProvider, it > also works for each protocol used in codebase annotations. > > So far this work nice, there is however one spoiler and that is the > current implementation of net.jini.loader.pref.PreferredClassLoader as > this one performs always a direct check against the first URL to see > whether the there is a PREFERRED.LIST for reasons as stated by inline > comments: > > * First determine if the JAR file exists by attempting to > * access it directly, without using a "jar:" URL, because > * the "jar:" URL handler can mask the distinction between > * definite lack of existence and less definitive errors. > * Unfortunately, this direct access circumvents the JAR > * file caching done by the "jar:" handler, so it ends up > * causing a duplicate request of the JAR file on first > * use. (For HTTP-protocol URLs, the initial request will > * use HEAD instead of GET.) > > First can somebody shed me light how a typical jar: handler can mask the > distinction between definite lack of existence and less definite errors. > > I'm not that concerned about the performance implications though the > current implementation defeats "increased reliability of codebase > annotations", I don't have a solution in mind yet, but I would like to > see a way to be able to get what I want without completely overriding > the protected method isPreferredResource(String, boolean).
