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" <[EMAIL PROTECTED]> > > 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]
