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]
