I was just thinking of the USE_APPLICATION_VIEW_CACHE context parameter in web.xml. This can cache view state and the Trinidad Dev guide says it can cause some unexpected behavior in rare cases. Make sure you have this set to False (good for development anyway).
I am currently having trouble migrating to JBoss 4.2 as well. It seems that Ajax4JSF is causing me some trouble. It is now required to be part of a Seam Project in JBoss 4.2 (The seam filter installs the A4J filter automatically). If you have any thoughts on this I would appreciate it. http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109711 On 5/30/07, Chris Lowe <[EMAIL PROTECTED]> wrote:
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. > > > > > > > > > > > > > > > > > > > > > > > > > > >
