river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: River & OSGi
Date Thu, 19 Nov 2009 20:36:20 GMT
Can you clarify your question for me?

I'm having a discussion about Classloader separation, modularity (OSGi), 
and binary compatibility within the local JVM, sharing of bytecode when 
it should be, eg shared domain objects, marshalled, unmarshalled or 
otherwise.  I'm trying to find a solution to this problem of ensuring 
compatible packages are loaded within each jvm on separate nodes 
participating in a djinn, I can see that static analysis can help 
resolve dependencies and record Package API signatures for fast runtime 
comparison before loading classes.

So yes the goal is binary compatibility, currently in Jini, unmarshalled 
objects, if utilising downloaded code and not locally preferred classes, 
will be loaded in separate Classloaders, so they may not be visible to 
each other at runtime, yes they can participate if they share a common 
supertype or a common interface, however creating an interface for every 
domain object that should be shared is a lot of work.  Not only that, an 
interface, once created, doesn't evolve in a friendly manner, your 
domain objects become snared, not able to be refactored easily.

So yes, the Jini discovery mechanism allows evolvability of systems by 
allowing new services to be made available, but they don't share objects 
nicely with the older existing services (unless you have locally 
installed preferred classes, which defeats the purpose of discovery) and 
they don't help with local Classloader isolation issues, nor will they 
assist with unmarshalling an object that has been persisted for which 
the URL from which the bytecode originated no longer exists.

But I'm wondering, I think you know the River codebase far better than I 
do, you are far more qualified than I, so I think that you'd be 
surprised if I uncovered something you didn't already know, so I was 
hoping that you might rephrase that question again so I can better 
answer it?



Peter Firmstone wrote:
> I'll get back to you on the weekend, but just to clarify, I think the 
> best time to collect Package API signatures is at build time, with the 
> build environment as it was intended by the developer.  Utilising the 
> freshly compiled class files and third party jar files, to create dist 
> jar files containing the Package API signature information.  I've been 
> referring to Package API signatures as class metadata, it doesn't have 
> to be shoehorned into the manifest though.
> Dennis Reedy wrote:
>> On Nov 18, 2009, at 1105PM, Mike McGrady wrote:
>>> There are of course limits and they come very quick to what you can 
>>> do to modify a jar file.
>> Very true, this goes for manifest modifications as well. Since all 
>> the 'proposed' analysis is done at build time jars can be modified 
>> with either approach. I suppose to a certain extent, its convention 
>> over configuration.
>> If the goal is binary compatibility, then does the existing type 
>> based lookup and discovery mechanism that Jini provides allow 
>> evolvability of systems? If not, where and why does it not?
>> Perhaps I missed this analysis on this thread, but can we break this 
>> down first prior to jumping into implementation details?
>> Dennis

View raw message