>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]
>
