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:[EMAIL PROTECTED]
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 <[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 [mailto:[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


Reply via email to