[JBoss JIRA] Created: (JBPORTAL-1094) ClassCastException when casting SubSession to List in PortalSessionSynchronizationInterceptor
by Poul Bildsoee Moeller (JIRA)
ClassCastException when casting SubSession to List in PortalSessionSynchronizationInterceptor
---------------------------------------------------------------------------------------------
Key: JBPORTAL-1094
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1094
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Portlet
Affects Versions: 2.4 Final
Environment: Portal Clustered using both Portal-ha-2.4.1CR1 and 2.4.0-ha running on JBoss AS 4.0.4
Reporter: Poul Bildsoee Moeller
Assigned To: Julien Viet
Priority: Minor
In org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor the following code is executed (code partially inserted):
HttpSession session = req.getSession(false);
if (session != null)
{
ss = (SubSession)session.getAttribute(key);
}
//
try
{
// Set the sub session for the portlet synchronization
if (ss != null && ss.isActivated())
{
invocation.setAttribute("subsession", ss);
}
//
invocation.invokeNext();
}
finally
{
List modifications = (List)invocation.getAttribute("subsession");
The code sets the SubSession as an attribute on invocation and then later tries to fetch this again and at the same time cast to List. This doesn't work since SubSession isn't a List. I am not sure what is meant to happen so I cannot really fix the problem myself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JBREM-623) need reset() call added back to JavaSerializationManager.sendObject() method
by Tom Elrod (JIRA)
need reset() call added back to JavaSerializationManager.sendObject() method
----------------------------------------------------------------------------
Key: JBREM-623
URL: http://jira.jboss.com/jira/browse/JBREM-623
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.2.0.Alpha3 (Bluto)
Reporter: Tom Elrod
Assigned To: Ron Sigal
Priority: Critical
Fix For: 2.2.0.Beta1 (Bluto)
Per JBREM-597, code was changed within JavaSerializationManager.sendObject() to not call reset() on the ObjectOutputStream as would cause an error (see below). Although this solution works, it is not optimal as need the reset() to be called to release the references kept internally to the object stream (otherwise could potentially run out of memory if are sending a lot of different object types).
Error when reset() method is called:
java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is:
java.io.IOException: Can not read data for version 121. Supported versions: 1, 2
at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:408)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125)
at org.jboss.remoting.Client.invoke(Client.java:605)
at org.jboss.remoting.Client.invoke(Client.java:597)
at org.jboss.remoting.Client.invoke(Client.java:582)
at org.jboss.test.remoting.transport.socket.connection.SocketTestClient.testInvocations(SocketTestClient.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.io.IOException: Can not read data for version 121. Supported versions: 1, 2
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:503)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:370)
... 28 more
Test case: org.jboss.test.remoting.transport.socket.connection.SocketConnectionTestCase & org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months
[JBoss JIRA] Created: (JBCACHE-693) TreeCache configuration bombs with InvocationTargetException when JVM locale is set to Turkish.
by Yasar Safkan (JIRA)
TreeCache configuration bombs with InvocationTargetException when JVM locale is set to Turkish.
-----------------------------------------------------------------------------------------------
Key: JBCACHE-693
URL: http://jira.jboss.com/jira/browse/JBCACHE-693
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Tested on Linux, using Resin 3.0.14 with Hibernate 3.
Reporter: Yasar Safkan
Assigned To: Manik Surtani
When the parameters:
-Duser.language=tr -Duser.country=TR
are passed to the JVM, the AppServer startup bombs when it tires to configure TreeCache using treecache.xml. Seems that it reads the value fine, but thinks the value is invalid for some reason.
My best guess is this stems from the way the letters i and I are handled in Turkish. If there is any upper/lowercase conversion code within JBossCache, these letters are handled funny, thus string constants like READ_COMMITED are not recognized.
The fix will probably be to use upper/lowercase conversion by specifying a character set in the JBossCache code, and not relying on the JVM defaults.
The JVM itself had a similar bug, which prevented encrytion from working under these same conditions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 3 months