[
https://issues.apache.org/jira/browse/TOMAHAWK-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631980#action_12631980
]
Leonardo Uribe commented on TOMAHAWK-1170:
------------------------------------------
The actual behavior is this:
Default:
org.apache.myfaces.CHECK_EXTENSIONS_FILTER is true
org.apache.myfaces.DISABLE_TOMAHAWK_FACES_CONTEXT_WRAPPER is false
If no extensions filter is configured, TomahawkFacesContextWrapper is used. In
portlet world, TomahawkFacesContextWrapper is always used.
The new default behavior is this
org.apache.myfaces.CHECK_EXTENSIONS_FILTER is true
org.apache.myfaces.DISABLE_TOMAHAWK_FACES_CONTEXT_WRAPPER is true
If no extensions filter is configured, no alternative is used.
So the solution proposed is change the default value of
org.apache.myfaces.DISABLE_TOMAHAWK_FACES_CONTEXT_WRAPPER from false to true,
and check this config param in portlet world, so there should be a way to
disable it in portlet world too.
> Resource mapping missing / throwExtensionsFilterMissing reported incorrectly
> under load
> ---------------------------------------------------------------------------------------
>
> Key: TOMAHAWK-1170
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1170
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: ExtensionsFilter
> Affects Versions: 1.1.7-SNAPSHOT
> Reporter: Simon Kitching
>
> It has been reported by two users that under load an application using
> Tomahawk intermittently throws an exception claiming "resource mapping
> missing".
> This message is meant to be thrown when a component in a request wants to
> register stuff for the extensions filter to output, but the current request
> never passed through the extensions filter. This is a sanity check to ensure
> that people that misconfigure the ExtensionsFilter get a helpful error
> message rather than just having tomahawk components that need additional
> resources acting weirdly.
> A workaround is to disable this safety check. The first reporter of this
> problem did disable the check and found the issue disappeared.
> The problem appears to be a race condition between multiple threads *reading*
> a map; at least that was the only piece of code I found that had any obvious
> thread race issues. I can't remember the exact piece of code for the moment,
> but will update this issue when I find it again.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
