Return-Path: Delivered-To: apmail-incubator-river-dev-archive@locus.apache.org Received: (qmail 61975 invoked from network); 24 Jan 2007 15:29:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Jan 2007 15:29:11 -0000 Received: (qmail 85331 invoked by uid 500); 24 Jan 2007 15:29:17 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 85317 invoked by uid 500); 24 Jan 2007 15:29:17 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 85308 invoked by uid 99); 24 Jan 2007 15:29:16 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [194.109.24.21] (HELO smtp-vbr1.xs4all.nl) (194.109.24.21) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Jan 2007 07:29:13 -0800 Received: from [192.168.1.51] (marbro.xs4all.nl [80.126.48.138]) (authenticated bits=0) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0OFSCvx051744 for ; Wed, 24 Jan 2007 16:28:13 +0100 (CET) (envelope-from mark.brouwer@cheiron.org) Message-ID: <45B77B0C.70305@cheiron.org> Date: Wed, 24 Jan 2007 16:28:12 +0100 From: Mark Brouwer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: river-dev@incubator.apache.org Subject: Re: Change for PreferredClassLoader its way of determining the existence of PREFERRED.LIST ? References: <45A3F189.8040809@cheiron.org> <45A67ED8.80907@Sun.COM> <45A6B402.20406@cheiron.org> <20070116212605.GP20922@east> <45ADE8D2.5030904@cheiron.org> <20070122184822.GC25418@east> <45B5EE76.4000500@cheiron.org> <45B62537.4040806@wonderly.org> <45B70E78.3070705@cheiron.org> <45B76FAB.1010108@wonderly.org> In-Reply-To: <45B76FAB.1010108@wonderly.org> Content-Type: multipart/mixed; boundary="------------080409020708010801070500" X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Checked: Checked by ClamAV on apache.org --------------080409020708010801070500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gregg Wonderly wrote: > Mark Brouwer wrote: >> Gregg Wonderly wrote: >>> I think that the behavior of fallback URLs is useful. Given the >>> framework that >>> exists, I think that the current implementation is applicable. But, >>> I also >> >> I've a bit of a problem positioning your language Gregg due to the words >> fallback and framework, but are you suggesting the new behavior should >> be conditionally. Note that as far as I can tell the only >> de-optimization is the one Peter will be remembered for the rest of his >> life. > > Let me try with different words... Ok I understand where you want to go to, however there was a thread during the Davis project which I'm unfortunately can't refer to as the archives have been closed, where I also referred to the current semantics for having the requirement of PREFERRED.LIST in the first JAR file. I attached my post and the responses of Peter and Laird Dornin for completeness. There is an issue in the Sun bug database http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4302427 that suggest that the fallback behavior you are referring to in itself is a bug. Based on the current semantics of PreferredClassLoader the proposed change doesn't alter its behavior. > If there are multiple URLs in the codebase, and two or more actually > points at the same content, then one of those URLs can be considered > "fallback" URLs. I.e. if one URL is not accessible, the client will > hopefully be able to load code from another. Thus, the failure handling > associated with "JAR not accessible" as opposed to "PREFERRED.LIST" not > present is important. Also, the location that the PREFERRED.LIST comes > from is important. > You are familiar with XML based configuration. Imagine that you could Is that a complement Gregg ;-) I think we should start a separate thread on improvements of codebase annotation for it seems you just want to have a complete new protocol handler Gregg that solves many issues around mobile code, but I think I leave it up to others who have done their fair share of research/thinking to comment on this first. -- Mark --------------080409020708010801070500 Content-Type: message/rfc822; name="Attached Message.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message.eml" Return-path: Received: from pavo.virgil.nl (pavo.virgil.nl [194.134.241.138]) by virgo.virgil.nl (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H4U00KWENK03T@virgo.virgil.nl> for marbro@ims-ms-daemon (ORCPT mark.brouwer@virgil.nl); Thu, 31 Oct 2002 15:14:24 +0100 (CET) Received: from jini.org (h36.sfo.collab.net [64.125.133.46]) by pavo.virgil.nl (8.10.2+Sun/8.10.2) with SMTP id g9VEENV00943 for ; Thu, 31 Oct 2002 15:14:23 +0100 (CET) Received: (qmail 4374 invoked by uid 5302); Thu, 31 Oct 2002 14:14:17 +0000 Received: (qmail 4365 invoked from network); Thu, 31 Oct 2002 14:14:16 +0000 Date: Thu, 31 Oct 2002 15:14:16 +0100 From: Mark Brouwer Subject: Codebase redundancy and PREFERRED.LIST To: Davis Reply-to: discuss@davis.jini.org Message-id: <3DC13AB8.30478F9E@virgil.nl> Organization: Virgil B.V. MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Precedence: bulk Delivered-to: mailing list discuss@davis.jini.org Mailing-List: contact discuss-help@davis.jini.org; run by ezmlm List-Post: List-Unsubscribe: List-Help: X-No-Archive: yes While thinking about codebase redundancy and preferred classes I started to wonder a) how (Preferred) classloaders in general work with unreachable URLs and b) what the effect of a broken link can be on retrieving the PREFERRED.LIST Assume my classes are marshalled with a codebase annotation of: 'http://host-A/dl.jar http://host-B/dl.jar' The 2 jar files are identical, the only difference is that they are served from 2 different hosts. The 2 jar files may refer to other jar files via the Class-Path manifest entry. A client classloader involved in unmarshal the annotated classes will probably try to obtain the dl.jar from host-A. If that doesn't succeed (broken network, webserver down for maintenance, etc.) what will the PreferredClassLoader do, will it ignore http://host-A/dl.jar and just use http://host-B/dl.jar ? If so will it use the PREFERRED.LIST of the dl.jar from host-B. Stated in the javadoc at PreferredClassLoader is: "These preferred lists must reside in a JAR file or directory which is relative to the first URL of each preferred class loader and must be named by the value of the static field PreferredClassProvider.PREF_NAME". In my opinion http://host-B/dl.jar is the second URL. What if after a while (in a situation not all jar files from host-B are fetched and cached) host-B goes down and host-A is up and running again? BTW something that keeps popping up in my mind at regular intervals: I remember from previous discussion at the RMI list and Jini Users that the URLClassLoader (or http protocol handler) always caches jar files once retrieved and doesn't check if it has been modified. If this is still true are there any plans to change this behavior. Probably I oversee many issues involved with versioning but I think this would be the first hurdle to take. Probably using a different URL for each version is a better and easier approach as this would allow different versions to coexists. We have a need to upgrade services in a running system, my guess is that these upgrades in 95% of the cases are implementation (preferred classes) related and not specification, therefore I'm thinking about a right approach. -- Mark Brouwer --------------------------------------------------------------------- To unsubscribe, e-mail: discuss-unsubscribe@davis.jini.org For additional commands, e-mail: discuss-help@davis.jini.org >From - Wed --------------080409020708010801070500 Content-Type: message/rfc822; name="Attached Message.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message.eml" Return-path: Received: from pavo.virgil.nl (pavo.virgil.nl [194.134.241.138]) by virgo.virgil.nl (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H4V00K8J9313T@virgo.virgil.nl> for marbro@ims-ms-daemon (ORCPT mark.brouwer@virgil.nl); Thu, 31 Oct 2002 22:59:26 +0100 (CET) Received: from jini.org (h36.sfo.collab.net [64.125.133.46]) by pavo.virgil.nl (8.10.2+Sun/8.10.2) with SMTP id g9VLxNV02012 for ; Thu, 31 Oct 2002 22:59:24 +0100 (CET) Received: (qmail 5997 invoked by uid 5302); Thu, 31 Oct 2002 21:59:18 +0000 Received: (qmail 5988 invoked from network); Thu, 31 Oct 2002 21:59:17 +0000 Date: Thu, 31 Oct 2002 16:59:13 -0500 (EST) From: Peter Jones - JavaSoft East Subject: Re: Codebase redundancy and PREFERRED.LIST To: discuss@davis.jini.org Reply-to: discuss@davis.jini.org Message-id: <200210312159.g9VLxDN21115@terrier.East.Sun.COM> Precedence: bulk X-Sun-Charset: US-ASCII Delivered-to: mailing list discuss@davis.jini.org Mailing-List: contact discuss-help@davis.jini.org; run by ezmlm List-Post: List-Unsubscribe: List-Help: X-No-Archive: yes >While thinking about codebase redundancy and preferred classes I started >to wonder a) how (Preferred) classloaders in general work with >unreachable URLs and b) what the effect of a broken link can be on >retrieving the PREFERRED.LIST > >Assume my classes are marshalled with a codebase annotation of: > > 'http://host-A/dl.jar http://host-B/dl.jar' > >The 2 jar files are identical, the only difference is that they are >served from 2 different hosts. The 2 jar files may refer to other jar >files via the Class-Path manifest entry. > >A client classloader involved in unmarshal the annotated classes will >probably try to obtain the dl.jar from host-A. If that doesn't succeed >(broken network, webserver down for maintenance, etc.) what will the >PreferredClassLoader do, will it ignore http://host-A/dl.jar and just >use http://host-B/dl.jar ? > >If so will it use the PREFERRED.LIST of the dl.jar from host-B. Stated >in the javadoc at PreferredClassLoader is: "These preferred lists must >reside in a JAR file or directory which is relative to the first URL of >each preferred class loader and must be named by the value of the static >field PreferredClassProvider.PREF_NAME". In my opinion >http://host-B/dl.jar is the second URL. That opinion/interpretation is correct. More text from the current spec: If there is no resource in the location described by PreferredClassProvider.PREF_NAME, preferred class loaders should assume that they contain no preferred resources. At runtime, any preferred list file resource that is located relative to the first URL of a preferred class loader will provide the only source of preferred information for the loader's entire path of URLs (preferred lists in other locations are ignored) Whether or not the current spec makes this entirely clear, the idea is that if a PreferredClassLoader cannot determine with reasonable certainty that the contents of the first URL either does or does not contain a PREFERRED.LIST, then the class or resource loading operation should fail (with a ClassNotFoundException or null, the latter case for resource-loading being somewhat ambiguous, unfortunately). In other words, PreferredClassLoader.isPreferredResource must throw an IOException (rather than returning false) if it cannot determine the existence of a PREFERRED.LIST at the first URL definitively one way or the other (such as because of a network failure). The current "@throws IOException" specification of isPreferredResource is not well worded to reflect this intention, but that's a known issue that will be fixed. >BTW something that keeps popping up in my mind at regular intervals: I >remember from previous discussion at the RMI list and Jini Users that >the URLClassLoader (or http protocol handler) always caches jar files >once retrieved and doesn't check if it has been modified. Specifically, it's the "jar:" URL scheme handler [that is responsible for this caching], which is used by the URLClassLoader implementation to load classes and resources from URLs to JAR files-- and URLClassLoader doesn't provide a way to control what value of "useCaches" to use for the "jar:" URLs it uses internally. >If this is still true are there any plans to change this behavior. Not that I know of. Workarounds still include the URLConnection.setDefaultUseCaches(false) hack and providing your own "jar:" URL scheme handler, as discussed in these messages: http://archives.java.sun.com/cgi-bin/wa?A2=ind0202&L=jini-users&P=R24352 http://archives.java.sun.com/cgi-bin/wa?A2=ind0206&L=jini-users&P=R24578 -- Peter --------------------------------------------------------------------- To unsubscribe, e-mail: discuss-unsubscribe@davis.jini.org For additional commands, e-mail: discuss-help@davis.jini.org --------------080409020708010801070500 Content-Type: message/rfc822; name="Attached Message.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message.eml" Return-path: Received: from pavo.virgil.nl (pavo.virgil.nl [194.134.241.138]) by virgo.virgil.nl (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H54006JQ2ASUQ@virgo.virgil.nl> for marbro@ims-ms-daemon (ORCPT mark.brouwer@virgil.nl); Tue, 05 Nov 2002 17:11:16 +0100 (CET) Received: from jini.org (h36.sfo.collab.net [64.125.133.46]) by pavo.virgil.nl (8.10.2+Sun/8.10.2) with SMTP id gA5GBFV12587 for ; Tue, 05 Nov 2002 17:11:16 +0100 (CET) Received: (qmail 25638 invoked by uid 5302); Tue, 05 Nov 2002 16:11:09 +0000 Received: (qmail 25629 invoked from network); Tue, 05 Nov 2002 16:11:07 +0000 Date: Tue, 05 Nov 2002 17:11:04 +0100 From: Mark Brouwer Subject: Re: Codebase redundancy and PREFERRED.LIST To: discuss@davis.jini.org Reply-to: discuss@davis.jini.org Message-id: <3DC7ED98.F41878F@virgil.nl> Organization: Virgil B.V. MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Precedence: bulk Delivered-to: mailing list discuss@davis.jini.org Mailing-List: contact discuss-help@davis.jini.org; run by ezmlm References: <200210312159.g9VLxDN21115@terrier.East.Sun.COM> List-Post: List-Unsubscribe: List-Help: X-No-Archive: yes Peter Jones - JavaSoft East wrote: > > In other words, PreferredClassLoader.isPreferredResource must throw an > IOException (rather than returning false) if it cannot determine the > existence of a PREFERRED.LIST at the first URL definitively one way or > the other (such as because of a network failure). The current "@throws > IOException" specification of isPreferredResource is not well worded to > reflect this intention, but that's a known issue that will be fixed. > This rules out the possibility of Codebase Redundancy by specifying multiple redundant URLs in the codebase. However I see at least two reasons to have such a feature: - service is exported on multiple interface. In case the networks are truly separated and there is just one URL that points to a webserver in one of the networks, only clients on the network that can reach the webserver are able to download the classes; - I have a cluster of services running at distinct locations and the registered proxies have some failover mechanism. I replicate the download jar files at multiple locations as I don't want to have a single point of failure, there must be a way that once annotated classes get their code from multiple places to make this work; I could invent my own protocol to accommodate these requirements like the JRAP project (http://jrap.jini.org/) but then I have the problem of convincing people to install the protocol handler, we all know what my chances are to get this done at a large scale. Therefore it would be nice if such a feature could be arranged by the codebase annotation and that URLClassLoader and therefore PreferredClassLoader could deal with this or ... why not make this a feature* of the httpmd protocol handler we all hope will be common once on every client JVM. It could be implemented within the already defined syntax of the httpmd URL if the comma ',' would be defined as a multiple comment separator, e.g.: httpmd://host1:port/path/dl.jar;md5=xxx,bu:host2:port,bu:host3:port,.jar In case a comment starts with 'bu:' it defines an alternative location for retreiving the download jar. This would require that the path segment is the same for each download location but this is not a problem. [*] I fear the answer will be in terms of "Right now our energy is focused on getting Davis done" ;-) but whether such a feature is in fact a requirement for some next release would be nice. -- Mark Brouwer --------------------------------------------------------------------- To unsubscribe, e-mail: discuss-unsubscribe@davis.jini.org For additional commands, e-mail: discuss-help@davis.jini.org --------------080409020708010801070500 Content-Type: message/rfc822; name="Attached Message.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message.eml" Return-path: Received: from pavo.virgil.nl (pavo.virgil.nl [194.134.241.138]) by virgo.virgil.nl (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H54006LZ8RBUQ@virgo.virgil.nl> for marbro@ims-ms-daemon (ORCPT mark.brouwer@virgil.nl); Tue, 05 Nov 2002 19:30:47 +0100 (CET) Received: from jini.org (h36.sfo.collab.net [64.125.133.46]) by pavo.virgil.nl (8.10.2+Sun/8.10.2) with SMTP id gA5IUkV12844 for ; Tue, 05 Nov 2002 19:30:46 +0100 (CET) Received: (qmail 789 invoked by uid 5302); Tue, 05 Nov 2002 18:30:38 +0000 Received: (qmail 694 invoked from network); Tue, 05 Nov 2002 18:29:46 +0000 Date: Tue, 05 Nov 2002 13:21:10 -0500 From: Laird Dornin Subject: Re: Codebase redundancy and PREFERRED.LIST In-reply-to: <3DC7ED98.F41878F@virgil.nl> To: discuss@davis.jini.org Reply-to: discuss@davis.jini.org Message-id: <200211051321.10877.lairdd@savaJe.com> Organization: SavaJe Technologies MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Precedence: bulk Delivered-to: mailing list discuss@davis.jini.org Delivered-to: moderator for discuss@davis.jini.org Mailing-List: contact discuss-help@davis.jini.org; run by ezmlm User-Agent: KMail/1.4.1 References: <200210312159.g9VLxDN21115@terrier.East.Sun.COM> <3DC7ED98.F41878F@virgil.nl> List-Post: List-Unsubscribe: List-Help: X-No-Archive: yes On Tuesday 05 November 2002 11:11 am, Mark Brouwer wrote: > This rules out the possibility of Codebase Redundancy by specifying > multiple redundant URLs in the codebase. =20 Yes, it does. However, there are good reasons to believe that the fail o= ver=20 behavior of URLClassLoader is itself a bug. For more information see: http://developer.java.sun.com/developer/bugParade/bugs/4302427.html > However I see at least two reasons to have such a feature: >=20 > - service is exported on multiple interface. In case the networks > are truly separated and there is just one URL that points to a > webserver in one of the networks, only clients on the network > that can reach the webserver are able to download the classes; > > - I have a cluster of services running at distinct locations and the > registered proxies have some failover mechanism. I replicate the > download jar files at multiple locations as I don't want to have > a single point of failure, there must be a way that once annotated > classes get their code from multiple places to make this work; > > I could invent my own protocol to accommodate these requirements like > the JRAP project (http://jrap.jini.org/) but then I have the problem of > convincing people to install the protocol handler, we all know what my > chances are to get this done at a large scale. Yes, since JRAP URLs are ip address / host name independent, you can use = them=20 to serve classes to clients on both sides of a network interface. But th= e=20 deployment problem certainly does get in the way. JRAP alleviates this=20 problem somewhat by introducing a way to download custom algorithms for=20 handling code... so at least with JRAP you only need to install one proto= col=20 handler in every client. Thereafter customizeable algorithms (for fault=20 tolerance, etc.) can be installed dynamically. > Therefore it would be nice if such a feature could be arranged by the > codebase annotation and that URLClassLoader and therefore > PreferredClassLoader could deal with this or ... why not make this a > feature* of the httpmd protocol handler we all hope will be common once > on every client JVM. It could be implemented within the already defined > syntax of the httpmd URL if the comma ',' would be defined as a multipl= e > comment separator, e.g.: I think its quite hard to know in advance what code downloading robustnes= s=20 strategies an application will want to emply ahead of time. Trying to ad= d=20 behavior that works for everyone would add a large amount of complexity t= o=20 the currently simple httpmd url protocol handler. I think URLClassLoader= has=20 introduced a false sense of robustness with its glib fail over mechanism. > httpmd://host1:port/path/dl.jar;md5=3Dxxx,bu:host2:port,bu:host3:port,.= jar > > In case a comment starts with 'bu:' it defines an alternative location > for retreiving the download jar. This would require that the path > segment is the same for each download location but this is not a > problem. Feels very much like a specific solution in very general code. > [*] I fear the answer will be in terms of "Right now our energy is > focused on getting Davis done" ;-) but whether such a feature is in fac= t > a requirement for some next release would be nice. Its interesting to note that the Sun folks once considered a notion of=20 "dynamic protocol handlers." The JRAP project at least in part tries to=20 provide that capability. --Laird --------------------------------------------------------------------- To unsubscribe, e-mail: discuss-unsubscribe@davis.jini.org For additional commands, e-mail: discuss-help@davis.jini.org --------------080409020708010801070500--