[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Exception Handling of Remote Calls
|
Hi Peter,
On 6/26/2014 5:28 AM, Peter Hermsdorf wrote:
Hi Scott,
thanks for your response. I had a look at the class SerializableStatus.
From what i see that class is used for wrapping non-serializable
Exceptions, which is not my problem, because most "3rd party
exceptions" extend java.lang.Exception which implements Serializable.
So on server side these Exceptions would not get wrapped.
(additionally the method createNewExceptionFor(Throwable) would not
add the original stacktrace. that code is commented)
But the wrapped exception mechanism that I'm looking for would use
something very similar to that, probably that was your point ;)
Yes. :)
My current problem is that I'm not finding a good point to intercept
the error handling on remote calls to do the wrapping of the original
exception (without hacking and building ecf code).
This confuses me Peter. Wouldn't the easiest thing be to have the
implementation intercept any errors, and to do the wrapping there?
Maybe you have a pointer on how/where to do that.
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.
Creating a new provider is something that ECF RS uniquely enables, and I
would be happy to direct you to information about how to do that (for
example, here's a tutorial on how to create a REST-based provider [1]),
but there are two caveats:
1) It's naturally more involved than simply having the RS implementation
catch/wrap, etc., as it gives *much* more control of the
remoting/distribution.
2) All of this (new RS and/or discovery providers) is
ECF-specific...i.e. it's not OSGi standardized in any way at this point.
But it's my hope that people/companies/whatever will create their own
custom providers, and I'm very much in a mode of making it as easy as
possible to do that (with more tutorials [1], additional docs, etc).
So if that's what you would like to do (create a new provider) I'll be
happy to provide code pointers, etc. Please just let me know which
provider you would like to extend (generic? or other?).
I have to qualify my offer of support a little bit: I'm currently very
heavily engaged with the work on OSGi RS/RSA for *R6*, both in terms of
the work on the specification (I'm on the OSGi EEG), and in terms of
ECF's implementation. as ECF RS/RSA implementation is a candidate for
the R6 reference implementation.
If you or your employer would like to potentially consult with me
directly about this, please contact me at slewis at composent.com and I
would be happy to discuss.
Thanks,
Scott
[1]
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
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
