river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Change for PreferredClassLoader its way of determining the existence of PREFERRED.LIST ?
Date Wed, 10 Jan 2007 09:40:58 GMT
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?



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).

View raw message