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 <[EMAIL PROTECTED]> 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:[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 > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
