You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Wolf Benz <eu...@gmail.com> on 2008/01/28 20:50:38 UTC
Re: Trinidad 404 error: requested resource (/tutoring/__ADFv__.jsp) is not available
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
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
Re: Trinidad 404 error: requested resource (/tutoring/__ADFv__.jsp) is not available
Posted by Wolf Benz <eu...@gmail.com>.
Hi Matthias,
I read this reply (of your part as well, if I remember correctly!)
already, but this doesn't help. (I have it already configured this way)
But I read for some people it does help. perhaps for me not as I'm
also using facelets, donno.
--> Any other idea to remedy?
Oh, and for your other question: the first time I encoutered it, I
made a JIRA entry (was at the time of 1.2.0 I believe) but it hasn't
been corrected since.
I also remember Simon Kitching had a brief look at it, but it's not
solved yet.
Kind Regards,
--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 <eu...@gmail.com> 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
>> 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
>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
Re: Trinidad 404 error: requested resource (/tutoring/__ADFv__.jsp) is not available
Posted by Rafa Pérez <ra...@gmail.com>.
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 <eu...@gmail.com> 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 <eu...@gmail.com> 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
>
> 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
>
>
>
>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
>
>
Re: Trinidad 404 error: requested resource (/tutoring/__ADFv__.jsp) is not available
Posted by Wolf Benz <eu...@gmail.com>.
Matthias, the JIRA enry is 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 <eu...@gmail.com> 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
>> 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
>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
Re: Trinidad 404 error: requested resource (/tutoring/__ADFv__.jsp) is not available
Posted by Matthias Wessendorf <ma...@apache.org>.
/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 <eu...@gmail.com> 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
> 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
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org