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.
> > > > >
> > > >
> > >
> > >
> >
>
>
