Comments inline.
Peter wrote:
N.B Can't see any chicken egg problem.
If service doesn't resolve to same service api as client, then it isn't
compatible. The client isn't interested in incompatible services, only those
that are compatible This is just an artifact of the dependency resolution
process.
But when do you perform resolution?
Lets say you have two client bundles:
Client1 is resolved to depend on package a.b.c ver 1.1.3 from bundle
a.b.c 1.1.3
Client2 is resolved to depend on package a.b.c ver 1.2.0 from bundle
a.b.c 1.2.0
Your service supports both clients. How do you resolve it so that it can
be linked with both clients?
The answer is - you can not. You must create two different instances of
the service proxy each one
instantiated from a class loaded in a different context.
But you cannot decide upon this context in advance!!! You have to know
which client you are serving.
No bundle indentifiers are necesary in the stream, the smart proxy ClassLoader
decides visibility and delegation, not RMIClassLoader.
But what ClassLoader is used to load the smart proxy???
You're attempting to do too many things with one class / object, there's a risk
that this very powerful class could be leveraged by an attacker, best to break
up the functionality.
Why do you think that it is handled by one class/object???
Also ServiceDiscoveryManager handles a lot of scenarios that occur with remote
services, your class wont, there are thousands of lines of code.
Have a look at SDM in JGDMS.
Sorry for sarcasm, but... This is one class/object doing so many things...
Thanks,
Michal
