[weld-issues] [JBoss JIRA] Updated: (WELD-531) Weld swallowing stacktrace in the case of multiple container errors

[Dan Allen (JIRA)]

     [ https://jira.jboss.org/browse/WELD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Allen updated WELD-531:
---------------------------

    Summary: Weld swallowing stacktrace in the case of multiple container errors  (was: Weld swallowing stacktrace when multiple container errors)


> Weld swallowing stacktrace in the case of multiple container errors
> -------------------------------------------------------------------
>
>                 Key: WELD-531
>                 URL: https://jira.jboss.org/browse/WELD-531
>             Project: Weld
>          Issue Type: Bug
>    Affects Versions: 1.0.1.Final
>            Reporter: Dan Allen
>
> When there are multiple container errors (for instance, definition errors at startup), Weld cycles through the errors and builds a localized message. However, it drops the cause of the exception. If the message is further up the chain (i.e., in the exception cause), this leads to exceptions such as:
> Exception #0: null
> The user is lost as to what the real problem is. Typically root causes are:
> - NoClassDefFoundError
> - NullPointerException
> The problem is not that the message is null. The problem is that the underlying cause is dropped.
> This came up recently when using Arquillian as reported in this forum post: https://community.jboss.org/message/544395#544395
> When placed in a debugger, it turned out that a NoClassDefFoundError was being thrown. There was no way for the user to trace that to the source.
> I think that what Weld needs to do is follow the cause until it finds a non-null message.

-- 
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