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 <[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

Reply via email to