Hi, It looks a lot like the issue I had recently using MyFaces in JSP (not Facelet) environment with jsp:include. Are you using jsp:include or foreach maybe? The issue is http://issues.apache.org/jira/browse/MYFACES-1834
Regards, ~ Simon On Tue, Apr 14, 2009 at 4:27 PM, Developer <[email protected]> wrote: > Hi Matthias, > > I was thinking of testing with the Sun Implementation but I do not think I > will get around to it given the time I have already spent on this. As you > can see, I have do not have *exact* reproduction steps and I do not like > opening bugs with ambiguous content. > > However, just in case, could you please point me to the instructions > regarding on how to open a bug? > > Thanks, > Nick > > ----- Original Message ----- From: "Matthias Wessendorf" < > [email protected]> > To: "MyFaces Discussion" <[email protected]> > Sent: Tuesday, April 14, 2009 3:54 PM > Subject: Re: Fw: Trinidad 1.2 PPR completely broken due to serious core > issue > > > > Hi, > > two quick questions, as I haven't gone over the code yet...: > -does it work with the SUN RI ?If so, this is a bug in MYFACES core > -can you file a bug ticket, on our jira server ? > (when it works with the RI, file it against MYFACES otherwise against > TRINIDAD) > > -Matthias > > On Sun, Apr 12, 2009 at 9:20 PM, Developer <[email protected]> > wrote: > >> Hi all, >> >> Trinidad 1.2.11 is utterly broken (at least in this assumedly common >> setup) >> because it overwrites certain IDs by appending "j_id_1" to them. This >> breaks >> the PPR, which used to work impecably in Oracle ADF. >> >> After more than 10 hours of investigation (!), by looking inside the >> Trinidad 1.2.11 source code and a lot of debugging and googling (where a >> similar issue is also reported, but unaddressed), I migrated to Trinidad >> 1.0.10, which works correctly on *exactly* the same setup, by not >> obliterating my IDs. >> >> So here is my setup (I will not paste my entire project, because it is >> irrelevant, I am sure this is very easily reproduced by performing a >> similar >> setup): >> >> Trinidad 1.2.11 over MyFaces-Core 1.2.6 >> Jetty 6.1.15 >> One JSPX page using JSP 2.0 >> One TAGX tag file, using JSP 2.0, which includes by means of jsp:doBody >> some >> content from the JSPX page >> Four or five levels of tr:panelGroupLayout, which include some >> tr:inputText >> and tr:selectOneChoice components with given IDs >> partialTriggers between some of the tr:panelGroupLayout components, which >> reference the same IDs I explicitly set >> There are *no* subviews or any other naming containers outside the >> toplevel >> f:view >> >> Surprisingly, when the number of panelGroupLayout levels varies, the PPR >> stops working with a message complaining about "cannot find component by >> ID...". Because what Trinidad 1.2 actually does is when it thinks a >> certain >> component renders its children repeatedly, e.g. tr:forEach, it starts >> appending "j_id_1", "j_id_2" a.s.o. to the given child ID. Which makes >> sense >> for a tr:forEach and maybe for some f:facet components, but not for a >> tr:panelGroupLayout component. >> >> Looking at the Trinidad 1.2 source code it appears that it has some sort >> of >> algorithm for determining which component acts as a tr:forEach type of >> component, and if that is the case it starts appending the horrible >> "j_id_1" >> after any ID given to a child component. >> >> So basically if I set the partialTriggers to use the ID followed by >> "j_id_1" >> everything works fine. There is no telling when this ID clobbering takes >> place, but it may have something to do with nested tr:panelGroupLayout >> and/or the fact that I am using a TAGX tag file. >> >> I thought it was worth sharing this, since from my perspective it makes >> Trinindad 1.2 useless. I switched back to Trinidad 1.0 and everything >> works >> just fine. Quite disappointing though -- this should have been much better >> tested. >> >> Of course, I can provide any details if the Trinidad developers are >> interested in fixing this issue. >> >> Thanks, >> Nick >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > >
