Hi Well, renaming did not do the trick.
I have tried to reduce this down to something simple: I have a index.html file with only 1 line in it: <span jsfid="/index.xml"></span> Then I have a index.xml file like this: <view> <component jsfid="/index.xml" extends="baseLayout"> <symbols> <set name="managed-Bean-Name" value="index" /> <set name="bodyContent" value="/pages/indexBody.html" /> <set name="globalnav" value="/pages/globalnav-2.html" /> </symbols> </component> </view> A managed bean defined as: <managed-bean> <description>View controller for forsiden</description> <managed-bean-name>index</managed-bean-name> <managed-bean-class> com.opstvedt.osseil.viewcontrollers.IndexPage </managed-bean-class> <managed-bean-scope>request</managed-bean-scope> <managed-property> <property-name>nyhetService</property-name> <property-class> com.opstvedt.osseil.hibernate.service.NyhetService </property-class> <value>#{nyhetService}</value> </managed-property> </managed-bean> On invocation the first call to the index bean the callstack is ( Objectid for ViewViewHandler=1708593): IndexPage.<init>() line: 42 NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method] NativeConstructorAccessorImpl.newInstance(Object[]) line: 39 DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 Constructor<T>.newInstance(Object...) line: 494 Class<T>.newInstance0() line: 350 Class<T>.newInstance() line: 303 ClassUtils.newInstance(Class) line: 274 ClassUtils.newInstance(String) line: 265 ManagedBeanBuilder.buildManagedBean(FacesContext, ManagedBean) line: 49 VariableResolverImpl.resolveVariable(FacesContext, String) line: 311 ShaleVariableResolver.resolveVariable(FacesContext, String) line: 152 DelegatingVariableResolver.resolveVariable(FacesContext, String) line: 110 WebApplicationContextVariableResolver.resolveVariable(FacesContext, String) line: 87 ViewViewHandler.setupViewController(FacesContext, UIViewRoot, String, boolean) line: 235 ViewViewHandler.createView(FacesContext, String) line: 126 LifecycleImpl.restoreView(FacesContext) line: 127 LifecycleImpl.execute(FacesContext) line: 66 FacesServlet.service(ServletRequest, ServletResponse) line: 106 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 252 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 ShaleApplicationFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 285 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 202 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 OpenSessionInViewFilter.doFilterInternal(HttpServletRequest, HttpServletResponse, FilterChain) line: 174 OpenSessionInViewFilter(OncePerRequestFilter).doFilter(ServletRequest, ServletResponse, FilterChain) line: 76 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 202 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 OpenSessionInViewFilter.doFilterInternal(HttpServletRequest, HttpServletResponse, FilterChain) line: 174 OpenSessionInViewFilter(OncePerRequestFilter).doFilter(ServletRequest, ServletResponse, FilterChain) line: 76 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 202 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 StandardWrapperValve.invoke(Request, Response, ValveContext) line: 214 StandardValveContext.invokeNext(Request, Response) line: 104 StandardPipeline.invoke(Request, Response) line: 520 StandardContextValve.invokeInternal(Wrapper, Request, Response) line: 198 StandardContextValve.invoke(Request, Response, ValveContext) line: 152 StandardValveContext.invokeNext(Request, Response) line: 104 StandardPipeline.invoke(Request, Response) line: 520 StandardHostValve.invoke(Request, Response, ValveContext) line: 137 StandardValveContext.invokeNext(Request, Response) line: 104 ErrorReportValve.invoke(Request, Response, ValveContext) line: 118 StandardValveContext.invokeNext(Request, Response) line: 102 StandardPipeline.invoke(Request, Response) line: 520 StandardEngineValve.invoke(Request, Response, ValveContext) line: 109 StandardValveContext.invokeNext(Request, Response) line: 104 StandardPipeline.invoke(Request, Response) line: 520 StandardEngine(ContainerBase).invoke(Request, Response) line: 929 CoyoteAdapter.service(Request, Response) line: 160 Http11Processor.process(InputStream, OutputStream) line: 799 Http11Protocol$Http11ConnectionHandler.processConnection(TcpConnection, Object[]) line: 705 TcpWorkerThread.runIt(Object[]) line: 577 ThreadPool$ControlRunnable.run() line: 684 ThreadWithAttributes(Thread).run() line: 595 [local variables unavailable] Then the managed bean gets instantiated again, and the ViewViewHandler has the same objected. I'll check the objectid of each and every one in the callstack to see where there is a new creation of that bean. Hermod -----Opprinnelig melding----- Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] Sendt: 1. april 2006 09:21 Til: Struts Users Mailing List; [EMAIL PROTECTED] Emne: Re: SV: SV: [Shale] Backingbean beeing created twice >From: Hermod Opstvedt <[EMAIL PROTECTED]> > > Hi > > You are right. This is happening further up the stack, and as far as I have > been able to determine, it has to do with the extension mapping with faces > and Clay. So now I am trying to sort this out. > I took another look at the stack trace and it looks like it's being delegated through the PropertyResovlers. My statement about this being a function of the JSF runtime was not 100% correct :-). Are you using the shale-spring integration? It looks like the jar is there. Is the context listener added you the web.xml for spring and the applicationContext.xml in the WEB-INF? <listener> <listener-class> org.springframework.web.context.ContextLoaderListener </listener-class> </listener> You might try removing the spring libraries just to reduce the fault domain. Gary > Hermod > > -----Opprinnelig melding----- > Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] > Sendt: 1. april 2006 00:13 > Til: Struts Users Mailing List; [EMAIL PROTECTED] > Emne: Re: SV: [Shale] Backingbean beeing created twice > > >From: Hermod Opstvedt > > > > Hi > > > > I applied your patch, but my backing bean is still beeing created twice. > > > > Once in restoreView, and then again in createView > > > > What scope is you managed bean defined in? If your bean is not defined in a > scope (NONE), it will be created each time. > > This patch has more to do with invoking the "init()" and "destroy()" methods > more than once per view controller. The JSF runtime handles creating > managed beans and caching them in the correct scope. > > The view controller init() and other callback methods are invoked on a > managed bean after the JSF runtime has returned an object instance. So the > "init()" method in the view controller should not be confused with an > object's constructor. > > > > I read from you mail identifying this, that you where looking for some > > feedback from someone (Craig?). > > > > Yeah, I was wanting for Craig to take a look. This is kind of his domain > and I might not have a full picture. > > > > If anything is a showstopper, this one definitly is! > > > > Hermod > > > Gary > > > > > -----Original Message----- > > From: Hermod Opstvedt [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 31, 2006 6:52 AM > > To: 'Struts Users Mailing List' > > Subject: SV: [Shale] Backingbean beeing created twice > > > > > > Hi > > > > I'll look at the trace from the debugger for both instance creations and > > confirm this. > > > > Hermod > > > > -----Opprinnelig melding----- > > Fra: Gary VanMatre [mailto:[EMAIL PROTECTED] > > Sendt: 31. mars 2006 00:47 > > Til: Struts Users Mailing List > > Emne: Re: [Shale] Backingbean beeing created twice > > > > >From: "Craig McClanahan" > > > > > > On 3/30/06, Hermod Opstvedt wrote: > > > > > > > > Hi > > > > > > > > I am seeing some odd behaviour in my Shale/Clay application. My > > > > backingbean > > > > (ie ViewController) is being created twice, meaning I have 2 instances > > > of > > > > it. I was wondering if this is expected behaviour or if this is a bug. > > > > > From > > > > the stacktrace: > > > > > > > > > How are you locating these two instances? Printing stuff in the > > > constructor? I don't see how you could ever end up with two request > scope > > > instances under one name. > > > > > > > The called twice to the int() might be related to this bug: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=38000 > > > > The behavior on a postback when you navigate back to the same page is: > > init() - invoked from resortView() > > int() - invoked from createView() > > > > prerender() > > prerender() > > destroy() > > destroy() > > > > The destroy is called twice because the view controller is added twice to > > the > > list that the phase listener uses to callback on the prerender and > destroy. > > > > Gary > > > > > ResultatPage.() line: 71 > > > > NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) > line: > > > > not > > > > available [native method] > > > > > > > > > This exception implies that the constructor threw an exception, which > > would > > > cause the managed bean creation to fail, so no instance would ever get > > > installed in scope. Every time an expression containing this managed > bean > > > name is evaluated, it will see "aha, there's no bean yet, so try to > create > > > > > one" -- and, I would assume, every attempt will fail. But its not > > > surprising to see multiple attempts if your constructor is throwing > > > exceptions. > > > > > > If the bean is a view controller, try moving the setup logic to the > init() > > > > > method instead of the constructor. Even if an exception is still thrown, > > > > the initial attempt to create the bean will succeed, so you won't get > > > multiple failed instantiation attempts. > > > > > > Craig > > > > > > NativeConstructorAccessorImpl.newInstance(Object[]) line: 39 > > > > DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27 > > > > Constructor.newInstance(Object...) line: 494 > > > > Class.newInstance0() line: 350 > > > > Class.newInstance() line: 303 > > > > ClassUtils.newInstance(Class) line: 274 > > > > ClassUtils.newInstance(String) line: 265 > > > > ManagedBeanBuilder.buildManagedBean(FacesContext, ManagedBean) line: > 49 > > > > VariableResolverImpl.resolveVariable(FacesContext, String) line: 311 > > > > > ShaleVariableResolver.resolveVariable(FacesContext, String) line: 152 > > > > DelegatingVariableResolver.resolveVariable(FacesContext, String) line: > > 110 > > > > WebApplicationContextVariableResolver.resolveVariable(FacesContext, > > > > String) > > > > line: 87 > > > > ViewViewHandler.setupViewController(FacesContext, UIViewRoot, String, > > > > > boolean) line: 233 > > > > ViewViewHandler.restoreView(FacesContext, String) line: 160 > > > > ... > > > > > > > > > > > > Hermod > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * > > > > This email with attachments is solely for the use of the individual or > > entity to whom it is addressed. Please also be aware that the DnB NOR > Group > > cannot accept any payment orders or other legally binding correspondence > > with > > customers as a part of an email. > > > > This email message has been virus checked by the virus programs used > > in the DnB NOR Group. > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]