[
https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881383#action_12881383
]
Leonardo Uribe commented on MYFACES-2730:
-----------------------------------------
Hi Jakob
At this point it is possible to identify the real reasons we should take into
account.
- Throw UnsupportedOperationException makes the application cannot be deployed,
even if it is possible to do it.
- It is necessary to tell user/developer that the called method is not
available on startup, and it is being called on that time by some code.
- It is not possible in a standard way to know when jsf is being initialized
but in myfaces we can look at
"org.apache.myfaces.webapp.StartupServletContextListener.FACES_INIT_DONE"
servletContext param. So if a user needs to execute some "invalid" code in the
constructor of some object created by a jsf Factory, it should rely on this
param to check this condition.
- When unwanted code could be executed? when some object that is instantiated
by a Factory is created. Usually the relevant place to find that code is the
constructor. But in theory since the lifecycle of those objects ends with the
request, we can ignore it if they are created at startup. The point is use that
code could be unintentional, but there is not enough reason to prevent deploy
an application.
The behavior of RI is just taken as reference, not to explain the reasoning,
but the common sense says if the did something in this or that way it must be
for something.
If there is a standard way to check when an jsf application is being
initialized, the reasoning proposed changes and in that case I'll be in favor
to throw Exceptions aggresively, but the scenario we have right now is
different.
After all previous reasoning I think the best is log a warn message on all
methods that should not be called during startup, so the user could be aware
about that, but do not throw UnsupportedOperationException, that prevents
deploy an application even if it is possible to do it.
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-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.
