[
https://issues.apache.org/jira/browse/TRINIDAD-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570322#action_12570322
]
Scott O'Bryan commented on TRINIDAD-955:
----------------------------------------
I notice you are using Facelets. I can only assume that is your issue. I
havn't had a chance to take a look at it, but here is what I think is
happening:
StateManager changed between JSF 1.1 and JSF 1.2. While an effort was made in
JSF 1.2 to allow exiting frameworks to continue to function, StateManagers
written for JSF 1.1 and JSF 1.2 don't play well together. In Trinidad 1.2.6 we
had to change from a JSF 1.1 type StateManager to a JSF 1.2 type StateManager
in order to address some compatibility issues with the JSR 301 PortletBridge.
I havn't had a chance to check yet, but my guess is that Facelets still has a
JSF 1.1 compatible StateManager.
Essentially, my guess is that saveView is being executed on the Facelet's
stateManager which (if it's a JSF 1.1 statemanager) will call
saveSerializedView in Trinidad's StateManagerImpl which will call
saveSerializedView in the R.I.'s StateManager. When Trinidad's restoreView is
being called, it does not know how to handle a state that it did not save.
There are a number of ways this can be fixed, neither of which are difficult,
but it may impact how everything works.
1. We can implement the saveSerializedView method which is currently in the
Trinidad 1.1.6 branch in addition to the saveView method which already exists
in the Trinidad 1.2.6 branch. I changed both of these StateManagerImpl's to
make sure the code was close to the same and the underlying logic is common
among both of the StateManager's .. The reason I didn't implement this method
is that (by default) in JSF 1.2, the saveSerializedView does nothing. Only if
a JSF 1.1 StateManager is in the stack does this method actually return a
value. So in my patch excluded implementing this method for correctness and
the ability to have a consistent and predictable outcome. We can add this back
in and it should fix the issue because Trinidad's state saving would once again
be invoked rather then using the delegate.
2. We can change Trinidad's StateManagerImpl to check for the existence of the
String , and if the state is not a String, simply delegate to the wrapped
class. This is a dangerous solution because it bypasses allows all of
Trinidad's state management to be bypassed all at once.
> ClassCastException in StateManagerImpl on PPR
> ---------------------------------------------
>
> Key: TRINIDAD-955
> URL: https://issues.apache.org/jira/browse/TRINIDAD-955
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Archetype
> Affects Versions: 1.2.6-core
> Environment: Facelets 1.1.14, JSF 1.2_07 RI
> Reporter: Alexey Stukalov
> Priority: Critical
>
> On attempt to PPR, the following exception is thrown:
> {panel}
> Caused by: java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast
> to java.lang.String
> at
> org.apache.myfaces.trinidadinternal.util.SubKeyMap._getBaseKey(SubKeyMap.java:116)
> at
> org.apache.myfaces.trinidadinternal.util.SubKeyMap.get(SubKeyMap.java:75)
> at
> org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:526)
> at
> com.sun.faces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:318)
> at
> com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316)
> at
> javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:204)
> at
> org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:260)
> at
> com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:176)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> at
> com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
> ... 19 more
> {panel}
> Instead of returning token string, an array of objects is returned by
> ResponseStateManager.getTreeStructureToRestore().
> This affects trinidad-1.2.6 (maybe the issue is caused by changes in revision
> #614404 ?). trinidad-1.2.5 is ok
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
