Brian - I'm not sure how to test for this, did you have anything in mind?
Adam - are you familiar with the "Seam-Discs" Trinidad example? http://pmuir.bleepbleep.org.uk/2007/04/seamdiscs-jboss-seam-and-apache.html I have made a minor mod to this and can reproduce the behaviour. Cheers, Chris On 5/30/07, Brian Smith <[EMAIL PROTECTED]> wrote:
Just an off the wall guess, but this couldn't be some sort of goofy caching issue? 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 <http://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 <http://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. > > > > > > > > > > > > > > > > > > >
