You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "Rick McGuire (JIRA)" <ji...@apache.org> on 2006/12/15 13:39:23 UTC
[jira] Created: (OPENEJB-408) Util.writeObject() fails when object
is array of remote interfaces.
Util.writeObject() fails when object is array of remote interfaces.
-------------------------------------------------------------------
Key: OPENEJB-408
URL: http://issues.apache.org/jira/browse/OPENEJB-408
Project: OpenEJB
Issue Type: Bug
Components: corba
Affects Versions: 2.2, 2.3
Reporter: Rick McGuire
Assigned To: Rick McGuire
Priority: Blocker
Fix For: 2.2, 2.3
Sort of a long chain of events failing here.
1) A method is called that returns an array of remote interfaces.
2) StandardServant calls Util.writeObject() to write out the method result (the array object).
3) writeObject() calls SerializationHandler.copyObj() to make a copy of the object. This is done so that writeReplace() will get called on any EJB objects in
the result.
4) copyObj() copies the object by write it out to an ObjectOutputStream, then reading back from an ObjectInputStream.
The result of these steps in an ArrayStoreException thrown by the ObjectInputStream. The cause of the exception is the following:
The objects stored in the array are instances of org.apache.openejb.proxy.SessionEJBObject. Serialization ends up calling the object's writeReplace() object, which appears to go through multiple stages of replacement, eventually resulting in an RMI Stub instance getting serialized to the stream. This stub object implements the EJBObject interface, but not the original remote interface that's the source array component type.
When this array is deserialized by ObjectInputStream, the RMI stubs are correctly deserialized, but an ArrayStoreException results because the stubs are not interface compatible with the original array.
The solution appears actually very simple. In writeObject(), skip the copy step if the object is an array. The Yoko output stream operations appears to be correctly sorting out the remote objects and correctly marshaling the array.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OPENEJB-408) Util.writeObject() fails when object
is array of remote interfaces.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick McGuire closed OPENEJB-408.
--------------------------------
Resolution: Fixed
> Util.writeObject() fails when object is array of remote interfaces.
> -------------------------------------------------------------------
>
> Key: OPENEJB-408
> URL: https://issues.apache.org/jira/browse/OPENEJB-408
> Project: OpenEJB
> Issue Type: Bug
> Components: corba
> Affects Versions: 2.2, 2.3
> Reporter: Rick McGuire
> Assigned To: Rick McGuire
> Priority: Blocker
> Fix For: 2.3
>
>
> Sort of a long chain of events failing here.
> 1) A method is called that returns an array of remote interfaces.
> 2) StandardServant calls Util.writeObject() to write out the method result (the array object).
> 3) writeObject() calls SerializationHandler.copyObj() to make a copy of the object. This is done so that writeReplace() will get called on any EJB objects in
> the result.
> 4) copyObj() copies the object by write it out to an ObjectOutputStream, then reading back from an ObjectInputStream.
> The result of these steps in an ArrayStoreException thrown by the ObjectInputStream. The cause of the exception is the following:
> The objects stored in the array are instances of org.apache.openejb.proxy.SessionEJBObject. Serialization ends up calling the object's writeReplace() object, which appears to go through multiple stages of replacement, eventually resulting in an RMI Stub instance getting serialized to the stream. This stub object implements the EJBObject interface, but not the original remote interface that's the source array component type.
> When this array is deserialized by ObjectInputStream, the RMI stubs are correctly deserialized, but an ArrayStoreException results because the stubs are not interface compatible with the original array.
> The solution appears actually very simple. In writeObject(), skip the copy step if the object is an array. The Yoko output stream operations appears to be correctly sorting out the remote objects and correctly marshaling the array.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work stopped: (OPENEJB-408) Util.writeObject() fails when
object is array of remote interfaces.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENEJB-408?page=all ]
Work on OPENEJB-408 stopped by Rick McGuire.
> Util.writeObject() fails when object is array of remote interfaces.
> -------------------------------------------------------------------
>
> Key: OPENEJB-408
> URL: http://issues.apache.org/jira/browse/OPENEJB-408
> Project: OpenEJB
> Issue Type: Bug
> Components: corba
> Affects Versions: 2.2, 2.3
> Reporter: Rick McGuire
> Assigned To: Rick McGuire
> Priority: Blocker
> Fix For: 2.2, 2.3
>
>
> Sort of a long chain of events failing here.
> 1) A method is called that returns an array of remote interfaces.
> 2) StandardServant calls Util.writeObject() to write out the method result (the array object).
> 3) writeObject() calls SerializationHandler.copyObj() to make a copy of the object. This is done so that writeReplace() will get called on any EJB objects in
> the result.
> 4) copyObj() copies the object by write it out to an ObjectOutputStream, then reading back from an ObjectInputStream.
> The result of these steps in an ArrayStoreException thrown by the ObjectInputStream. The cause of the exception is the following:
> The objects stored in the array are instances of org.apache.openejb.proxy.SessionEJBObject. Serialization ends up calling the object's writeReplace() object, which appears to go through multiple stages of replacement, eventually resulting in an RMI Stub instance getting serialized to the stream. This stub object implements the EJBObject interface, but not the original remote interface that's the source array component type.
> When this array is deserialized by ObjectInputStream, the RMI stubs are correctly deserialized, but an ArrayStoreException results because the stubs are not interface compatible with the original array.
> The solution appears actually very simple. In writeObject(), skip the copy step if the object is an array. The Yoko output stream operations appears to be correctly sorting out the remote objects and correctly marshaling the array.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (OPENEJB-408) Util.writeObject() fails when
object is array of remote interfaces.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENEJB-408?page=all ]
Work on OPENEJB-408 started by Rick McGuire.
> Util.writeObject() fails when object is array of remote interfaces.
> -------------------------------------------------------------------
>
> Key: OPENEJB-408
> URL: http://issues.apache.org/jira/browse/OPENEJB-408
> Project: OpenEJB
> Issue Type: Bug
> Components: corba
> Affects Versions: 2.2, 2.3
> Reporter: Rick McGuire
> Assigned To: Rick McGuire
> Priority: Blocker
> Fix For: 2.2, 2.3
>
>
> Sort of a long chain of events failing here.
> 1) A method is called that returns an array of remote interfaces.
> 2) StandardServant calls Util.writeObject() to write out the method result (the array object).
> 3) writeObject() calls SerializationHandler.copyObj() to make a copy of the object. This is done so that writeReplace() will get called on any EJB objects in
> the result.
> 4) copyObj() copies the object by write it out to an ObjectOutputStream, then reading back from an ObjectInputStream.
> The result of these steps in an ArrayStoreException thrown by the ObjectInputStream. The cause of the exception is the following:
> The objects stored in the array are instances of org.apache.openejb.proxy.SessionEJBObject. Serialization ends up calling the object's writeReplace() object, which appears to go through multiple stages of replacement, eventually resulting in an RMI Stub instance getting serialized to the stream. This stub object implements the EJBObject interface, but not the original remote interface that's the source array component type.
> When this array is deserialized by ObjectInputStream, the RMI stubs are correctly deserialized, but an ArrayStoreException results because the stubs are not interface compatible with the original array.
> The solution appears actually very simple. In writeObject(), skip the copy step if the object is an array. The Yoko output stream operations appears to be correctly sorting out the remote objects and correctly marshaling the array.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENEJB-408) Util.writeObject() fails when object
is array of remote interfaces.
Posted by "Dain Sundstrom (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENEJB-408?page=all ]
Dain Sundstrom updated OPENEJB-408:
-----------------------------------
Fix Version/s: (was: 2.2)
If this wasn't fixed in 2.2, it isn't getting fixed since 2.2 is wrapped.
> Util.writeObject() fails when object is array of remote interfaces.
> -------------------------------------------------------------------
>
> Key: OPENEJB-408
> URL: http://issues.apache.org/jira/browse/OPENEJB-408
> Project: OpenEJB
> Issue Type: Bug
> Components: corba
> Affects Versions: 2.2, 2.3
> Reporter: Rick McGuire
> Assigned To: Rick McGuire
> Priority: Blocker
> Fix For: 2.3
>
>
> Sort of a long chain of events failing here.
> 1) A method is called that returns an array of remote interfaces.
> 2) StandardServant calls Util.writeObject() to write out the method result (the array object).
> 3) writeObject() calls SerializationHandler.copyObj() to make a copy of the object. This is done so that writeReplace() will get called on any EJB objects in
> the result.
> 4) copyObj() copies the object by write it out to an ObjectOutputStream, then reading back from an ObjectInputStream.
> The result of these steps in an ArrayStoreException thrown by the ObjectInputStream. The cause of the exception is the following:
> The objects stored in the array are instances of org.apache.openejb.proxy.SessionEJBObject. Serialization ends up calling the object's writeReplace() object, which appears to go through multiple stages of replacement, eventually resulting in an RMI Stub instance getting serialized to the stream. This stub object implements the EJBObject interface, but not the original remote interface that's the source array component type.
> When this array is deserialized by ObjectInputStream, the RMI stubs are correctly deserialized, but an ArrayStoreException results because the stubs are not interface compatible with the original array.
> The solution appears actually very simple. In writeObject(), skip the copy step if the object is an array. The Yoko output stream operations appears to be correctly sorting out the remote objects and correctly marshaling the array.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENEJB-408) Util.writeObject() fails when
object is array of remote interfaces.
Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OPENEJB-408?page=comments#action_12458784 ]
Rick McGuire commented on OPENEJB-408:
--------------------------------------
Committed revision 487544. -- trunk
> Util.writeObject() fails when object is array of remote interfaces.
> -------------------------------------------------------------------
>
> Key: OPENEJB-408
> URL: http://issues.apache.org/jira/browse/OPENEJB-408
> Project: OpenEJB
> Issue Type: Bug
> Components: corba
> Affects Versions: 2.2, 2.3
> Reporter: Rick McGuire
> Assigned To: Rick McGuire
> Priority: Blocker
> Fix For: 2.2, 2.3
>
>
> Sort of a long chain of events failing here.
> 1) A method is called that returns an array of remote interfaces.
> 2) StandardServant calls Util.writeObject() to write out the method result (the array object).
> 3) writeObject() calls SerializationHandler.copyObj() to make a copy of the object. This is done so that writeReplace() will get called on any EJB objects in
> the result.
> 4) copyObj() copies the object by write it out to an ObjectOutputStream, then reading back from an ObjectInputStream.
> The result of these steps in an ArrayStoreException thrown by the ObjectInputStream. The cause of the exception is the following:
> The objects stored in the array are instances of org.apache.openejb.proxy.SessionEJBObject. Serialization ends up calling the object's writeReplace() object, which appears to go through multiple stages of replacement, eventually resulting in an RMI Stub instance getting serialized to the stream. This stub object implements the EJBObject interface, but not the original remote interface that's the source array component type.
> When this array is deserialized by ObjectInputStream, the RMI stubs are correctly deserialized, but an ArrayStoreException results because the stubs are not interface compatible with the original array.
> The solution appears actually very simple. In writeObject(), skip the copy step if the object is an array. The Yoko output stream operations appears to be correctly sorting out the remote objects and correctly marshaling the array.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira