On 12/21/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
Whatever you want to call it, the managed bean class *must* be instantiated. Consider the text from Section 2.2.1 of the JSF Specification:
For each component in the component tree,
determine if a ValueBinding for "binding" is
present. If so, call the setValue() method on
this value binding, passing the component
instance on which it was found.
Calling setValue() on a ValueBinding *must*, as required by the spec, invoke the standard managed beans mechanisms to create a bean if it does not yet exist. Therefore, any class referenced by a binding _expression_ *must* have a public, zero-args constructor in order for this to be possibe.
Yep, although we'll likely need snippets of the source JSP and Java code too.
Craig McClanahan wrote:
> On 12/21/05, *Simon Kitching* <[EMAIL PROTECTED]
> Tonio Caputo wrote:
> > Hi,
> >
> > I'm having a big problem trying to use MyFaces.
> >
> > I have an application running with Java reference implementation
> > all works ok.
> >
> > When I try to use it with MyFaces I'm getting this problem:
> >
> > javax.servlet.ServletException:
> > Could not restore StateHolder of type
> > com.avivacanada.pampa.util.jsf.BasePageBean$1
> > (missing no-args constructor?)
> >
> > Of course BasePageBean$1 is an anonymous class, no constructor in
> > it.
> >
> >
> > I will describe you some characteristics of my application
> > that could help (of course if you need the source no problem)
> >
> > Every jsp has a java class java-page associated with it.
> > They all extend BasePageBean, all components in the
> > jsp are bound to a corresponding one in the java class.
> >
> > BasePageBean has a CommandButton common to all pages
> > and it adds a listener to this command-button, this
> > is the anonymous class that gives the problem.
> >
> > Any help will be welcomed
> > thank you in advance
> >
>
> First thing that strikes me: why is the "restore view" process
> trying to
> restore an instance of a backing bean? Restore view only restores the
> UIViewRoot and its components, not backing beans.
>
>
> Well, that depends on the circumstances ...
>
> If you use the "binding" attribute on your component, to bind the
> component instance to a backing bean instance:
>
> <h:outputText ... binding="#{mybean.myOutputTextComponent }" .../>
>
> then you will have to be restoring the backing bean instance (if it is
> in request scope, or if it doesn't exist already) as part of the Restore
> View phase.
I was using the term "restore" as in "deserialize from previously stored
view state".
As you say, when a component has a binding to a managed bean, then when
the UIComponent has its state restored, it tries to assign the newly
restored component to the specified binding property. If the target
managed bean doesn't yet exist, then a new instance of that bean will
indeed be recreated (though I wouldn't call that "restored" myself, as
the managed bean's state isn't restored).
Whatever you want to call it, the managed bean class *must* be instantiated. Consider the text from Section 2.2.1 of the JSF Specification:
For each component in the component tree,
determine if a ValueBinding for "binding" is
present. If so, call the setValue() method on
this value binding, passing the component
instance on which it was found.
Calling setValue() on a ValueBinding *must*, as required by the spec, invoke the standard managed beans mechanisms to create a bean if it does not yet exist. Therefore, any class referenced by a binding _expression_ *must* have a public, zero-args constructor in order for this to be possibe.
A bad managed bean config entry (pointing to a class that has no default
constructor) would indeed cause a failure. However the exception message
above suggests to me that the StateManager is trying to recreate the
problem class rather than the VariableResolver/ManagedBeanManager.
However once Tonio posts the full exception it should be possible to
check...
Yep, although we'll likely need snippets of the source JSP and Java code too.
Regards,
Simon
Craig
