Hi Adam, I'm having difficulty running the latest version of Seam under glassfish:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4050702 Is there a simple Trinidad 1.2 project that I can download for Eclipse? I can start with that and add Ajax4Jsf then Seam. Cheers, Chris. On 5/31/07, Chris Lowe <[EMAIL PROTECTED]> wrote:
If I set CACHE_VIEW_ROOT to false the problem goes away. On 5/31/07, Chris Lowe <[EMAIL PROTECTED] > wrote: > > I take it back - it's now even stranger! > > First click that fires validation works. Click again and the > duplication starts happening as before. > > On 5/31/07, Chris Lowe <[EMAIL PROTECTED]> wrote: > > > > I've just done an update to my environment: > > > > Update to latest Ajax4Jsf snapshot from http://maven.exadel.com/org/ajax4jsf/ajax4jsf/ > > > > Update to latest Seam snapshot (CVS) and reconfigured filters in-line > > with new version (many of the Seam filters + Ajax4Jsf have been rolled into > > one); > > Changed ALTERNATE_VIEW_HANDLER from: > > > > <context-param> > > <param-name>org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER > > </param-name> > > <param-value>org.jboss.seam.ui.facelet.SeamFaceletViewHandler > > </param-value> > > </context-param> > > > > To > > > > <context-param> > > <param-name>org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER > > </param-name> > > <param-value>com.sun.facelets.FaceletViewHandler</param-value> > > > > </context-param> > > > > USE_APPLICATION_VIEW_CACHE and CACHE_VIEW_ROOT are both true. > > > > My app now does not exhibit the duplication problems. > > > > That was a strange one! > > > > On 5/31/07, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > Well, we've got a lot of variables here. It's a little > > > suspicious to me hearing that an Ajax4JSF filter is > > > now required, when this behavior doesn't appear to > > > be reproducing for other users of Trinidad 1.2. > > > > > > I'd try, for example, the same page without Ajax4JSF > > > installed - if that means taking Seam out of the picture > > > for that one page, OK. > > > > > > I'd also try deploying the same app to Glassfish - > > > if it reproduces there, then we know it's not JBoss > > > specific. > > > > > > BTW, USE_APPLICATION_VIEW_CACHE=false > > > is the default, so setting that won't change anything. > > > Another random thing to try is setting > > > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT > > > to false. That will be a change from the default. > > > It throws away an extremely valuable optimization, > > > but it also might help point out where things are going > > > wrong. > > > > > > -- Adam > > > > > > > > > On 5/30/07, Chris Lowe < [EMAIL PROTECTED]> wrote: > > > > Is there anything I can do to help narrow this down? > > > > > > > > > > > > > > > > On 5/30/07, Adam Winer < [EMAIL PROTECTED]> wrote: > > > > > Hrm, that looks like the same version as Glassfish! I > > > > > didn't know they were using the RI. So scrap that theory! > > > > > It still *might* be something wrong in JBoss (maybe their > > > > > implementation of JspIdConsumer in the JSP engine?), > > > > > but this is more puzzling. > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > On 5/30/07, Chris Lowe < [EMAIL PROTECTED] > wrote: > > > > > > Thanks for the reply Adam. > > > > > > > > > > > > Do you happen to know what version of JSF Glassfish is using? > > > > > > > > > > > > From jsf-api.jar that is with JBoss 4.2.0.GA, the manifest > > > states: > > > > > > > > > > > > Manifest-Version: 1.0 > > > > > > Specification-Title: JavaServer Faces > > > > > > Created-By: 1.5.0_04-b05 (Sun Microsystems Inc.) > > > > > > Ant-Version: Apache Ant 1.6.5 > > > > > > Implementation-Title: Sun Microsystems JavaServer Faces > > > Implementation > > > > > > Specification-Vendor: JBoss ( http://www.jboss.org/ ) > > > > > > Specification-Version: 1.2MR1 > > > > > > Implementation-Vendor-Id: com.sun > > > > > > Extension-Name: javax.faces > > > > > > Implementation-Version: 1.2_04-b10-p01 > > > > > > Implementation-Vendor: Sun Microsystems, Inc. > > > > > > Implementation-URL: http://www.jboss.org/ > > > > > > Cheers, > > > > > > > > > > > > Chris. > > > > > > > > > > > > > > > > > > > > > > > > On 5/30/07, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > > I suspect that there's something wrong with > > > > > > > the implementation of JSF 1.2 used by JBoss, probably > > > > > > > in that implementation's UIComponentClassicTagBase > > > > > > > code or something similar. The behavior you're describing > > > > > > > doesn't occur with Glassfish. > > > > > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > > > > > > > On 5/30/07, Chris Lowe < [EMAIL PROTECTED] > > > > wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > I have a project that is running Trinidad and I recently > > > upgraded to > > > > > > JBoss > > > > > > > > 4.2.0.GA. As part of this upgrade I also migrated to JSF > > > 1.2 (the > > > > > > latest > > > > > > > > Seam version requires me to do this). Ever since then, > > > whenever I > > > > > > submit a > > > > > > > > form that fails validation, the form renders the correct > > > validation > > > > > > messages > > > > > > > > but I get some weird rendering of the form. It's actually > > > like the > > > > > > previous > > > > > > > > HTML doesn't get cleared and the new form + validation > > > errors gets > > > > > > tacked > > > > > > > > onto the end - I'm literally seeing double. If I click my > > > submit > > > > button > > > > > > > > again, then a third instance will be tacked onto the > > > bottom, and so > > > > on. > > > > > > If > > > > > > > > at this point I simply refresh the page, then everything > > > resets back > > > > to > > > > > > > > normal. If I use the application without causing > > > validation errors > > > > then > > > > > > > > everything works as normal. I get the same behaviour on > > > FireFox and > > > > IE > > > > > > and > > > > > > > > there are no exceptions in the logs. > > > > > > > > > > > > > > > > I tried updating the Trinidad build to > > > > > > trinidad-*-1.2-07-may-SNAPSHOT.jar , > > > > > > > > but to no avail. > > > > > > > > > > > > > > > > I eventually tracked the strange behaviour down to my > > > usage of > > > > > > <trh:body>, > > > > > > > > if I use a vanilla body tag then the page duplication > > > problem goes. > > > > > > > > However, I still get similar issues with <tr:commandLink> > > > - the > > > > instance > > > > > > of > > > > > > > > the link is duplicated with each form submission that > > > causes a > > > > > > validation > > > > > > > > error. Changing to <h:commandLink> again, resolves this > > > issue. > > > > > > > > > > > > > > > > Has anyone come across this before? > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Chris. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
