You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Geoff Longo <gm...@gmail.com> on 2009/04/08 14:41:53 UTC
t:saveState and Mojarra 1.2_12
I have an application where I am trying to change the JSF implementation
from MyFaces Core 1.2.6 to Mojarra 1.2_12. I was hoping the application
could still make use of the tomahawk saveState tag, as we use it heavily
throughout the application. But it appears that the saveState tag is not
working properly with Mojarra. I have debugged the issue and have found
that the saveState and restoreState methods do get invoked, and it is able
to restore the object successfully. But when the restoreState method tries
to set the restored object through the ValueExpression, it eventually tries
to resolve the variable by calling Mojarra's
ManagedBeanELResolver.setValue() method. Inside this method, there is code
to create the managed bean if the base is null (which in my case it is,
however, the property is not). So this causes a new ManagedBean to be
created, and the one that was restored by saveState is lost. The MyFaces
ManagedBeanResolver does not have this logic, thus it does not resolve the
bean and it continues on until the ScopedAttributeResolver class resolves
it.
My saveState declaration looks like this (we are saving the state of the
entire bean):
<t:saveState id="MyBackingBean" value="#{MyBackingBean}"/>
I tried to write a custom EL Resolver, but I'm not sure exactly what to do
in this case, since I want to preserve the behavior of the other Resolvers.
Any ideas?
Thanks,
Geoff
Re: t:saveState and Mojarra 1.2_12
Posted by Ganesh <ga...@j4fry.org>.
Hi Geoff,
Which is the tomahawk version you have in use? There is a tomahawk12
branch which is required for your task. I'm doing saveState with
tomahawk12_1.1.8 on glassfish v2.1
Best Regards,
Ganesh
Geoff Longo schrieb:
> I have an application where I am trying to change the JSF
> implementation from MyFaces Core 1.2.6 to Mojarra 1.2_12. I was
> hoping the application could still make use of the tomahawk saveState
> tag, as we use it heavily throughout the application. But it appears
> that the saveState tag is not working properly with Mojarra. I have
> debugged the issue and have found that the saveState and restoreState
> methods do get invoked, and it is able to restore the object
> successfully. But when the restoreState method tries to set the
> restored object through the ValueExpression, it eventually tries to
> resolve the variable by calling Mojarra's
> ManagedBeanELResolver.setValue() method. Inside this method, there is
> code to create the managed bean if the base is null (which in my case
> it is, however, the property is not). So this causes a new
> ManagedBean to be created, and the one that was restored by saveState
> is lost. The MyFaces ManagedBeanResolver does not have this logic,
> thus it does not resolve the bean and it continues on until the
> ScopedAttributeResolver class resolves it.
>
> My saveState declaration looks like this (we are saving the state of
> the entire bean):
>
> <t:saveState id="MyBackingBean" value="#{MyBackingBean}"/>
>
> I tried to write a custom EL Resolver, but I'm not sure exactly what
> to do in this case, since I want to preserve the behavior of the other
> Resolvers.
>
> Any ideas?
>
> Thanks,
> Geoff
Re: t:saveState and Mojarra 1.2_12
Posted by Ognjen Blagojevic <og...@etf.bg.ac.rs>.
I just wrote about similar problem. I'm using Mojarra 1.2_09, and
tomahawk12-1.1.7. I experience the bug under Tomcat 6.0.18, and 6.0.16,
but not under 6.0.14, and 6.0.13.
I don't know if the root of the problem is the same.
-Ognjen
Geoff Longo wrote:
> I have an application where I am trying to change the JSF implementation
> from MyFaces Core 1.2.6 to Mojarra 1.2_12. I was hoping the application
> could still make use of the tomahawk saveState tag, as we use it heavily
> throughout the application. But it appears that the saveState tag is
> not working properly with Mojarra. I have debugged the issue and have
> found that the saveState and restoreState methods do get invoked, and it
> is able to restore the object successfully. But when the restoreState
> method tries to set the restored object through the ValueExpression, it
> eventually tries to resolve the variable by calling Mojarra's
> ManagedBeanELResolver.setValue() method. Inside this method, there is
> code to create the managed bean if the base is null (which in my case it
> is, however, the property is not). So this causes a new ManagedBean to
> be created, and the one that was restored by saveState is lost. The
> MyFaces ManagedBeanResolver does not have this logic, thus it does not
> resolve the bean and it continues on until the ScopedAttributeResolver
> class resolves it.
>
> My saveState declaration looks like this (we are saving the state of the
> entire bean):
>
> <t:saveState id="MyBackingBean" value="#{MyBackingBean}"/>
>
> I tried to write a custom EL Resolver, but I'm not sure exactly what to
> do in this case, since I want to preserve the behavior of the other
> Resolvers.
>
> Any ideas?
>
> Thanks,
> Geoff
Re: t:saveState and Mojarra 1.2_12
Posted by Geoff Longo <gm...@gmail.com>.
Just as an FYI, I was able to get it to work by creating my own
CustomManagedBeanResolver:
public class CustomManagedBeanResolver extends ManagedBeanELResolver
{
@Override
public void setValue(ELContext context, Object base, Object property,
Object value)
throws ELException
{
if (base == null && property == null) {
String message = MessageUtils.getExceptionMessageString
(MessageUtils.NULL_PARAMETERS_ERROR_MESSAGE_ID, "base and
property");
throw new PropertyNotFoundException(message);
}
if (base == null) {
FacesContext fc =
(FacesContext)context.getContext(FacesContext.class);
fc.getExternalContext().getRequestMap().put((String)property,
value);
context.setPropertyResolved(true);
}
}
}
And declaring this custom el resolver in faces-config.xml:
<el-resolver>com.mypackage.util.CustomManagedBeanResolver</el-resolver>
Seems to be working ok, just not sure if this will cause any issues.
Thanks,
Geoff
On Wed, Apr 8, 2009 at 8:41 AM, Geoff Longo <gm...@gmail.com> wrote:
> I have an application where I am trying to change the JSF implementation
> from MyFaces Core 1.2.6 to Mojarra 1.2_12. I was hoping the application
> could still make use of the tomahawk saveState tag, as we use it heavily
> throughout the application. But it appears that the saveState tag is not
> working properly with Mojarra. I have debugged the issue and have found
> that the saveState and restoreState methods do get invoked, and it is able
> to restore the object successfully. But when the restoreState method tries
> to set the restored object through the ValueExpression, it eventually tries
> to resolve the variable by calling Mojarra's
> ManagedBeanELResolver.setValue() method. Inside this method, there is code
> to create the managed bean if the base is null (which in my case it is,
> however, the property is not). So this causes a new ManagedBean to be
> created, and the one that was restored by saveState is lost. The MyFaces
> ManagedBeanResolver does not have this logic, thus it does not resolve the
> bean and it continues on until the ScopedAttributeResolver class resolves
> it.
>
> My saveState declaration looks like this (we are saving the state of the
> entire bean):
>
> <t:saveState id="MyBackingBean" value="#{MyBackingBean}"/>
>
> I tried to write a custom EL Resolver, but I'm not sure exactly what to do
> in this case, since I want to preserve the behavior of the other Resolvers.
>
> Any ideas?
>
> Thanks,
> Geoff
>
Re: t:saveState and Mojarra 1.2_12
Posted by Geoff Longo <gm...@gmail.com>.
Just as an FYI, I was able to get it to work by creating my own
CustomManagedBeanResolver:
public class CustomManagedBeanResolver extends ManagedBeanELResolver
{
@Override
public void setValue(ELContext context, Object base, Object property,
Object value)
throws ELException
{
if (base == null && property == null) {
String message = MessageUtils.getExceptionMessageString
(MessageUtils.NULL_PARAMETERS_ERROR_MESSAGE_ID, "base and
property");
throw new PropertyNotFoundException(message);
}
if (base == null) {
FacesContext fc =
(FacesContext)context.getContext(FacesContext.class);
fc.getExternalContext().getRequestMap().put((String)property,
value);
context.setPropertyResolved(true);
}
}
}
And declaring this custom el resolver in faces-config.xml:
<el-resolver>com.mypackage.util.CustomManagedBeanResolver</el-resolver>
Seems to be working ok, just not sure if this will cause any issues.
Thanks,
Geoff
On Wed, Apr 8, 2009 at 8:41 AM, Geoff Longo <gm...@gmail.com> wrote:
> I have an application where I am trying to change the JSF implementation
> from MyFaces Core 1.2.6 to Mojarra 1.2_12. I was hoping the application
> could still make use of the tomahawk saveState tag, as we use it heavily
> throughout the application. But it appears that the saveState tag is not
> working properly with Mojarra. I have debugged the issue and have found
> that the saveState and restoreState methods do get invoked, and it is able
> to restore the object successfully. But when the restoreState method tries
> to set the restored object through the ValueExpression, it eventually tries
> to resolve the variable by calling Mojarra's
> ManagedBeanELResolver.setValue() method. Inside this method, there is code
> to create the managed bean if the base is null (which in my case it is,
> however, the property is not). So this causes a new ManagedBean to be
> created, and the one that was restored by saveState is lost. The MyFaces
> ManagedBeanResolver does not have this logic, thus it does not resolve the
> bean and it continues on until the ScopedAttributeResolver class resolves
> it.
>
> My saveState declaration looks like this (we are saving the state of the
> entire bean):
>
> <t:saveState id="MyBackingBean" value="#{MyBackingBean}"/>
>
> I tried to write a custom EL Resolver, but I'm not sure exactly what to do
> in this case, since I want to preserve the behavior of the other Resolvers.
>
> Any ideas?
>
> Thanks,
> Geoff
>