> On 15 Feb 2022, at 13:05, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:
>
>
>> How the client knows the code needed to deserialise?
> The service provides this information, typically in a services configuration,
>
How is this configuration provided to the client and when?
> by default this is a space separated list of URI, similar to a codebase
> annotation, but it doesn't have to be. JERI manages the deserialization of
> code through a default ProxyCodebaseSpi implementation,
>
How does the default ProxyCodebaseSpi implementation know where to download
code from if there are no annotations?
> the client applies constraints, to ensure that input validation is used as
> well as any other constraints, such as principals, or encryption strength.
> ProxyCodebaseSpi can be customized by the client, so the client may implement
> ProxyCodebaseSpi if it wants to do something different, eg use OSGi or Maven
> to manage dependency resolution.
>
Ok, so the client has to know in advance how to load the service code?
>
>> Does it require to have it installed in advance? If so - how?
> Only JGDMS platform and JERI.
>
>
>
How are service proxy classes loaded then?
>> How is the following scenario handled:
>>
>> class JavaSpaceEventPublisher implements RemoteEventListener, Serializable {
>> private final JavaSpace space;
>>
>> //… publish event in JavaSpace implementation
>> }
>>
>> The smart proxy class has dependencies on RemoteEventListener and on
>> JavaSpace. How do you properly resolve classes in this case?
> Typically the client has the ServiceAPI it needs already installed locally,
> however this may not always be the case, depending on how you want to resolve
> the proxy classes and how much you want to share with the client, you can
> include additional jar files in the annotation, and use preferred.list or you
> can use Maven or OSGi to resolve dependencies and provision the ClassLoader
> used for proxy deserialization.
>
I am asking about something different - the smart proxy class depends on _two_
interfaces:
RemoteEventListener <—— proxy class ——> JavaSpace
RemoteEventListener is its service interface.
But it is not known in advance what interfaces the client already has:
1) Just RemoteEventListener
2) Both RemoteEventListener and JavaSpace
3) None
How is class resolution implemented in JGDMS so that it works properly in _all_
of the above cases?
> …[snip]
>
> If you want to use non final classes for your service method arguments and
> allow clients to override these classes, then you will need to enable
> codebase annotations in AtomicILFactory in your configuration. The caveat
> is there is no guarantee, the service will be able to resolve these classes
> at the server endpoint, or that codebase annotation loss won't occur, it will
> try using existing mechanisms, such as RMIClassLoaderSPI, which is probably
> fine for seasoned Jini vets, but not so user friendly for the newbie, who now
> has to debug ClassNotFoundExceptions.
>
>
That’s why I got rid of RMIClassLoaderSPI completely - this is simply a wrong
API and has to be thrown away.
Michal
