[
https://issues.apache.org/jira/browse/MYFACES-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244991#comment-14244991
]
Leonardo Uribe commented on MYFACES-3929:
-----------------------------------------
I have changed the name of this issue to "Update
org.apache.myfaces.CONFIG_REFRESH_PERIOD to JSF 2.2" because we need to review
this feature fully. This is a development-only feature that comes from JSF
1.1/1.2, and many things have changed since that time.
The base idea of org.apache.myfaces.CONFIG_REFRESH_PERIOD web config parameter
is check if the configuration files have changed and if that so, reload MyFaces
to reflect the new configuration, to avoid redeploy. It doesn't detect changes
over the classloader or web.xml, because a change there is better done by
plugins like jetty or other IDEs.
Since JSF 1.1/1.2 this checks for changed on faces-config.xml files in
/WEB-INF/faces-config.xml or javax.faces.CONFIG_FILES . But in JSF 2.2 we have
now new configuration files:
- .taglib.xml files
- *-flow.xml files
- files under javax.faces.FACELETS_LIBRARIES or facelets.LIBRARIES
The first thing we need to do is update this feature so the last modified time
takes into account these files.
Other thing I detected after some tests was that we need to purge the
Application instance from the FacesContext, so once application is recreated,
the current request uses the newest instance. This ensures the changes are
reflected on the request that do the update.
It is a good idea to use FacesWrapper to locate the right class to do the
reload.
> Update org.apache.myfaces.CONFIG_REFRESH_PERIOD to JSF 2.2
> ----------------------------------------------------------
>
> Key: MYFACES-3929
> URL: https://issues.apache.org/jira/browse/MYFACES-3929
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.2.5
> Reporter: Sven Linstaedt
> Assignee: Leonardo Uribe
> Priority: Minor
> Attachments: myfaces-trunk.patch
>
>
> org.apache.myfaces.config.FacesConfigurator#purgeConfiguration() does a
> pretty good job, until custom factories for application, renderkit or
> lifecycle are installed. In this case, purge will fail, because the returned
> factory delegates do not contain a appropriate purge method.
> Given all delegates are implementing javax.faces.FacesWrapper#getWrapped()
> correct, this problem might be easily solved be fetching the wrapped factory
> instance as long as one is available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
