Re: [ecf-dev] Exception Handling of Remote Calls

[Peter Hermsdorf <peter.hermsdorf@xxxxxxxxx>]

Hi Scott,

> With ECF, it is quite possible...and encouraged...to create/use your 
> own RS provider, and your provider either extend an existing provider 
> (generic, r-osgi, JMS, mqtt, or otherwise), and then that provider can 
> do whatever it wants with catching exceptions and wrapping etc.

I tried extending the generic provider to add the Exception wrapping

1) I registered my own IHostContainerSelector which extends 
HostContainerSelector
2) in my HostContainerSelector I have overridden createRSContainer and 
insead of

 container.getAdapter(IRemoteServiceContainerAdapter.class);

I used my own Implementation of RegistrySharedObject

thats because I haven't seen a way to intercept at the AdapterManager ...

3) in my RegistrySharedObject implementation I have overridden 
executeRequest and implemented my custom getSerializableException method.

The problem is that the Service does not get picked up by the client 
with RemoteReferenceNotFoundException.

After debugging (on server side) i found out that 
RemoteServiceAdmin.selectRemoteServiceReference does not return any 
references to my service. This is probably because the implementation is 
again fetching the IRemoteServiceContainerAdapter from the container ... 
which is obviously not my Implementation of RegistrySharedObject

Do you have any suggestions of how to intercept in this getAdapter 
loading mechanism?

Thanks,
Peter

> > Thanks,
> > Peter
> >
> >
> > Am 24.06.2014 16:08, schrieb Scott Lewis:
> > > Hi Peter,
> > >
> > > On 6/24/2014 5:23 AM, Peter Hermsdorf wrote:
> > > > Hi,
> > > >
> > > > i have a question regarding exception handling of remote calls 
> > > > which is not specific to ecf, but needs to be solved using ecf ;)
> > > >
> > > > When doing remote calls which result in any kind of exception not 
> > > > related to the remoting itself (eg. exceptions of 3rd party 
> > > > libraries used on server side) they get serialized back to the 
> > > > client which (most of the time) results in ClassNotFound Exception 
> > > > because the library specific Exception class is not known at client 
> > > > side.
> > > >
> > > > I would like to discuss ways to handle this kind of errors:
> > > >
> > > > 1) put all jars also on the client side
> > > >
> > > > that would be the easiest but (from my point of view) also the 
> > > > worst solution. Polluting the client with libraries which he only 
> > > > needs for error display seems wrong to be. besides introducing 
> > > > additional dependencies and larger deployment artifacts
> > > >
> > > > 2) catch "application" exceptions on server side and wrap them into 
> > > > a "general" exception class which is also known on client side
> > > >
> > > > catch Exceptions eg. in
> > > >
> > > > org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.executeRequest 
> > > >
> > > >
> > > > and before deserializing the response back to the client wrap the 
> > > > actual exception into a more general one (including copying call 
> > > > stack etc.)
> > > >
> > > > that would be my preferred solution, but i'm not sure what is the 
> > > > entry point to start with the implementation. Any hints are greatly 
> > > > appreciated.
> > > > Best would be to have an implementation for this kind of error 
> > > > handling which is not provider dependent...
> > > >
> > > > 3) catching all errors in the implementation of the remote service 
> > > > and wrap them into this kind of general Exception
> > > >
> > > > downside of this approach is a lot of boiler plate code in the 
> > > > remote service implementation and a pollution of the implementation 
> > > > itself with code which is only needed for error handling when 
> > > > called from remote....
> > > >
> > > >
> > > > Any other approaches or suggestions how to handle this kind of errors?
> > >
> > > I think you've identified the main approaches.    FWIW, I agree that 
> > > 1 is undesirable for the reasons you give.
> > >
> > > WRT 2 and 3 (catching and wrapping exceptions in host 
> > > implementation), ECF provides two classes to help out with these 
> > > strategies in org.eclipse.ecf.core.status package:
> > >
> > > org.eclipse.ecf.core.status.SerializableStatus
> > > org.eclipse.ecf.core.status.SerializableMultiStatus
> > >
> > > As the class names imply, these are serializable implementations of 
> > > the Equinox IStatus API.   They also have logic to check for whether 
> > > the constructor-provided Throwable is serializable, and if not then 
> > > a general Exception is substituted in the status object (which is 
> > > Serializable).   Of course they also have the IStatus/MultiStatus 
> > > hierarchical structure which can then be used across remote calls.
> > >
> > > This doesn't solve the general problem, but I think it does provide 
> > > some useful structures to implement 2 and 3.   Also, I'm open to 
> > > adding additional support, if other improvements can be identified.
> > >
> > > Thanks,
> > >
> > > Scott
> > >
> > >
> > > _______________________________________________
> > > ecf-dev mailing list
> > > ecf-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/ecf-dev
> >
> > _______________________________________________
> > ecf-dev mailing list
> > ecf-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev