[
https://jira.jboss.org/browse/ARQ-299?page=com.atlassian.jira.plugin.syst...
]
Andy Gibson commented on ARQ-299:
---------------------------------
Proposed solution at :
http://github.com/andygibson/arquillian/tree/ARQ-299
Make the exception in the test result transient so it is not serialized, when you set the
exception, build a proxy for that exception which can be serialized. Also recursively
proxy the exception cause so we can re-build the whole exception stack.
When getThrowable is called, if the value is null (i.e. in a client side unserialized
TestResult instance) then we lazily re-build the exception from the proxy if the proxy is
not null. We also rebuild the cause exceptions down the stack. If an exception class
cannot be created because the class isn't on the client or it doesn't have a
simple exception constructor (i..e faces validation exception) then a
ArquillianProxyException (name can be changed) is created instead which references the
name and message of the original exception and hints at why the exception couldn't be
re-created.
Is there is a way to determine if the test is running on the server or in the client? If
so, we can skip the exception proxying for the client run testing since the throwable
value will always be set in the test result and we have no need to proxy it.
One problem that still remains is the ability to check for specific exceptions as a test
result if those exceptions cannot be proxied correctly (i.e. faces validation exception
which needs a faces context or faces messages in its constructors). Since we can't
put those exceptions back properly without coding for each case and coming up with a faces
context, on the client side, its going to break those tests that expect validation
errors.
Create a IN_CONTAINER Exception Proxy
-------------------------------------
Key: ARQ-299
URL:
https://jira.jboss.org/browse/ARQ-299
Project: Arquillian
Issue Type: Feature Request
Reporter: Aslak Knutsen
On Exception, the IN_CONTAINER TestRunner tries to serialize the caught Exception back to
the Client so it can be displayed as if it was local. The problem is if you don't have
the Client lib on Client Classpath or you have the wrong version of it. This results in a
Deserialization exception on the Client.
We probably have to not Serialize the actual Exception, but serialize a Textual
representation of it, which we can create a 'proxy' Exception of on the client
side and make it 'look' like the original.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira