river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: MarshalledServiceItem
Date Thu, 03 Feb 2011 00:32:57 GMT
On 2/2/2011 6:15 PM, Peter Firmstone wrote:
> Michał Kłeczek wrote:
>> On Thu, Feb 3, 2011 at 12:47 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>> I like the fact that Gregg's pushed the envelope, he's pushed Jini beyond
>>> it's current capability.
>>> Now I'm wondering if there's a way around the Preferred Classes problem.
>> The problem with PREFERRED.LIST is more fundamental - for example
>> every RemoteEvent producer is forced to download a jar file just to
>> check that RemoteEventListener is not preferred. As such the issue
>> cannot be solved at the LUS API level.
>> Michal
> Yes there are more fundamental problems with preferred classes, ClassLoading etc
> that remain to be solved.
> But rather than fix it on this occassion, MarshalledServiceItem is just resolved
> with local classes and preferred class loading is not used or needed. When the
> client unmarshalls the MarshalledServiceItem, then preferred class loading will
> be used and jar files downloaded. MarshalledServiceItem can provide a
> significant amount of information by just resolving using local classes, which
> the client can utilise.
> In the long term I see it like this:
> We need to look into dependency inversion to remove implementation classes from
> the platform and application class loader, which is the problem that preferred
> class loading addresses.
> If implementation classes are not present in the platform, you don't need
> preferred classes for proxys to have their own copy of an implementation class,
> because those classes will be resolved by standard java classloading rules in
> the proxy class loader.

One thing to note, is that I have used PreferredClassLoader to fix bugs by 
taking common classes that I use in GUI constructions that would have been 
resolved in the parent loader and switching them to be preferred so that I'd get 
the fixed version.  I am not sure that there is a perfect "split" of 
implementation vs platform.  Sometimes implementation can be a mini-platform of 
sorts.  Just repackaging/rearranging jars is not a singular fix, always.

Gregg Wonderly

View raw message