>From: Hermod Opstvedt <[EMAIL PROTECTED]> > > 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] >
