December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3952) Problem with SerializableProxy when de-serializing in a remote client

by Frank Ulbricht (JIRA)

Problem with SerializableProxy when de-serializing in a remote client --------------------------------------------------------------------- Key: JBAS-3952 URL: http://jira.jboss.com/jira/browse/JBAS-3952 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3, Hibernate service Affects Versions: JBossAS-4.0.5.GA Environment: Windows Vista and Windows XP, Java 1.5.0 Update 10 and Java 1.6.0 Reporter: Frank Ulbricht Assigned To: Bill Burke After calling a SessionBean method that returns an entity with a lazy relation there is an problem with de-serialization on the client side. The lazy field cannot not be assigned because of a ClassCastException. In other projects the same happens after a method returns the result of a query where lazy fields are involved. The problem occurs only with lazy fields. The is a simple test case attached with the problem code line marked. Here is the complete stacktrace: java.lang.reflect.UndeclaredThrowableException at $Proxy6.updateAddress(Unknown Source) at com.qualitype.testcase.client.RemoteClientTestCase.test(RemoteClientTestCase.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.lang.ClassCastException: cannot assign instance of org.hibernate.proxy.pojo.javassist.SerializableProxy to field com.qualitype.testcase.entity.Address.person of type com.qualitype.testcase.entity.Person in instance of com.qualitype.testcase.entity.Address at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:306) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) ... 22 more Caused by: java.lang.ClassCastException: cannot assign instance of org.hibernate.proxy.pojo.javassist.SerializableProxy to field com.qualitype.testcase.entity.Address.person of type com.qualitype.testcase.entity.Person in instance of com.qualitype.testcase.entity.Address at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(Unknown Source) at java.io.ObjectStreamClass.setObjFieldValues(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122) at java.io.ObjectInputStream.readExternalData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279) ... 34 more -- 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

17 years, 4 months

5
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1734) "edit mode" could be checked for authorization

by Thomas Heute (JIRA)

"edit mode" could be checked for authorization ---------------------------------------------- Key: JBPORTAL-1734 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1734 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Reporter: Thomas Heute Assigned To: Julien Viet Fix For: 2.8 Final An admin should be able to define which roles have access to the edit mode for a particular portlet. Since it would break backward compatibility, it has to be part of a major release. -- 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

17 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1214) drools-server should not have .settings commited into svn

by Geoffrey De Smet (JIRA)

drools-server should not have .settings commited into svn --------------------------------------------------------- Key: JBRULES-1214 URL: http://jira.jboss.com/jira/browse/JBRULES-1214 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.1 Reporter: Geoffrey De Smet Assigned To: Mark Proctor Priority: Trivial Fix For: FUTURE See JBRULES-834. As far as I can tell, the commit of /drools-server/.settings is an error because the other server modules explicitly svn:ignore the .settings directory. The svn ignore was probably forgotten, which might have given our good friend eclipse the opportunity to commit it. I could be wrong though. If I am right though, the .settings directory should be deleted in svn, which will cause havoc when everyone updates who's relying on .settings in drools-server, and the svn:ignore should be edited to contain these 3 items: .metadata .settings .wtpmodules This way it uses standardized svn ignores just like the other modules. -- 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

17 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-346) Mavenize Docbook support

by Paul Gier (JIRA)

Mavenize Docbook support ------------------------ Key: JBBUILD-346 URL: http://jira.jboss.com/jira/browse/JBBUILD-346 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Fix For: MavenBuild 2.0 Migrate docbook-support from ant to maven. https://svn.jboss.org/repos/jbossas/trunk/docbook-support/ -- 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

17 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3828) spelling mistake in xml tag

by Goran Oberg (JIRA)

spelling mistake in xml tag --------------------------- Key: JBAS-3828 URL: http://jira.jboss.com/jira/browse/JBAS-3828 Project: JBoss Application Server Issue Type: Bug Affects Versions: JBossAS-4.0.4.GA Environment: All Reporter: Goran Oberg Priority: Trivial Just a spelling mistake... Should be <url-delimiter> instead of <url-delimeter> in <ha-local-tx-datasource> -- 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

17 years, 4 months

5
7
0 / 0

[JBoss JIRA] Created: (JBPORTAL-953) wiki not visible

by Sacha Labourey (JIRA)

wiki not visible ---------------- Key: JBPORTAL-953 URL: http://jira.jboss.com/jira/browse/JBPORTAL-953 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4 Final Reporter: Sacha Labourey deploying wiki.war from portletswap in JBP deploy's folder doesn't make it visible in the list of creatable portlet (admin interface) -- 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

17 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JGRP-640) Shared protocols

by Bela Ban (JIRA)

Shared protocols ---------------- Key: JGRP-640 URL: http://jira.jboss.com/jira/browse/JGRP-640 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.x Like the shared transport, investigate whether we can share other protocols. E.g. FD, FD_SOCK (preventing duplicate server sockets and sockets), Discovery and so on. -- 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

17 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-983) Messages can be delivered after connection is stopped

by Tim Fox (JIRA)

Messages can be delivered after connection is stopped ----------------------------------------------------- Key: JBMESSAGING-983 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-983 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.CR1 Stopping a connection does not currently block until all current onMessage invocations are complete, as per JMS spec. We need to make sure it does. -- 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

17 years, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-806) JBM is assuming it can look up system properties on the client side

by Tim Fox (JIRA)

JBM is assuming it can look up system properties on the client side ------------------------------------------------------------------- Key: JBMESSAGING-806 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-806 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.SP3, 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta2, 1.0.1.SP4 JBM (JMSRemotingConnection) does several System.getProperties() to get the override bind address and port. However in a security restricted environment e.g. jnlp or applet this may not work. This causes an exception to be thrown and the connection is not created. Need to catch the exception and set to null. -- 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

17 years, 4 months

5
15
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1197) support HTTP transport

by Jeff Mesnil (JIRA)

support HTTP transport ---------------------- Key: JBMESSAGING-1197 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1197 Project: JBoss Messaging Issue Type: Sub-task Components: JMS Remoting Reporter: Jeff Mesnil Assigned To: Jeff Mesnil Fix For: 2.0.0 Alpha the new remoting code based on MINA currently supports only TCP transport. It must also support HTTP transport. MINA provides an HTTP package we can use for both the JMS clients (send requests/receive responses) and the JMS servers (receive request/send response). Message delivery must also be taken into account. The client can use polling (and remains a simple HTTP client). However since MINA code is used on both the client and ther server, we need to check if we can send HTTP requests to the client on the same TCP connection (the ideabeing that we MUST NOT open a server connection on the client in any way) -- 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

17 years, 4 months

3
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007