Michał Kłeczek wrote:
On Thu, Feb 3, 2011 at 12:47 AM, Peter Firmstone <j...@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.
Cheers,
Peter.
