FAQ

On 9/23/07, 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.
That logic aside, try changing the faces mapping as described below.
It's precisely *because* the resource isn't generated that you run into
this problem. It's handled entirely from code.

-- Adam

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
gsl@aragorn:~> 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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 7 | next ›
Discussion Overview
groupusers @
categoriesmyfaces
postedSep 23, '07 at 1:39p
activeJan 29, '08 at 7:35a
posts7
users5
websitemyfaces.apache.org

People

Translate

site design / logo © 2019 Grokbase