[
http://issues.apache.org/jira/browse/MYFACES-872?page=comments#action_12358627
]
Roland Huss commented on MYFACES-872:
-------------------------------------
Yes, BoardConverter is an implementation of an JSF converter which handles our
domain object Board
With "next application class" I mean the next class from our application's
client jar file (gss-client.jar). In this case
it is a UserSession which is a backing bean for a component.
I inserted a phase listener with the following method:
public void beforePhase(PhaseEvent phaseEvent) {
printMark(">>>>>>>>>>>>>>>>>>>>>>>>>>>",phaseEvent);
if (log.isDebugEnabled()) {
try {
Thread.currentThread().getContextClassLoader().loadClass("com.bmw.gss.client.converter.BoardConverter");
this.getClass().getClassLoader().loadClass("com.bmw.gss.client.converter.BoardConverter");
log.debug("Found BoardConverter class");
} catch (ClassNotFoundException e) {
log.debug("Couldn't found BoardConverter: " + e,e);
}
}
}
The output is:
[java] 44444 DEBUG util.PhaseTracker| >>>>>>>>>>>>>>>>>>>>>>>>>>>
RESTORE_VIEW(1) - (no view-id) | en_US
[java] 44444 DEBUG util.PhaseTracker| Found BoardConverter class
[java] 44550 ERROR .JspStateManagerImpl| Could not deserialize state:
com.bmw.gss.client.converter.BoardConverter [java]
java.lang.ClassNotFoundException: com.bmw.gss.client.converter.BoardConverter
[java] at
weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:198)
....
So, loading the converter directly from the application works fine. In fact, as
you can see the converter has been already loaded during
the previous serialization (otherwise we wouldn't get that far).
I didn't contacted BEA yet, but I agree that it is probably a Weblogic issue.
However, I probably have to provide a stripped down
example showing this issue and unfortunately I'm very busy these days ;-(
For me the workaround to use plain objects instead of a serialized tree is
usable. I just wanted to point out, that there might
be some issues with serialization/deserialization on Weblogic 8.1
> Deserialization of view fails on Weblogic 8.1
> ---------------------------------------------
>
> Key: MYFACES-872
> URL: http://issues.apache.org/jira/browse/MYFACES-872
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: Nightly
> Environment: Linux
> Weblogic 8.1
> Reporter: Roland Huss
> Attachments: client_server_stacktrace.txt, state_server_stacktrace.txt
>
> The current MyFaces SVN snapshot used object serialization for storing the
> view in the session
> (instead of plain objects as it does in 1.1.1)
> This leads to an ClassLoader issue on Weblogic 8.1 during deserialization of
> the view. It seems that
> Weblogic cannot find non-myfaces classes during view-restoring:
> [java] 78230 ERROR .JspStateManagerImpl| Could not deserialize state:
> com.bmw.gss.client.converter.BoardConverter
> [java] java.lang.ClassNotFoundException:
> com.consol.gss.client.converter.BoardConverter
> [java] at
> weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:199)
> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> [java] ....
> [java] at
> org.apache.myfaces.application.jsp.JspStateManagerImpl.deserializeView(JspStateManagerImpl.java:546)
> Strange engough, the client classes and myfaces.jar are loaded by the same
> Classloader (we deployed them as jar within
> an ear which are both referenced from the war's manifest) and except for this
> deserialization issue the can 'see' each
> other.
> I'm not sure, whether this is MyFaces or a Weblogic Issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
