You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2004/10/27 19:26:17 UTC
Confusion over request scope
I tried an experiment where I set the <managed-bean-scope> to request.
In my JSF page, I added a valueChangeListener attribute to a property
associated with that same bean. (The listener, however, was a
different bean with application scope.)
When I made a change and submitted I discovered that the listener
detected the field change and my debug statements showed both the old
and new values. My question is how can JSF know the old value if the
object's lifetime was only for the request???
Not that I'm complaining, because this is ultimately what I want, but
its confusing. Am I missing something here?
TIA
sean
Re: Confusion over request scope
Posted by Craig McClanahan <cr...@gmail.com>.
No, the bean still goes away at the end of the request, but the
components themselves (including their current values) are saved and
restored so that, on the following form submit, a value change event
can be sent to the (new) listener.
Craig
On Wed, 27 Oct 2004 15:09:46 -0400, Sean Schofield
<se...@gmail.com> wrote:
> Craig,
>
> You are a mailing list animal! I don't know how you find the time
> (but I'm glad you do!)
>
> I figured it was probably something the specification required (must
> have missed that in my cursory reading of the specification.)
>
> OK so let me see if I understand this. The bean is stored in the
> request and dies along with the request (as expected.) But in
> situations where the bean is referenced by the component tree, it
> lives on until the end of the next request.
>
> Now that I think about it, the component tree is repopulated after
> validation, etc. so this must be when the reference to the original
> request-scope bean dies (and is replaced with the next one.)
>
> Is that right?
>
> sean
>
Re: Confusion over request scope
Posted by Sean Schofield <se...@gmail.com>.
Craig,
You are a mailing list animal! I don't know how you find the time
(but I'm glad you do!)
I figured it was probably something the specification required (must
have missed that in my cursory reading of the specification.)
OK so let me see if I understand this. The bean is stored in the
request and dies along with the request (as expected.) But in
situations where the bean is referenced by the component tree, it
lives on until the end of the next request.
Now that I think about it, the component tree is repopulated after
validation, etc. so this must be when the reference to the original
request-scope bean dies (and is replaced with the next one.)
Is that right?
sean
Re: Any known problems using J2EE with JSF/Tiles?
Posted by Mark Lowe <me...@gmail.com>.
Some guy getting guru meditaton the other day found he had a sun jsf
jar kicking around..
Sean.
I'm not sure but I was thinking about this problem dispatching with sun's jsf.
I dont know if this would be anti portlets. But in TilesHandler rather than
externalContext.dispatch(tilesId);
could try
facesContext.getViewRoot().setViewId(tilesId);
I haven't got the set up to try it anymore, but i saw how deep you've
been trying to get this working, and so you might have an immediate
way of testing.
Mark
On Wed, 27 Oct 2004 15:11:28 -0400, Sean Schofield
<se...@gmail.com> wrote:
> Glenn,
>
> There are some issues with Tiles (and dynamic server-side includes in
> general) but this does not seem like your problem (judging by the
> stack trace.)
>
> I'm really new to Faces myself so I can't help much beyond suggesting
> that Tiles is not the cause of your problem in this case.
>
> HTH,
> sean
>
> On Wed, 27 Oct 2004 11:37:58 -0700 (PDT), Glenn Davidson
>
>
> <gb...@yahoo.com> wrote:
> >
> >
> >
> >
> >
> > I have an application that is using a large J2EE middle tier with a
> > JSF/Tiles GUI. When I began to add the J2EE parts I began getting the
> > following error when starting JBoss. Does anyone have any ideas?
> >
> > Glenn
> >
> >
> >
> > 12:51:25,390 ERROR [Engine] StandardContext[/ProgramAdministrator]Exception
> > send
> > ing context initialized event to listener instance of class
> > net.sourceforge.myfa
> > ces.webapp.StartupServletContextListener
> > java.lang.NoSuchMethodError:
> > javax.faces.FactoryFinder.getFactoryNames()Ljava/ut
> > il/Set;
> > at
> > net.sourceforge.myfaces.config.FacesConfigFactoryBase.performMetaInfF
> > actoryConfig(FacesConfigFactoryBase.java:199)
> > at
> > net.sourceforge.myfaces.config.FacesConfigFactoryBase.parseFacesConfi
> > gFiles(FacesConfigFactoryBase.java:110)
> > at
> > net.sourceforge.myfaces.config.FacesConfigFactoryBase.getFacesConfig(
> > FacesConfigFactoryBase.java:88)
> > at
> > net.sourceforge.myfaces.webapp.StartupServletContextListener.initFace
> > s(StartupServletContextListener.java:78)
> > at
> > net.sourceforge.myfaces.webapp.StartupServletContextListener.contextI
> > nitialized(StartupServletContextListener.java:60)
> > at
> > org.apache.catalina.core.StandardContext.listenerStart(StandardContex
> > t.java:3805)
> > at
> > org.apache.catalina.core.StandardContext.start(StandardContext.java:4
> > 321)
> > at
> > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
> > .java:823)
> > at
> > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80
> > 7)
> > at
> > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> > java:39)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> > sorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:324)
> > at
> > org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:
> > 503)
> > at
> > org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:1
> > ...........
> >
> > ________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Address AutoComplete - You start. We finish.
> >
> >
>
Re: Any known problems using J2EE with JSF/Tiles?
Posted by Sean Schofield <se...@gmail.com>.
Glenn,
There are some issues with Tiles (and dynamic server-side includes in
general) but this does not seem like your problem (judging by the
stack trace.)
I'm really new to Faces myself so I can't help much beyond suggesting
that Tiles is not the cause of your problem in this case.
HTH,
sean
On Wed, 27 Oct 2004 11:37:58 -0700 (PDT), Glenn Davidson
<gb...@yahoo.com> wrote:
>
>
>
>
>
> I have an application that is using a large J2EE middle tier with a
> JSF/Tiles GUI. When I began to add the J2EE parts I began getting the
> following error when starting JBoss. Does anyone have any ideas?
>
> Glenn
>
>
>
> 12:51:25,390 ERROR [Engine] StandardContext[/ProgramAdministrator]Exception
> send
> ing context initialized event to listener instance of class
> net.sourceforge.myfa
> ces.webapp.StartupServletContextListener
> java.lang.NoSuchMethodError:
> javax.faces.FactoryFinder.getFactoryNames()Ljava/ut
> il/Set;
> at
> net.sourceforge.myfaces.config.FacesConfigFactoryBase.performMetaInfF
> actoryConfig(FacesConfigFactoryBase.java:199)
> at
> net.sourceforge.myfaces.config.FacesConfigFactoryBase.parseFacesConfi
> gFiles(FacesConfigFactoryBase.java:110)
> at
> net.sourceforge.myfaces.config.FacesConfigFactoryBase.getFacesConfig(
> FacesConfigFactoryBase.java:88)
> at
> net.sourceforge.myfaces.webapp.StartupServletContextListener.initFace
> s(StartupServletContextListener.java:78)
> at
> net.sourceforge.myfaces.webapp.StartupServletContextListener.contextI
> nitialized(StartupServletContextListener.java:60)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContex
> t.java:3805)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4
> 321)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
> .java:823)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80
> 7)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at
> org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:
> 503)
> at
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:1
> ...........
>
> ________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
>
>
Any known problems using J2EE with JSF/Tiles?
Posted by Glenn Davidson <gb...@yahoo.com>.
I have an application that is using a large J2EE middle tier with a JSF/Tiles GUI. When I began to add the J2EE parts I began getting the following error when starting JBoss. Does anyone have any ideas?
Glenn
12:51:25,390 ERROR [Engine] StandardContext[/ProgramAdministrator]Exception send
ing context initialized event to listener instance of class net.sourceforge.myfa
ces.webapp.StartupServletContextListener
java.lang.NoSuchMethodError: javax.faces.FactoryFinder.getFactoryNames()Ljava/ut
il/Set;
at net.sourceforge.myfaces.config.FacesConfigFactoryBase.performMetaInfF
actoryConfig(FacesConfigFactoryBase.java:199)
at net.sourceforge.myfaces.config.FacesConfigFactoryBase.parseFacesConfi
gFiles(FacesConfigFactoryBase.java:110)
at net.sourceforge.myfaces.config.FacesConfigFactoryBase.getFacesConfig(
FacesConfigFactoryBase.java:88)
at net.sourceforge.myfaces.webapp.StartupServletContextListener.initFace
s(StartupServletContextListener.java:78)
at net.sourceforge.myfaces.webapp.StartupServletContextListener.contextI
nitialized(StartupServletContextListener.java:60)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContex
t.java:3805)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4
321)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
.java:823)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:80
7)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:
503)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:1 ...........
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
Re: Confusion over request scope
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 27 Oct 2004 13:26:17 -0400, Sean Schofield
<se...@gmail.com> wrote:
> I tried an experiment where I set the <managed-bean-scope> to request.
> In my JSF page, I added a valueChangeListener attribute to a property
> associated with that same bean. (The listener, however, was a
> different bean with application scope.)
>
> When I made a change and submitted I discovered that the listener
> detected the field change and my debug statements showed both the old
> and new values. My question is how can JSF know the old value if the
> object's lifetime was only for the request???
Simple ... it's magic :-).
> Not that I'm complaining, because this is ultimately what I want, but
> its confusing. Am I missing something here?
What's really going on is that JSF promises to save and restore the
state of the entire component tree for you, in betwen requests. You
get to set a context init parameter that requests state saving happen
either client side or server side. How it actually works is up to the
JSF implementation, but for the JSF RI those choices result in:
* client -- the component tree is serialized into a hidden variable
that is included in the subsequent form submit, and used to
restore the tree before processing the submit.
* server -- the component tree is saved in your session.
I haven't looked recently, but I think MyFaces tries to do something a
little smarter than that for client side saving.
In either case, then, the previous state of the tree is there when the
new input value is set, so the value change event can be fired as
expected.
Basically, JSF has real components, not just tags that generate HTML :-).
> TIA
>
> sean
>
Craig