[
https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881841#action_12881841
]
Mike Kienenberger commented on MYFACES-2730:
--------------------------------------------
> My first question is who fills the stack trace: the constructor of the
> exception or the try {} catch{} block.
Using Jakob's proposed statement without the try/catch will work the way you
want.
As for the discussion in general, Leonardo, can you provide an existing
concrete use case where throwing the exceptions will be an issue? If I
understand correctly, Jakob is saying that he doesn't know of any existing use
cases where this is going to be a problem. And we certainly don't want to
allow poorly-written code to be usable if we don't have to allow it.
I think we're all in agreement that if we have to log warnings, we will do so.
The question is whether we have to log warnings for existing code.
> FacesContext not available on application startup
> -------------------------------------------------
>
> Key: MYFACES-2730
> URL: https://issues.apache.org/jira/browse/MYFACES-2730
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-127, JSR-252, JSR-314
> Affects Versions: 1.1.8, 1.2.9, 2.0.0
> Reporter: Nick Belaevski
> Assignee: Leonardo Uribe
> Fix For: 2.0.2-SNAPSHOT
>
> Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch,
> MYFACES-2730-3.patch, MYFACES-2730-revert.patch
>
>
> If custom ResourceHandler calls FacesContext.getCurrentInstance() in
> constructor to read init parameters, null value is returned. This affects
> latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this
> case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
