[ http://issues.apache.org/jira/browse/MYFACES-1163?page=comments#action_12369381 ]
Stan Silvert commented on MYFACES-1163: --------------------------------------- I was wrong. What I was seeing was some experimental JBoss code crapping out because of the MyFaces package name changes. This was not because of class loading. I haven't reproduced the actual problem that this issue refers to. I'll still fix it, but I will need Ingo's help with testing. Is this only a problem with client state saving? > JBoss classloading fails if myfaces jars installed in tomcat > ------------------------------------------------------------ > > Key: MYFACES-1163 > URL: http://issues.apache.org/jira/browse/MYFACES-1163 > Project: MyFaces Core > Type: Bug > Versions: 1.1.2, 1.1.2-SNAPSHOT, 1.1.3-SNAPSHOT > Environment: JBoss 4.0.4RC1 myfaces-1.1.3-SNAPSHOT > Reporter: Ingo Massen > Assignee: Stan Silvert > Priority: Blocker > > Cannot use Myfaces jars installed in > JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs as they do > not use the correct WebappClassloader but instead an UCL3 classloader. > This is because myfaces use the following line in StateUtils.getAsObject > ObjectInputStream s = new ObjectInputStream(input); > instead of > import org.apache.myfaces.shared.util.MyFacesObjectInputStream; > ObjectInputStream s = new MyFacesObjectInputStream(input); > The same applies to JspStateManagerImpl.deserializeView(). > ObjectInputStream uses Class.forName instead of > Thread.currentThread().getContextClassLoader() as the ClassUtils > implementation that MyFacesObjectInputStream uses does. -- 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
