[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772069#action_12772069
]
Fernando Silva Lozano commented on PORTLETBRIDGE-99:
----------------------------------------------------
Michael asked:
"Can you clarify your last comment? Once you "hack" the bridge by marking the
RequestScopeListener as serializable -- does it still cause the
IllegalArgumentException to be thrown? Or are you finding that you are hitting
other objects that are also getting added to the session that throw this
exception? If the former, is there a different stack trace than the original
you provided -- though I am confused why you would still get this exception
once its marked serializable."
After I marked RequestScopeListener as Serializable, another class caused the
same exception, with the same stack trace. So I went on marking more classes as
Serializable, and the exception started to happen with MyFaces core (*NOT*
portlet bridge) classes. I checked out Myfaces core and continued marking
classes as serializable, but gave up when the same exception (with same stack
trace) was thrown for an internal eXo Platform portlet container class.
if you want I can send my changes so far and the latest stack trace,but I
wonder if it's something with portlet bridge itself or with the way eXo tries
to implement clustering. I hadn't noticed before the stack trace shows
replication being managed by an eXo class and not by JBoss AS cache. Maybe we
should test with something else, say Pluto inside a clustered stand-alone
Tomcat.But I don't even know if Pluto is supposed to work on a clustered web
container.
I guess a sessionPassivateListener would work, at least the servlet spec says
it exists for these kind of scenario (replicating or passivating a session).
As far as I know both Tomcat and JBoss AS try to replicate evetything in the
HttpSession and if something can't be they throw exceptions and the current
replication transaction fails -- that is, they won't move on to the next
attribute. From previous experiences I make all session attributes serializable
as sugested (required?) by the servlet spec.
Although JBoss AS uses Tomcat's Catalina, the replication implementations are
completely different. But if you configure JBoss AS to use a TreeCacheAOP for
replication (instead of the plain TreeCache) it doesn't need serializable
attributes. This set-up is not java ee compliant, as it requires you to
instrument your classes using JBoss AOP.
> RequestScopeListener not Serializable
> -------------------------------------
>
> Key: PORTLETBRIDGE-99
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-beta
> Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces
> 1.2.7 and JBoss embebed Mojarra
> Reporter: Fernando Silva Lozano
>
> I get lots of erros on JBoss AS log such as:
> 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException:
> java.io.NotSerializableException:
> org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener
> 13:51:03,110 ERROR [STDERR] at
> org.jgroups.Message.setObject(Message.java:281)
> 13:51:03,110 ERROR [STDERR] at org.jgroups.Message.<init>(Message.java:141)
> 13:51:03,110 ERROR [STDERR] at
> org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103)
> 13:51:03,110 ERROR [STDERR] at
> org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114)
> 13:51:03,110 ERROR [STDERR] at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 13:51:03,111 ERROR [STDERR] at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> 13:51:03,111 ERROR [STDERR] at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
> 13:51:03,111 ERROR [STDERR] at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 13:51:03,111 ERROR [STDERR] at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 13:51:03,111 ERROR [STDERR] at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> 13:51:03,112 ERROR [STDERR] at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 13:51:03,112 ERROR [STDERR] at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
> 13:51:03,112 ERROR [STDERR] at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> 13:51:03,112 ERROR [STDERR] at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> 13:51:03,112 ERROR [STDERR] at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
> 13:51:03,112 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595)
> I think it is self-explanatory: every object stored on the user HTTP session
> should be serializable, and one of the objects put there by the bridge (an
> inner class of BridgeImpl) isn't.
> I rated as Major because I suppose this will prevent my JSF portlet to work
> correctly in a clustered container.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
