Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <911952483.1256932439439.JavaMail.jira@brutus>
Date: Fri, 30 Oct 2009 19:53:59 +0000 (UTC)
From: "Michael Freedman (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Commented: (PORTLETBRIDGE-99) RequestScopeListener not
 Serializable
In-Reply-To: <1582044659.1256849759692.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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