[arquillian-issues] [JBoss JIRA] Commented: (ARQ-299) Create a IN_CONTAINER Exception Proxy

[Andy Gibson (JIRA)]

    [ https://jira.jboss.org/browse/ARQ-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12554384#action_12554384 ] 

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