[
https://jira.jboss.org/browse/WELD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12534389#action_12534389
]
Pete Muir commented on WELD-531:
--------------------------------
I'm not really understanding what you are asking for? A matrix which shows
which version of Weld is used in what container, and when an update is planned?
> 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
> Assignee: Pete Muir
> Priority: Blocker
>
> 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
