[
https://issues.apache.org/jira/browse/TOMAHAWK-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631673#action_12631673
]
Simon Kitching commented on TOMAHAWK-1170:
------------------------------------------
Kennard's problem is simply that the advice on the referenced RichFaces site is
wrong. They simply cannot insist on being the first filter in the list if they
create their own FacesContext wrapper directly and then the rendered page uses
tomahawk components. The ExtensionsFilter needs to be first in this case.
Please report this as a bug in the RichFaces documentation.
Leonardo, I do think that there is a bug in the new tomahawk extensions code
though. IMO, the TomahawkFacesContextWrapper should set the flag that the
AddResourceFactory is checking for. The check is really to verify that the
response is correctly wrapped, and so the flag should be set in the two places
where the response can be wrapped: (a) the filter, and (b) the custom
FacesContext.
> 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.
