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 2007/12/27 19:23:33 UTC
Re: Dialog issue during ADF->Trinidad migration
Not here... it's still failing although I have a /faces/* mapping
My setup is:
MyFaces Core & Impl 1.2.0 -- Toma -- Trini 1.2.4 -- facelets
I read(google) it is bound to the Core JSF implementation and that it
was recently corrected in Sun's own RI.
--> does someone know whether it has already been corrected in the MF
Core 1.2.1 implementation?
Speaking of: while trying to acquire the latest jar from the Apache
trunk "http://svn.apache.org/repos/asf/myfaces/core/trunk_1.2.x", when
trying to mvn(almost any target), I always get this error:
java.lang.NoSuchMethodError:
org.codehaus.plexus.util.FileUtils.copyFile(Ljava/io/File;Ljava/io/
File;Ljava/lang/String;[Lorg/codehaus/plexus/util/FileUtils
$FilterWrapper;)
It seems smth is wrongly referenced/forgotten.
Google told me it was an (Apache) config error.
As it's still pending, I was wondering: how do other people get this
jar? (ideas?) I can hardly imagine I'm the only one trying this ;-)
--Wolf
On 12 Sep 2007, at 21:46, Bertrand, Shawn R wrote:
> Thanks, fellas. We did indeed have a *.faces mapping. We now use /
> faces and all is well!
>
> All the best,
>
> Shawn
>
>
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Wednesday, September 12, 2007 2:06 PM
> To: MyFaces Discussion
> Subject: Re: Dialog issue during ADF->Trinidad migration
>
> 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 <ma...@apache.org> 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 <sh...@tycoelectronics.com>
> 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 [mailto:awiner@gmail.com]
> > 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 <
> > shawn.bertrand@tycoelectronics.com> 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: Dialog issue during ADF->Trinidad migration
Posted by Wolf Benz <eu...@gmail.com>.
Oops. Hope you had a backup.
Are the plexus guys aware of it/even better: remedying it?
Or is this adressed by the latest M2 2.0.8 version?
I'm afraid not: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13139&styleName=Text&projectId=10500&Create=Create
(don't see any mention of it)
Too bad.
Apart from this M2 problem, I posted the mail as, when using
tr:inputDate, the popup I got caused the missing adf resource error.
And to say that I migrated from Tomahawk to Trinidad just because
t:inputCalendar kept throwing me errors, grrrrr, not one working date
picker component, it's a bummer.
You have any idea whether this adf is corrected in MF Core 1.2.1?
--Wolf
On 27 Dec 2007, at 21:33, Matthias Wessendorf wrote:
> it is a plexus bug;
> I managed to fix it, when killing my m2_repo, as far as I remember
>
> -M
>
> On Dec 27, 2007 7:23 PM, Wolf Benz <eu...@gmail.com> wrote:
>> Not here... it's still failing although I have a /faces/* mapping
>>
>> My setup is:
>> MyFaces Core & Impl 1.2.0 -- Toma -- Trini 1.2.4 -- facelets
>> I read(google) it is bound to the Core JSF implementation and that
>> it was
>> recently corrected in Sun's own RI.
>> --> does someone know whether it has already been corrected in the
>> MF Core
>> 1.2.1 implementation?
>>
>> Speaking of: while trying to acquire the latest jar from the Apache
>> trunk
>> "http://svn.apache.org/repos/asf/myfaces/core/trunk_1.2.x", when
>> trying to
>> mvn(almost any target), I always get this error:
>> java.lang.NoSuchMethodError:
>> org.codehaus.plexus.util.FileUtils.copyFile(Ljava/io/File;Ljava/io/
>> File;Ljava/lang/String;[Lorg/codehaus/plexus/util/FileUtils
>> $FilterWrapper;)
>>
>> It seems smth is wrongly referenced/forgotten.
>> Google told me it was an (Apache) config error.
>> As it's still pending, I was wondering: how do other people get
>> this jar?
>> (ideas?) I can hardly imagine I'm the only one trying this ;-)
>>
>> --Wolf
>>
>>
>>
>> On 12 Sep 2007, at 21:46, Bertrand, Shawn R wrote:
>>
>>
>> Thanks, fellas. We did indeed have a *.faces mapping. We now use /
>> faces
>> and all is well!
>>
>> All the best,
>>
>> Shawn
>>
>>
>> ________________________________
>>
>> From: Adam Winer [mailto:awiner@gmail.com]
>> Sent: Wednesday, September 12, 2007 2:06 PM
>> To: MyFaces Discussion
>> Subject: Re: Dialog issue during ADF->Trinidad migration
>>
>> 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 <ma...@apache.org> 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 <sh...@tycoelectronics.com>
>> 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 [mailto:awiner@gmail.com]
>>> 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 <
>>> shawn.bertrand@tycoelectronics.com> 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: Dialog issue during ADF->Trinidad migration
Posted by Matthias Wessendorf <ma...@apache.org>.
it is a plexus bug;
I managed to fix it, when killing my m2_repo, as far as I remember
-M
On Dec 27, 2007 7:23 PM, Wolf Benz <eu...@gmail.com> wrote:
> Not here... it's still failing although I have a /faces/* mapping
>
> My setup is:
> MyFaces Core & Impl 1.2.0 -- Toma -- Trini 1.2.4 -- facelets
> I read(google) it is bound to the Core JSF implementation and that it was
> recently corrected in Sun's own RI.
> --> does someone know whether it has already been corrected in the MF Core
> 1.2.1 implementation?
>
> Speaking of: while trying to acquire the latest jar from the Apache trunk
> "http://svn.apache.org/repos/asf/myfaces/core/trunk_1.2.x", when trying to
> mvn(almost any target), I always get this error:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.util.FileUtils.copyFile(Ljava/io/File;Ljava/io/File;Ljava/lang/String;[Lorg/codehaus/plexus/util/FileUtils$FilterWrapper;)
>
> It seems smth is wrongly referenced/forgotten.
> Google told me it was an (Apache) config error.
> As it's still pending, I was wondering: how do other people get this jar?
> (ideas?) I can hardly imagine I'm the only one trying this ;-)
>
> --Wolf
>
>
>
> On 12 Sep 2007, at 21:46, Bertrand, Shawn R wrote:
>
>
> Thanks, fellas. We did indeed have a *.faces mapping. We now use /faces
> and all is well!
>
> All the best,
>
> Shawn
>
>
> ________________________________
>
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Wednesday, September 12, 2007 2:06 PM
> To: MyFaces Discussion
> Subject: Re: Dialog issue during ADF->Trinidad migration
>
> 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 <ma...@apache.org> 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 <sh...@tycoelectronics.com> 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 [mailto:awiner@gmail.com]
> > 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 <
> > shawn.bertrand@tycoelectronics.com> 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