[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772062#action_12772062
]
Michael Freedman commented on PORTLETBRIDGE-99:
-----------------------------------------------
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. One possibility is that we should also have a
null constructor?
FYI... in a perfect world this attribute would not be replication/distributed.
The purpose of this attribute is to act as a sentinel. The set of Bridge
requestScopes are managed in the Application scope -- this was done for two
reasons:
a) because this scopeManager is managing (caching) the container's request
scope objects which have no expectation of being serializable/distributed it
was thought better to not store this data in the session.
b) the bridge can easily manage (removing) all its scopes (for shutdown)
when the application terminates.
The "sentinel" on the session works as follows:
a) the object holds a string that contains a request scope prefix for this
user session (all request scopes managed by the bridge contain N levels of
prefixing to allow removal of groups of scopes).
b) implements the session listener interface so that when the session is
being removed and hence this attribute -- we are notified so we can remove the
corresponding entries in the application scope.
I.e. since we can't/don't migrate the actual bridge request scopes managed in
the app scope it would be best if we don't migrate this session attribute -- is
there anyway to disable it from being migrated? I think some servers merely
don't migrate those attrs that don't implement Serializable (without throwing
an exception) but that obviously isn't the case here. All I can think of is to
write a sessionPassivateListener which would remove the attribute, delegate,
then add it back. But I suspect that the actual passivation doesn't occur in
the listener notification process and hence this wouldn't work.
If we have to make this thing serializable -- the servlet spec implies it only
needs to be marked serializable as there is no requirement the container use
the Java serialization process/mechanism. Hence I would have figured it would
have worked from your attempt above. Please send me additional information so
we can figure this out.
> 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.
