[
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
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
