Yes, quite interesting indeed, but somewhat annoying as well.
That bug was orginally marked as RESOLVED for facelets 1.1.12, but it
has been reopend. In our testing last Friday we also concluded it wasn't
fixed yet. :-(
I will follow your advice and start replacing ui:repeat by t:dataList.
It's quite disappointing to find that such a great framework like
facelets still has such a huge bug.
With kind regards,
Marco
-----Original Message-----
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
Sent: donderdag 29 maart 2007 19:22
To: MyFaces Discussion
Subject: Re: [OT?] ui:repeat stops after first entry
Interesting. Someone reported something similar here:
https://facelets.dev.java.net/issues/show_bug.cgi?id=160
On 3/29/07, Beelen, Marco <[EMAIL PROTECTED]> wrote:
> Hello Mike,
>
> Thanks for your reply and your suggestions.
>
> I think I've got the problems solved, but won't be sure until some
final
> integration testing tomorrow.
>
> At appairs the weird behaviour was caused by a strange ug in the
> ui:repeat indeed, which appairs to be solved in facelets 1.1.12. Up
> until this morning I still had 1.1.11 in my project. The bug
manifested
> itself when the version of the JRE wasn't exactly the same as the
> version used to compile the facelets.jar, but it does not occur when
an
> IDE-debugger is attached to the JVM. ( Try troubleshooting that!!! ),
> which explains why in my local environment the bug didn't occur since
I
> always start my tomcat for development testing from within Eclipse.
>
>
> With kind regards,
> Marco
>
>
>
>
>
> -----Original Message-----
> From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
> Sent: woensdag 28 maart 2007 19:28
> To: MyFaces Discussion
> Subject: Re: [OT?] ui:repeat stops after first entry
>
> Some things to try:
>
> 1) Replace ui:repeat with t:dataList. There have been issues with
> ui:repeat in the past which did not happen with t:dataList.
>
> 2) Replace t:updateActionListener with f:setPropertyActionListener
> (property attribute renamed target) if you're using facelets 1.1.11
> and beyond. f:setPropertyActionListener handles some situations that
> some t:updateActionListener implementations do not when used with
> facelets (particularly ui:includes).
>
> For what it's worth, I've seen a number of "weird" bugs posted, caused
> when people have tried upgrading from 1.5 to 1.6. I avoid 1.6 at
> this time.
>
> On 3/28/07, Beelen, Marco <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Hello all,
> >
> > This post might be a bit of topic on this list, but I decided to
post
> > anyhow, since I'm quite confused about a problem I'm having at the
> moment.
> > Maybe somebody can enlighten me with some great insight. Otherwise:
> Sorry
> > for bothering you.
> >
> >
> > The problem I'm having occurs when I'm using ui:repeat (Facelets) to
> iterate
> > over a List.
> > The entries of the list contain object which have another List
nested
> within
> > them and I again use a ui:repeat to iterate over the entries in the
> nested
> > list, to create <h:inputText /> for all nested items.
> >
> > I use this constuction on several tabs,which each have a seperate
> action
> > button.
> > Using the updateActionListener I determine on which tab the user was
> when
> > submitting the form and will save only those entries on that
specific
> tab.
> >
> > The user submits each form and goes to the next tab. All goes well
> until
> > they submit the form on the final tab.
> > From that moment on just the very first entry of the first nested
list
> gets
> > rendered and more strangely: It happens only on my test and
> > production-server (Linux) and not on my development machine (WinXP).
> >
> > I downgraded my local java version to 1.5.0_11 to match the version
of
> the
> > server and made sure both machines use the same version of Tomcat
> (5.5.20),
> > but still I could not reproduce the problem locally.
> >
> > Using some logging and debugging I determined that the managed-bean
> does
> > contain more than just that signle entry.
> >
> > Initially I had java 1.6.0 on my local machine, so I tried running
the
> > application on the test-server with Java 1.6.0 and the problem did
not
> occur
> > anymore, so that appair to be the obvious solution, but it doesn't
> stop me
> > for wondering what might be the cause of this problem. ( Especially
> since an
> > upgrade to Java 6 on the server requires some additional testing of
> other
> > applications as well, which doesn't quite fit neetly within the
> planned
> > schedule. )
> >
> >
> > Any suggestions how I could further proceed with the investigationof
> this
> > problem are highly appreciated.
> >
> >
> > With kind regards,
> > Marco Beelen.
> >
> >
> >
>
------------------------------------------------------------------------
> ------
> > Notice: This e-mail message, together with any attachments,
contains
> > information of Merck & Co., Inc. (One Merck Drive, Whitehouse
> Station,
> > New Jersey, USA 08889), and/or its affiliates (which may be known
> > outside the United States as Merck Frosst, Merck Sharp & Dohme or
MSD
> > and in Japan, as Banyu - direct contact information for affiliates
is
> > available at http://www.merck.com/contact/contacts.html)
> > that may be
> > confidential, proprietary copyrighted and/or legally privileged. It
> is
> > intended solely for the use of the individual or entity named on
this
> > message. If you are not the intended recipient, and have received
> this
> > message in error, please notify us immediately by reply e-mail and
> then
> > delete it from your system.
> >
> >
>
------------------------------------------------------------------------
> ------
>
>
>
>
>
------------------------------------------------------------------------
------
> Notice: This e-mail message, together with any attachments, contains
> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
> New Jersey, USA 08889), and/or its affiliates (which may be known
> outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
> and in Japan, as Banyu - direct contact information for affiliates is
> available at http://www.merck.com/contact/contacts.html) that may be
> confidential, proprietary copyrighted and/or legally privileged. It is
> intended solely for the use of the individual or entity named on this
> message. If you are not the intended recipient, and have received this
> message in error, please notify us immediately by reply e-mail and
then
> delete it from your system.
>
>
------------------------------------------------------------------------
------
>
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
------------------------------------------------------------------------------
