You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Chris Lowe <ch...@gmail.com> on 2007/05/30 11:28:07 UTC
Strange Trinidad behaviour after upgrading to JBoss 4.2.0
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.
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
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 <ch...@gmail.com> wrote:
>
> If I set CACHE_VIEW_ROOT to false the problem goes away.
>
>
> On 5/31/07, Chris Lowe <chris.lowe.trinidad@gmail.com > 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 <ch...@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> wrote:
> > > > > Is there anything I can do to help narrow this down?
> > > > >
> > > > >
> > > > >
> > > > > On 5/30/07, Adam Winer < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com > 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com >
> > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
If I set CACHE_VIEW_ROOT to false the problem goes away.
On 5/31/07, Chris Lowe <ch...@gmail.com> 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 <ch...@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> wrote:
> > > > Is there anything I can do to help narrow this down?
> > > >
> > > >
> > > >
> > > > On 5/30/07, Adam Winer < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com > 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com >
> > > 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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
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 <ch...@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> wrote:
> > > Is there anything I can do to help narrow this down?
> > >
> > >
> > >
> > > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com > 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com > 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.
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
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 <aw...@gmail.com> 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 <ch...@gmail.com> wrote:
> > Is there anything I can do to help narrow this down?
> >
> >
> >
> > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Adam Winer <aw...@gmail.com>.
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 <ch...@gmail.com> wrote:
> Is there anything I can do to help narrow this down?
>
>
>
> On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
I tried with USE_APPLICATION_VIEW_CACHE=false, but it made no difference.
On 5/30/07, Brian Smith <un...@gmail.com> wrote:
>
> Yeah I just saw that, I am trying to reproduce your error now.
>
> BTW, I get the same error
>
> java.lang.IndexOutOfBoundsException: Index: 4,Size: 4
>
> when running the example.
>
> -Brian
>
> On 5/30/07, Chris Lowe <ch...@gmail.com> wrote:
> >
> > I also have an entry on the JBoss forum:
> >
> > http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049845#4049845
> >
> >
> > My post has details of a repro case based on some minor mods to the
> > Seam-Discs example.
> >
> > Cheers,
> >
> > C.
> >
> >
> > On 5/30/07, Chris Lowe <chris.lowe.trinidad@gmail.com > wrote:
> > >
> > > LOL - I'd already replied to that! I'll give your suggestion a try
> > > and shall take a fresh look at your post...
> > >
> > > Cheers,
> > >
> > > Chris.
> > >
> > > (aka lowecg2004)
> > >
> > >
> > > On 5/30/07, Brian Smith <unobriani@gmail.com > wrote:
> > > >
> > > > 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 <chris.lowe.trinidad@gmail.com > 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 <unobriani@gmail.com > wrote:
> > > > > >
> > > > > > Just an off the wall guess, but this couldn't be some sort of
> > > > > > goofy caching issue?
> > > > > >
> > > > > > On 5/30/07, Chris Lowe < chris.lowe.trinidad@gmail.com > wrote:
> > > > > > >
> > > > > > > Is there anything I can do to help narrow this down?
> > > > > > >
> > > > > > > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com>
> > > > > > > > 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 < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com>
> > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Brian Smith <un...@gmail.com>.
Yeah I just saw that, I am trying to reproduce your error now.
BTW, I get the same error
java.lang.IndexOutOfBoundsException: Index: 4,Size: 4
when running the example.
-Brian
On 5/30/07, Chris Lowe <ch...@gmail.com> wrote:
>
> I also have an entry on the JBoss forum:
>
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049845#4049845
>
> My post has details of a repro case based on some minor mods to the
> Seam-Discs example.
>
> Cheers,
>
> C.
>
>
> On 5/30/07, Chris Lowe <ch...@gmail.com> wrote:
> >
> > LOL - I'd already replied to that! I'll give your suggestion a try and
> > shall take a fresh look at your post...
> >
> > Cheers,
> >
> > Chris.
> >
> > (aka lowecg2004)
> >
> >
> > On 5/30/07, Brian Smith <unobriani@gmail.com > wrote:
> > >
> > > 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 <chris.lowe.trinidad@gmail.com > 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 <unobriani@gmail.com > wrote:
> > > > >
> > > > > Just an off the wall guess, but this couldn't be some sort of
> > > > > goofy caching issue?
> > > > >
> > > > > On 5/30/07, Chris Lowe < chris.lowe.trinidad@gmail.com > wrote:
> > > > > >
> > > > > > Is there anything I can do to help narrow this down?
> > > > > >
> > > > > > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com>
> > > > > > > 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.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
I also have an entry on the JBoss forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4049845#4049845
My post has details of a repro case based on some minor mods to the
Seam-Discs example.
Cheers,
C.
On 5/30/07, Chris Lowe <ch...@gmail.com> wrote:
>
> LOL - I'd already replied to that! I'll give your suggestion a try and
> shall take a fresh look at your post...
>
> Cheers,
>
> Chris.
>
> (aka lowecg2004)
>
>
> On 5/30/07, Brian Smith <un...@gmail.com> wrote:
> >
> > 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 <chris.lowe.trinidad@gmail.com > 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 <unobriani@gmail.com > wrote:
> > > >
> > > > Just an off the wall guess, but this couldn't be some sort of goofy
> > > > caching issue?
> > > >
> > > > On 5/30/07, Chris Lowe < chris.lowe.trinidad@gmail.com > wrote:
> > > > >
> > > > > Is there anything I can do to help narrow this down?
> > > > >
> > > > > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com>
> > > > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Brian Smith <un...@gmail.com>.
LOL, I guess I don't pay attention to who is replying sometimes. Thanks
On 5/30/07, Chris Lowe <ch...@gmail.com> wrote:
>
> LOL - I'd already replied to that! I'll give your suggestion a try and
> shall take a fresh look at your post...
>
> Cheers,
>
> Chris.
>
> (aka lowecg2004)
>
>
> On 5/30/07, Brian Smith <un...@gmail.com> wrote:
> >
> > 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 <chris.lowe.trinidad@gmail.com > 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 <unobriani@gmail.com > wrote:
> > > >
> > > > Just an off the wall guess, but this couldn't be some sort of goofy
> > > > caching issue?
> > > >
> > > > On 5/30/07, Chris Lowe < chris.lowe.trinidad@gmail.com > wrote:
> > > > >
> > > > > Is there anything I can do to help narrow this down?
> > > > >
> > > > > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com>
> > > > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
LOL - I'd already replied to that! I'll give your suggestion a try and
shall take a fresh look at your post...
Cheers,
Chris.
(aka lowecg2004)
On 5/30/07, Brian Smith <un...@gmail.com> wrote:
>
> 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 <ch...@gmail.com> 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 <unobriani@gmail.com > wrote:
> > >
> > > Just an off the wall guess, but this couldn't be some sort of goofy
> > > caching issue?
> > >
> > > On 5/30/07, Chris Lowe < chris.lowe.trinidad@gmail.com > wrote:
> > > >
> > > > Is there anything I can do to help narrow this down?
> > > >
> > > > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Brian Smith <un...@gmail.com>.
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 <ch...@gmail.com> 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 <un...@gmail.com> wrote:
> >
> > Just an off the wall guess, but this couldn't be some sort of goofy
> > caching issue?
> >
> > On 5/30/07, Chris Lowe < chris.lowe.trinidad@gmail.com > wrote:
> > >
> > > Is there anything I can do to help narrow this down?
> > >
> > > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 < awiner@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
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 <un...@gmail.com> wrote:
>
> Just an off the wall guess, but this couldn't be some sort of goofy
> caching issue?
>
> On 5/30/07, Chris Lowe < chris.lowe.trinidad@gmail.com> wrote:
> >
> > Is there anything I can do to help narrow this down?
> >
> > On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Brian Smith <un...@gmail.com>.
Just an off the wall guess, but this couldn't be some sort of goofy caching
issue?
On 5/30/07, Chris Lowe <ch...@gmail.com> wrote:
>
> Is there anything I can do to help narrow this down?
>
> On 5/30/07, Adam Winer <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
Is there anything I can do to help narrow this down?
On 5/30/07, Adam Winer <aw...@gmail.com> 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 <ch...@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > > >
> > >
> >
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Adam Winer <aw...@gmail.com>.
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 <ch...@gmail.com> 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 <aw...@gmail.com> 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 < chris.lowe.trinidad@gmail.com> 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.
> > >
> >
>
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Chris Lowe <ch...@gmail.com>.
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 <aw...@gmail.com> 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 <ch...@gmail.com> 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.
> >
>
Re: Strange Trinidad behaviour after upgrading to JBoss 4.2.0
Posted by Adam Winer <aw...@gmail.com>.
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 <ch...@gmail.com> 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.
>