Return-Path: Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org Received: (qmail 39599 invoked from network); 16 Jul 2009 09:56:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Jul 2009 09:56:17 -0000 Received: (qmail 87713 invoked by uid 500); 16 Jul 2009 09:57:22 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 87687 invoked by uid 500); 16 Jul 2009 09:57:22 -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 87677 invoked by uid 99); 16 Jul 2009 09:57:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jul 2009 09:57:22 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [61.9.168.152] (HELO nskntmtas06p.mx.bigpond.com) (61.9.168.152) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jul 2009 09:57:12 +0000 Received: from nskntotgx01p.mx.bigpond.com ([58.171.191.95]) by nskntmtas06p.mx.bigpond.com with ESMTP id <20090716095648.LDJR1960.nskntmtas06p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com> for ; Thu, 16 Jul 2009 09:56:48 +0000 Received: from [10.239.185.199] (really [58.171.191.95]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20090716095647.ZZZ6272.nskntotgx01p.mx.bigpond.com@[10.239.185.199]> for ; Thu, 16 Jul 2009 09:56:47 +0000 Message-ID: <4A5EF95F.6080600@zeus.net.au> Date: Thu, 16 Jul 2009 19:56:47 +1000 From: Peter Firmstone Organization: Zeus Project Services User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: river-dev@incubator.apache.org Subject: Re: Class Loading issues References: <4A5E6994.2060606@zeus.net.au> <4A5EEAE7.5040903@zeus.net.au> In-Reply-To: <4A5EEAE7.5040903@zeus.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4A5EF960.008D,ss=1,fgs=0 X-Virus-Checked: Checked by ClamAV on apache.org How about something totally different? A codebase lookup service perhaps? Given a class name, serialVersionUID and class file checksum it can return a list of URL's registered as providing that service and containing that class and return a new checksum if the class file has been updated in a compatible manner, a lookup table could be provided and another service to propagate updated class file checksums relevant to a particular class name and serialVersionUID between codebase lookup services. A classfile checksum would need to be generated for each class (when?) and sent with the marshalled object, instead of a list of codebase URL's A background process might also check the currently loaded class files periodically for updates, and update it? How could this be done? Class file caching proxy's could also register as codebases with the lookup service, in order to reduce remote network traffic and preserve class files when codebases are down? I'd be interested in what Dennis Reedy has to say about QOS? Also posted to Jira Cheers, Peter. Peter Firmstone wrote: > Done Thanks Mike, > > Peter. > > Michael Warres wrote: >> On Wed, Jul 15, 2009 at 7:43 PM, Peter Firmstone >> wrote: >> >>> I stumbled across your paper on Class Loading issues in RMI and >>> Jini, I'm on >>> the River dev mailling list, I'm wondering if I may upload your >>> paper to >>> JIRA or our Wiki so we can follow up on your findings? >>> >> >> Sure, fine by me (not that you need my permission--it looks like the >> copyright >> permits this, though IANAL). >> >> Thanks, >> -Mike >> >> > >