Hi Sebastian,
Is this solution finally working? I am
curious to know what is the working solution. Because, I too have
similar situation, but currently I am passing as a String and recreating
exception on client side. I know this is hack.
Regards
Raman
From: Raymond Feng [mailto:[email protected]]
Sent: Thursday, September 16, 2010 5:03 AM
To: [email protected]
Subject: Re: Throwable as method argument causes exception
You will have to add the setters for the properties so that JAXB can
unmarshal the data into the bean (wrapper).
________________________________________________________________
Raymond Feng
[email protected]
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
________________________________________________________________
On Sep 15, 2010, at 4:07 PM, Millies, Sebastian wrote:
Hello Mike,
strangely, when I pass my wrapper class over JMS to the service, both
its
attributes will be set to null by some mediating code in Tuscany.
Is there an example somewhere from which I can see what I am doing
wrong?
-- Sebastian
PS: For what its worth, here is the code of my Throwable wrapper:
public class ThrowableWrapper implements Serializable
{
private static final long serialVersionUID = 7112569161595756136L;
private byte[] b;
private String stacktrace;
public ThrowableWrapper()
{
}
public ThrowableWrapper( Throwable t ) throws IOException
{
// write the Throwable to a byte array
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(t);
b = baos.toByteArray();
// save stack trace as string, because it won't be serialized
StringWriter w = new StringWriter();
PrintWriter p = new PrintWriter( w );
t.printStackTrace( p );
stacktrace = w.getBuffer().toString();
}
public Throwable getThrowable() throws IOException,
ClassNotFoundException {
ByteArrayInputStream bais = new ByteArrayInputStream(b);
ObjectInputStream ois = new ObjectInputStream(bais);
Object t = ois.readObject();
return (Throwable) t;
}
public String getStackTraceString() {
return stacktrace;
}
}
-----Original Message-----
From: Millies, Sebastian
[mailto:[email protected]]
Sent: Wednesday, September 15, 2010 4:58 PM
To: [email protected]
Subject: Re: Throwable as method argument causes exception
Hello Mike,
thanks for the hint. In fact I have already tried using a
wrapper
class,
which did NOT serialize the Throwable, but simply stored it in
an
attribute
for which it also provided a getter-method. Imagine my surprise
when
the exception
went away. I am still puzzled about what is going on. It almost
seems
as if
JAXB did not traverse the entire object graph, but stopped after
one
level.
Anyway, I guess I really should serialize the Throwable, but for
my
purposes
I will want to serialize the stack trace, too, because I am
implementing a logging
service, which should as a matter of course log the stack trace
of the
exception
that is passed in by the client. I hope serializing to a byte
array is
acceptable
to JAXB.
-- Sebastian
-----Original Message-----
From: Mike Edwards
[mailto:[email protected]]
Sent: Wednesday, September 15, 2010 4:44 PM
To: [email protected]
Subject: Re: Throwable as method argument causes
exception
Millies, Sebastian wrote:
but that should not be a problem here. I am not
throwing an
exception,
I am simply passing one as a method parameter.
-- Sebastian
Sebastian,
Ah yes, I ran into this entertaining problem when I
coded the Async
invocation code in 2.x.
Fundamentally, the problem is caused because Throwable
is not
serializable - as others have noted,
it has a getStackTrace() method which causes the
problem.
When I wanted to pass an exception as a parameter, what
I did was to
create a wrapper class and put
the exception into the wrapper class, with the wrapper
class taking
care of the serialization of the
exception. This did mean that I did NOT serialize the
stack trace -
but in an SOA world, I think
that handing over stack traces between clients and
services is not a
good plan anyway, so I think
that this is OK.
You may wish to approach the problem along similar
lines.
Yours, Mike.
