Donn Aiken wrote:
Joachim --
On Mon, Mar 1, 2010 at 1:09 PM, Joachim Schrod<jsch...@acm.org> wrote:
Donn Aiken wrote:
On Mon, Mar 1, 2010 at 11:11 AM, Joachim Schrod<jsch...@acm.org> wrote:
Donn, thanks, but that doesn't quite cover my situation.
When one uses extension mapping and Facelets, the popup dialog of a basic
<tr:inputDate> does not work, it causes the error message "The
requested
resource (/CONTEXT/__ADFv__) is not available".
This is known since July 2007:
https://issues.apache.org/jira/browse/TRINIDAD-119
A patch exists since July 2008, revised in July 2009. (But I don't want
to
wait until July 2010 for the next activity. :-)
I just did a servlet mapping like this:
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/__ADFv__*</url-pattern>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
Ugly, but it seems to work fine under Tomcat.
As I wrote above, I use extension mapping, i.e., my URIs have an extension
.jsf and not a prefix /faces/. And sadly
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/__ADFv__*</url-pattern>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
doesn't work, the popup request still returns a 404 response.
(It's an interesting question why not, as this request is passed to the
MyFaces Servlet, but somehow Trinidad doesn't get a hold on it, while it
succeeds when using the filter. Really strange.)
Is it a problem to have both *.jsf and /faces configured? Another approach
I have used successfully is to fix it up with a servlet filter. But I did
use a sendRedirect to /faces/__ADFv__ url pattern rather than /__ADFv__
/faces URI requests don't ever happen in my configuration, also no
"/faces/__ADFv__". It is definitively the case that just
"/__ADFv__" (+ leading context + query string) URIs are requested
-- I traced the network traffic to check them.
Fixing with a servlet filter is the patch in JIRA issue
TRINIDAD-119 that I wrote of above. This works, maybe with minor
adaptions.
It seems I wasn't clear enough: I have a workaround, it works for
me. I don't look for a solution for my application, I want to know
about the future of that workaround -- is it the solution, will it
be an "official workaround", or will it stay as a patch in JIRA
that useres have to search for.
Thus, my question were/are:
-- Is there a real fix upcoming?
Maybe all dev work is in 2.0 and nobody cares for 1.2
any more.
-- Or shouldn't such a filter be folded in the distribution
meanwhile?
-- Or at least be mentioned in the Wiki, to save others the time
to search for that problem's workaround?
Maybe that makes it clearer.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jsch...@acm.org
Roedermark, Germany
