[
https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881827#action_12881827
]
Leonardo Uribe commented on MYFACES-2730:
-----------------------------------------
Hi Jakob
Do you have anything more than your personal opinion for argument your point of
view? I did a list with all arguments I have to support the patch proposed, but
at this time none of them has been questioned without provide more arguments to
the discussion.
Let's review your last response:
"....Yes, aggresively throwing UnsupportedOperationException could prevent
applications from beeing deployed, but those applications include invalid
behavior...."
This afirmation is not necessary true. Note that Factory objects are still
being created during initialization.
"... Throwing and immediatly catching an Exception does not make much sence to
me ..."
The idea is have an exception logged with the stack trace filled. I'm not tried
yet the other form but if it is possible to see the stack trace on the log that
include the method name that is being called it is ok to do that change. My
first question is who fills the stack trace: the constructor of the exception
or the try {} catch{} block.
"...I think StartupFacesContextImpl contains many (somehow) duplicate code to
FacesContextImpl. Thus this may be a problem with maintaining... "
Given the arguments proposed the distinction between how
StartupFacesContextImpl and FacesContextImpl works is clear. In the first case
we need to log some methods that should not be called, return dummy stuff and
throw exceptions in other parts. In the second case we need a working
implementation. The previous case we proposed in the first patch (for
StartupExternalContextImpl) was different because we are not considering log
methods or throw exceptions at all. So maintaining is no longer a concern,
because we don't have choice.
".... First it lets invalid code be deployed and second it may be hard to
maintain (see the issues we had with the dummy Servlet request and response
classes in the past...) ...."
Note the issues we had with the dummy Servlet request and response classes was
for precisely throw Exceptions aggresively. That kind of bugs is what I want to
prevent. They are very annoying and since that we don't have a standard way to
recognize when we are initializing, we could force users to use specific
myfaces hacks to make its code work.
A vote could be necessary if we have different opinions but based on proper
arguments. What we need to do first is exhaust the arguments, or in other
words, find the truth behind the arguments.
I invite you to try to find if there is something is not being consider or if
there are wrong assumptions, and if so, I'll formulate another alternative to
solve this issue. I'll take my time to review all this stuff again.
regards,
Leonardo
> 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.
