[jira] Created: (PORTLETBRIDGE-99) RequestScopeListener not Serializable

[My Faces - Dev mailing list]

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 WCM 1.2 under JBoss AS 4.2.2, 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.

[My Faces - Dev mailing list]

    [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771629#action_12771629 ]

Fernando Silva Lozano commented on PORTLETBRIDGE-99:
----------------------------------------------------

From revision 811048:

http://svn.apache.org/viewvc/myfaces/portlet-bridge/core/trunk/impl/src/main/java/org/apache/myfaces/portlet/faces/bridge/BridgeImpl.java?view=markup

It looks like all we need is to change lines 1772 and 1773 as follows:

1772: private final class RequestScopeListener
1773:     implements HttpSessionBindingListener, java.lang.Serializable

I'm trying right now to figure out how to build the portlet bridge from sources to test my "patch".

> 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 WCM 1.2 under JBoss AS 4.2.2, 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.

[My Faces - Dev mailing list]

    [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771673#action_12771673 ]

Fernando Silva Lozano commented on PORTLETBRIDGE-99:
----------------------------------------------------

After making my little change, logs start to show the message:

18:47:04,479 ERROR [STDERR] java.lang.IllegalArgumentException: java.io.NotSerializableException: org.apache.myfaces.portlet.faces.context.FacesContextFactoryImpl
18:47:04,479 ERROR [STDERR] at org.jgroups.Message.setObject(Message.java:281)

It looks loke I'll have to hunt a lot of non-serializable classes on MyFaces also...

Am I the first one to try MyFaces and the portlet-bridge on a clustered web container?

> 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 WCM 1.2 under JBoss AS 4.2.2, 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.

[My Faces - Dev mailing list]

    [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772046#action_12772046 ]

Fernando Silva Lozano commented on PORTLETBRIDGE-99:
----------------------------------------------------

The brute force approach didn't work. After making serializable many classes from both myfaces and the portlet bridge I ended up with serialization erros on an eXo platfrom implementation class. Internal from the portlet container shouldn't be exposed as session attributes, so the real fix needs a deeper look inside the causes of the serialization error, that is, something is stored as a session attribute that shouldn't.

> 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.

[My Faces - Dev mailing list]

    [ 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.

[My Faces - Dev mailing list]

    [ 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.

[My Faces - Dev mailing list]

    [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772078#action_12772078 ]

Michael Freedman commented on PORTLETBRIDGE-99:
-----------------------------------------------

Note:  If the problem truly is just with the RequestScopeListener we can consider changing this so this isn't an HttpSessionAttributeListener but rather a HttpSessionListener.  This wasn't done (originally) because we wanted to avoid folks having to add an entry to the web.xml (the session listener) just to get the bridge to work properly.  I.e. we figure most folks would forget to do this and then be confused when the bridge didn't work properly.  

However, if we have to do it .... I can probably figure out a way to only require it for the distributable case -- i.e. if this listener is set/configured then don't add the atributeListener otherwise add it ... but that in itself will require some obscure code to deal with removing scopes on a portlet session basis.

> 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.

[My Faces - Dev mailing list]

    [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772082#action_12772082 ]

Michael Freedman commented on PORTLETBRIDGE-99:
-----------------------------------------------

Sounds like the problem may be more pervasive than the bridge.  I.e. sounds like MyFaces and maybe even eXo itself has non-serializable session attrs.  Is this the new(er) jBoss/eXo combined portal?  If not what causes these two to show up together?  

If you think the bridge is really the culprit here you can try removing adding this session attribute altogether (as a test).  Since its just used to clean up the scope cache when the session is invalidated the only consequence (for the test) is the cache has stale values if the session is invalidated.  Can you try this?

Note:  I checked through the bridge code and the only two other cases  (1 in the portlet 1.0 bridge case) where it adds session attrs -- the values of these attrs are Strings -- so they shouldn't cause any problems.
    -Mike-

> 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.