Peter, I am not sure I really understand the exact issue(s) that you want to
resolve. Jini has the behavior that clients dynamically discover the "code"
that they will use. OSGi has the attribute that clients load packages for the
"code" that they use. In both cases, the deployment mechanism has established
the content that is "the code". OSGi includes more literal dependency
specifications from each packages perspective. Jini doesn't do it that way.
Instead, the "codebase" and "classpath" mechanisms are used to "tell" the system
that is built what to do.
When you get into a more arbitrary environment like "the internet", then more
expressive and more detailed relationship descriptions between packages can help
make it possible for multiple packages to use multiple versions of the same
package. The code in com.sun.jini.start provides the mechanism for services to
be separated from each other, but not from the system classpath.
I think it would be a good idea to just detail the concerns first, and then
discuss where those concerns are visible or problematic so that we can work
through any other issues that might be stimulated forth, out of the discussion.
Gregg
My main concern here is usability, River presents a problem for new
developers, by behaving in ways (because of the underlying java
platform) that are non intuitive, brittle and unexpected.
Eg: codebase annotation losses when remote objects are transferred
around the network, or where multiple remote objects interact in the
same jvm.
If possible I'd like to make the default behaviour intuitive, without
the need for a detailed understanding of class loaders, codebase
annotation losses etc for the application developer, but without
limiting advanced developers who have a detailed understanding.
Jini concepts are simple and elegant, the implementation isn't, perhaps
because we push the boundaries of the java platform itself.
I'm starting to think that each remote service with a smart proxy
deserves it's own separate namespace, due to class versioning issues. I
can't think of any way to fix the current issues using ClassLoaders
alone and smarter minds have spent many hours contemplating the problem.
We could use two jvm's, one for local code, one for remote downloaded code.
Each remote proxy should have jsk-platform.jar and any libraries it
needs in it's own classloader, in the remote process jvm. So the remote
process jvm has a flat hierarchy of ClassLoaders, each containing a
smart proxy namespace. A small management kernerl would manage it in
the application classloader.
The client interacts through these via reflective proxy's. Smart
proxy's in the remote process jvm can be passed reflective proxy's that
refer to other smart proxy's in different ClassLoaders, if obtained from
the client. Then the codebase annotations can even contain and utilise
different versions of River, excluding the policy provider of course,
which will be controlled by the client. Proxy verification would have
to be performed in the remote process jvm.
This relies on maintaining Serialized form compatibility between
versions, since serialization alone would be used to transfer classes
between the client and remote process jvm.
Thoughts?
Peter.
On 8/29/2011 5:32 AM, Peter Firmstone wrote:
> On 29/08/2011 6:23 PM, Peter Firmstone wrote:
>>> On 28 August 2011 09:18, Peter Firmstone<peter.firmst...@zeus.net.au>
wrote:
>>> >
>>> > Then we stop using the preferred classes mechanism by default.
>>> >
>>>
>>> Why?
>>>
>>> > This will allow us to prevent codebase annotation loss.
>>> >
>>>
>>> Because of annotation loss? That's quite a serious compromise and
>>> prevents service implementers from doing version management of code in
>>> their proxies amongst other things. That's a killer as it requires all
>>> services to move with the platform all the time which implies forced
>>> mass upgrades etc.
>>
>> Hmm, ok, so these are implementation private copies / concerns, unless they
>> share a common interface or superclass with the platform.
>>
>> The other alternative exteme is to prefer all classes other than those in
the
>> service api, meaning the proxy get's to have all it's own implementation
>> classes, this would definitely prevent codebase annotation loss.
>>
>> So if that's the case, is it possible to automate the preferred list?
>>
>> Now what happens if we extend an existing Service API and the extension
>> classes are not installed on the client, the proxy must download them.
>>
>> So how about for all codebase annotations ending in *api.jar, we consult the
>> parent classloader first, followed by the proxy ClassLoader
>> (PreferredClassLoader) and for all other codebases, we try the proxy
>> Classloader first, then the parent classloader if not found, or perhaps only
>> the proxy classloader then throw a ClassNotFoundException?
>
> This would require some very carefull thought, feel free to mention any
gotcha's
> you can think of. Any java classes would also have to delegate up.
>
> Perhaps this isn't quite the right approach, perhaps the right approach is to
> create a tool that generates preferred class lists for developers, all
comments
> and thoughts are welcome.
>
> Another problem is, if a client retains references to objects from a proxy,
this
> can prevent the proxy classloader from being garbage collected, even if the
> client has finished with the proxy itself.
>
> To me it appears that the client and proxy should only interract using the
> service api or common interfaces and jvm classes. This would also be useful
to
> enable clients and proxy's to run is separate jvm's, where each has it's own
> runtime zone? In this case the proxy could use one version of a class, while
the
> client uses another, provided that the serialized form is still compatible,
you
> don't have to suffer the ClassLoader visibility problems then.
>
> Cheers,
>
> Peter.
>
>>
>> Then developers don't need to try figure out what classes are preferred,
>> simplifying development.
>>
>> This allows each proxy to have it's own private implementation namespace.
>>
>> Thoughts?
>>
>> Cheers,
>>
>> Peter.
>>
>>
>
>
