myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Freedman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (PORTLETBRIDGE-99) RequestScopeListener not Serializable
Date Fri, 30 Oct 2009 19:53:59 GMT

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


Mime
View raw message