Not sure, but I think we had a similar problem and apart from changing the
mapping, we had to include
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.jsp</param-value>
</context-param>
in web.xml.
HTH
On Jan 29, 2008 8:22 AM, Wolf Benz <[EMAIL PROTECTED]> wrote:
> Matthias, the JIRA enry is
> MYFACES-1794<https://issues.apache.org/jira/browse/MYFACES-1794>
> *-Wolf*
> *
> *On 28 Jan 2008, at 21:25, Matthias Wessendorf wrote:
>
> /faces/* as servlet mapping.
>
> not yet fixed in MyFaces.
>
> Is there an issue for that already in our jira ?
>
> On Jan 28, 2008 8:50 PM, Wolf Benz <[EMAIL PROTECTED]> wrote:
>
>
> Hi List,
>
>
> I'm using MF 1.2.2 + Trinidad 1.2.5 and Facelets.
>
> And still getting this "The requested resource (/tutoring/__ADFv__.jsp) is
>
> not available" (see conversation below) message when using tr:inputDate
>
>
> Is there a way to remedy from this bug until it has been corrected in
> the(MF
>
> core) distributions?
>
> & I thought it was planned to be corrected in MF Core 1.2.1, what happened
>
> to that version? :-)
>
>
> --Wolf
>
>
>
>
>
> On 23 Sep 2007, at 15:40, Gregg Leichtman wrote:
>
>
> I'm getting a 404 error as follows:
>
> HTTP Status 404 - /tutoring/__ADFv__.jsp
>
> ________________________________
>
> type Status report
>
> message /tutoring/__ADFv__.jsp
>
> description The requested resource (/tutoring/__ADFv__.jsp) is not
>
> available.
>
> ________________________________
>
> Apache Tomcat/6.0.13
>
> whenever I try to select the popup of an inputColor or inputDate component
>
> _without_ a supporting chooseColor or chooseDate component respectively.
> If
>
> I use a supporting chooseColor or chooseDate component all is well. I
> found
>
> the following forum conversation below from the 12th of this month and it
>
> might apply, but unlike Mr. Bertrand, I have no evidence that the
>
> __ADFv__.jsp file has been generated. I did a "find" from the top of my
>
> deployed Tomcat 6.0.13 distribution and there just doesn't seem to be any
>
> such jsp or class file anywhere. In fact there is no file whose name
>
> contains "ADF". The components themselves do render, just the popups
> fail.
>
>
> I have not tried to change the faces mapping as described below, since the
>
> resource doesn't seem to be generated and there would be nothing to link
> to.
>
>
> I'm using the following:
>
>
> INFO: Initializing Sun's JavaServer Faces implementation (1.2_04-b16-p02)
>
> for context '/tutoring'
>
> Trinidad 1.2.1
>
> Tiles 2.0.4
>
> Shale snapshot 1.1.0 from 20070717
>
> [EMAIL PROTECTED]:~> uname -a
>
> Linux aragorn 2.6.11.4-21.13-default #1 Mon Jul 17 09:21:59 UTC 2006 i686
>
> i686 i386 GNU/Linux
>
>
> Here is a snippet of the jsp file:
>
>
> ...
>
> <tr:panelGroupLayout layout="horizontal">
>
> <tr:inputColor shortDesc="Set color of new message."
>
> columns="6" value="#{list.newMessageColor}">
>
> <f:facet name="help">
>
> <tr:outputText value="(#RRGGBB) or (r,g,b)"/>
>
> </f:facet>
>
> </tr:inputColor>
>
> <tr:inputDate id="insertDate" columns="8" maximumLength="8"
>
> shortDesc="Insert a date into a new message at the cursor."/>
>
> </tr:panelGroupLayout>
>
> ...
>
>
> Any help would be appreciated.
>
>
> -=> Gregg
>
> <=-
>
> Yeah, that sounds like the issue. Older versions of the RI,as well as
>
> MyFaces 1.2 don't support *.faces mappings well
>
> enough for this scenario (I haven't looked into why).
>
>
> -- Adam
>
>
>
> On 9/12/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
>
>
> Is it possible, that you are
>
> using myfaces 1.2 ?
>
>
> and *.faces mapping ?
>
> try, /faces/* as your mapping
>
>
> On 9/12/07, Bertrand, Shawn R <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> Thanks for the clarification.
>
>
>
>
> Unfortunately, it isn't working in Trinidad as it did in ADF Faces.
>
> FredJSP.getRedirectURL generates a baseURL of
>
> "/nas/__ADFv__.faces?_afPfm=497604ee&_t=fred" and arguments
>
> of {"_vir", "/jsp/SnmpSsMacDetail.jsp", "loc", "en-US", "_minWidth",
>
> "_minHeight",}. The second argument is correct and that resource is
>
> definitely present in the deployed application.
>
>
>
>
> The separate browser window does appear as it used to but it contains an
>
> HTTP 404 error with the description "The requested resource
>
> (/__ADFv__.jsp)
>
> is not available.".
>
>
>
>
> Thanks again,
>
>
>
>
> Shawn Bertrand
>
>
> Tyco Electronics Corporation
>
>
>
>
>
>
> ________________________________
>
>
>
> From: Adam Winer [EMAIL PROTECTED]
>
> Sent: Tuesday, September 11, 2007 4:32 PM
>
> To: MyFaces Discussion
>
> Subject: Re: Dialog issue during ADF->Trinidad migration
>
>
>
>
>
> There's two separate flags here:
>
>
> - useWindow
>
> - usePopup
>
>
> If useWindow is false, that means we navigate the whole page
>
> to the dialog. Simple enough.
>
>
> If useWindow is true, then we look at usePopup: if it's false,
>
> we want to show the dialog in a new browser window.
>
> We use FredJSP so that we have a frameset around the
>
> dialog view, needed to make sure that context is not lost
>
> when you navigate within the dialog.
>
>
> If usePopup is true, we use a DHTML dialog. We don't
>
> need FredJSP, since we're putting the dialog in an iframe,
>
> and can directly navigate to the page.
>
>
> Does this make sense?
>
>
> What you're describing - " uses the URL returned from FredJSP.
>
> getRedirectURL" - is intentional (and was the way things
>
> worked back in ADF, FWIW). What should be happening next
>
> is that a frameset gets generated where the frame's source
>
> is the URL of the desired page - so your dialog does show up.
>
> Is that not working?
>
>
> -- Adam
>
>
>
>
>
> On 9/11/07, Bertrand, Shawn R <
>
> [EMAIL PROTECTED]> wrote:
>
>
>
>
> (Trinidad 1.0.2 – build from July – the current one).
>
>
>
>
> I've migrated our application to use Trinidad, and see some PPR issues
>
> that
>
> are likely ours, but for the most part everything is working as
>
> expected.
>
> Except….
>
>
>
>
> We use the dialog framework extensively, and every time we attempt to
>
> display one a popup appears but uses the URL returned from
>
> FredJSP.getRedirectURL. This happens because the code in CoreRenderKit,
>
> when constructing a DialogRequest object, calls usePopupForDialog to
>
> determine if the popup is supported. Why wouldn't the passed-in
>
> usePopup
>
> setting be used? Fortunately for me (at least for now), I added the
>
> "org.apache.myfaces.trinidadinternal.renderkit.USE_DIALOG_POPUP"
>
> context parameter to my web.xml and popups are now appearing (though
>
> they
>
> appear in a dhtml-looking layer instead of the traditional popup dialog
>
> (probably a good thing).
>
>
>
>
> Note: the Trinidad demo doesn't seem to need this context parameter to
>
> display dialogs.
>
>
>
>
> Thanks in advance,
>
>
>
>
> Shawn Bertrand
>
>
> Tyco Electronics Corporation
>
>
>
>
>
> --
>
> Matthias Wessendorf
>
>
> further stuff:
>
> blog: http://matthiaswessendorf.wordpress.com/
>
> mail: matzew-at-apache-dot-org
>
>
>
>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
>
>
