You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/04/29 05:15:49 UTC
Tricky question - UnmarshalException Serialized Form.
Got a tricky question about java.rmi.UnmarshalException and
compatibility communicating with earlier versions of Jini.
For Java CDC, I'm missing java.rmi.UnmarshalException
UnmarshalException extends java.rmi.RemoteException, which I do have.
UnmarshalException has no Serialized state, nor does it have any
methods, only constructors.
I can't go changing all existing public API methods that throw it, to
throw say, net.jini.io.UnmarshalException since earlier platform
versions won't have the required class file.
I could throw RemoteException instead, however that might cause the
Exception to be caught higher up the call stack.
One solution seems to be to convert the serialized form to
java.rmi.RemoteException, and then change it back somewhere, perhaps in
JERI for java cdc?
Any ideas?
Cheers,
Peter.
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Got a tricky question about java.rmi.UnmarshalException and
> compatibility communicating with earlier versions of Jini.
>
> For Java CDC, I'm missing java.rmi.UnmarshalException
>
> UnmarshalException extends java.rmi.RemoteException, which I do have.
>
> UnmarshalException has no Serialized state, nor does it have any
> methods, only constructors.
>
> I can't go changing all existing public API methods that throw it, to
> throw say, net.jini.io.UnmarshalException since earlier platform
> versions won't have the required class file.
>
> I could throw RemoteException instead, however that might cause the
> Exception to be caught higher up the call stack.
>
> One solution seems to be to convert the serialized form of <edit>
> net.jini.io.UnmarshalException to java.rmi.UnmarshalException for
> ObjectOutputStream</edit>, and then change it back in
> ObjectInputStream somewhere, perhaps in JERI for java cdc only?
This doesn't seem very reasonable, I guess the consequences of changing
the exception thrown will cause a ClassNotFoundException or similar in a
remote jvm that unmarshalls the exception if it is serialized.
Still thinking...
> Any ideas?
>
> Cheers,
>
> Peter.
>
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ha, your right, I'm talking crap!
Hmm, let me start again: The debugging information I want, in this case
the stack trace, isn't part of the serialized form, it's transient, I
need to figure out how to get at it remotely.
Gregg had the right solution.
There you go people, don't be afraid to make fools of yourselves, jump
in and give us a hand!
Cheers,
Peter.
Christopher Dolan wrote:
> I'm intrigued and confused. Throwable is Serializable so how is it
> possible to make a subclass not serializable?
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Friday, April 30, 2010 2:22 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Tricky question - UnmarshalException Serialized Form.
>
> Thanks Gregg,
>
> I'm thinking about making all the new Exception classes non serializable
>
> to eliminate any codebase downloads for older jini version clients,
> thanks for the soln.
>
> That way only RemoteExceptions need be Serialized.
>
> Cheers,
>
> Peter.
>
> Gregg Wonderly wrote:
>
>> Peter Firmstone wrote:
>>
>>> No mate, that sounds cool, it would be nice to send stack traces
>>> remotely with nested exceptions too if possible anyone got any
>>> experiences or suggestions?
>>>
>> ex.printStackTrace( new PrintWriter( new StringWriter() ) );
>>
>> This works for me where I have does this to make sure that I don't
>> have to worry about SQLExceptions and the like not being serializable.
>>
>> Gregg Wonderly
>>
>>
>>
>
>
>
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Gregg Wonderly <gr...@gmail.com>.
SQL exceptions from some DBs seem to include meta data in the creation of the subclass object which is not serializable. Unfortunately, serializable is still not built into the language spec so that compilers have to traverse the class members to make sure they live up to the contract.
Gregg
Sent from my iPad
On Apr 30, 2010, at 8:56 AM, "Christopher Dolan" <ch...@avid.com> wrote:
> I'm intrigued and confused. Throwable is Serializable so how is it
> possible to make a subclass not serializable?
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Friday, April 30, 2010 2:22 AM
> To: river-dev@incubator.apache.org
> Subject: Re: Tricky question - UnmarshalException Serialized Form.
>
> Thanks Gregg,
>
> I'm thinking about making all the new Exception classes non serializable
>
> to eliminate any codebase downloads for older jini version clients,
> thanks for the soln.
>
> That way only RemoteExceptions need be Serialized.
>
> Cheers,
>
> Peter.
>
> Gregg Wonderly wrote:
>> Peter Firmstone wrote:
>>> No mate, that sounds cool, it would be nice to send stack traces
>>> remotely with nested exceptions too if possible anyone got any
>>> experiences or suggestions?
>>
>> ex.printStackTrace( new PrintWriter( new StringWriter() ) );
>>
>> This works for me where I have does this to make sure that I don't
>> have to worry about SQLExceptions and the like not being serializable.
>>
>> Gregg Wonderly
>>
>>
>
RE: Tricky question - UnmarshalException Serialized Form.
Posted by Christopher Dolan <ch...@avid.com>.
I'm intrigued and confused. Throwable is Serializable so how is it
possible to make a subclass not serializable?
Chris
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: Friday, April 30, 2010 2:22 AM
To: river-dev@incubator.apache.org
Subject: Re: Tricky question - UnmarshalException Serialized Form.
Thanks Gregg,
I'm thinking about making all the new Exception classes non serializable
to eliminate any codebase downloads for older jini version clients,
thanks for the soln.
That way only RemoteExceptions need be Serialized.
Cheers,
Peter.
Gregg Wonderly wrote:
> Peter Firmstone wrote:
>> No mate, that sounds cool, it would be nice to send stack traces
>> remotely with nested exceptions too if possible anyone got any
>> experiences or suggestions?
>
> ex.printStackTrace( new PrintWriter( new StringWriter() ) );
>
> This works for me where I have does this to make sure that I don't
> have to worry about SQLExceptions and the like not being serializable.
>
> Gregg Wonderly
>
>
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Gregg,
I'm thinking about making all the new Exception classes non serializable
to eliminate any codebase downloads for older jini version clients,
thanks for the soln.
That way only RemoteExceptions need be Serialized.
Cheers,
Peter.
Gregg Wonderly wrote:
> Peter Firmstone wrote:
>> No mate, that sounds cool, it would be nice to send stack traces
>> remotely with nested exceptions too if possible anyone got any
>> experiences or suggestions?
>
> ex.printStackTrace( new PrintWriter( new StringWriter() ) );
>
> This works for me where I have does this to make sure that I don't
> have to worry about SQLExceptions and the like not being serializable.
>
> Gregg Wonderly
>
>
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Gregg Wonderly <gr...@wonderly.org>.
Peter Firmstone wrote:
> No mate, that sounds cool, it would be nice to send stack traces
> remotely with nested exceptions too if possible anyone got any
> experiences or suggestions?
ex.printStackTrace( new PrintWriter( new StringWriter() ) );
This works for me where I have does this to make sure that I don't have to worry
about SQLExceptions and the like not being serializable.
Gregg Wonderly
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Peter Firmstone <ji...@zeus.net.au>.
Tom Hobbs wrote:
> Hi Peter,
>
> I've always been under the impression that Jini threw high level/general
> exceptions on purpose, specifically to counter this issue.
>
> Presumable there is a small subset of exceptions (like RemoteException)
> which is going to exist on "all" JVMs, thus enabling compatibility across
> different versions. If I understand you correctly, you want to throw a more
> specific exception which some JVMs aren't going to have. Is that right?
>
> Would an acceptable solution be to introduce a new River exception which
> extends RemoteException. Then older JVMs can carry on catching
> RemoteException and dealing with it how every they see fit, and new ones can
> catch the more specific version.
>
> Personally, I think that throwing the general RemoteException (with a useful
> message) is the most appropriate thing to do at the 'River level'.
>
> An exceptions-dl.jar sounds a promising idea in any case.
>
> Does that make sense or have I missed something again?
>
No mate, that sounds cool, it would be nice to send stack traces
remotely with nested exceptions too if possible anyone got any
experiences or suggestions?
> Cheers,
>
> Tom
>
>
> On Thu, Apr 29, 2010 at 11:13 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>
>> Perhaps an exceptions-dl.jar, which would only be required if an exception
>> was propagated from a jini 2.2.0 CDC node to a jini 2.1.2 or earlier java SE
>> node?
>>
>> Seems the least complicated solution?
>>
>>
>> Peter Firmstone wrote:
>>
>>
>>> Got a tricky question about java.rmi.UnmarshalException and compatibility
>>> communicating with earlier versions of Jini.
>>>
>>> For Java CDC, I'm missing java.rmi.UnmarshalException
>>>
>>> UnmarshalException extends java.rmi.RemoteException, which I do have.
>>>
>>> UnmarshalException has no Serialized state, nor does it have any methods,
>>> only constructors.
>>>
>>> I can't go changing all existing public API methods that throw it, to
>>> throw say, net.jini.io.UnmarshalException since earlier platform versions
>>> won't have the required class file.
>>>
>>> I could throw RemoteException instead, however that might cause the
>>> Exception to be caught higher up the call stack.
>>>
>>> One solution seems to be to convert the serialized form to
>>> java.rmi.RemoteException, and then change it back somewhere, perhaps in JERI
>>> for java cdc?
>>>
>>> Any ideas?
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>>
>
>
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi Peter,
I've always been under the impression that Jini threw high level/general
exceptions on purpose, specifically to counter this issue.
Presumable there is a small subset of exceptions (like RemoteException)
which is going to exist on "all" JVMs, thus enabling compatibility across
different versions. If I understand you correctly, you want to throw a more
specific exception which some JVMs aren't going to have. Is that right?
Would an acceptable solution be to introduce a new River exception which
extends RemoteException. Then older JVMs can carry on catching
RemoteException and dealing with it how every they see fit, and new ones can
catch the more specific version.
Personally, I think that throwing the general RemoteException (with a useful
message) is the most appropriate thing to do at the 'River level'.
An exceptions-dl.jar sounds a promising idea in any case.
Does that make sense or have I missed something again?
Cheers,
Tom
On Thu, Apr 29, 2010 at 11:13 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Perhaps an exceptions-dl.jar, which would only be required if an exception
> was propagated from a jini 2.2.0 CDC node to a jini 2.1.2 or earlier java SE
> node?
>
> Seems the least complicated solution?
>
>
> Peter Firmstone wrote:
>
>> Got a tricky question about java.rmi.UnmarshalException and compatibility
>> communicating with earlier versions of Jini.
>>
>> For Java CDC, I'm missing java.rmi.UnmarshalException
>>
>> UnmarshalException extends java.rmi.RemoteException, which I do have.
>>
>> UnmarshalException has no Serialized state, nor does it have any methods,
>> only constructors.
>>
>> I can't go changing all existing public API methods that throw it, to
>> throw say, net.jini.io.UnmarshalException since earlier platform versions
>> won't have the required class file.
>>
>> I could throw RemoteException instead, however that might cause the
>> Exception to be caught higher up the call stack.
>>
>> One solution seems to be to convert the serialized form to
>> java.rmi.RemoteException, and then change it back somewhere, perhaps in JERI
>> for java cdc?
>>
>> Any ideas?
>>
>> Cheers,
>>
>> Peter.
>>
>>
>
Re: Tricky question - UnmarshalException Serialized Form.
Posted by Peter Firmstone <ji...@zeus.net.au>.
Perhaps an exceptions-dl.jar, which would only be required if an
exception was propagated from a jini 2.2.0 CDC node to a jini 2.1.2 or
earlier java SE node?
Seems the least complicated solution?
Peter Firmstone wrote:
> Got a tricky question about java.rmi.UnmarshalException and
> compatibility communicating with earlier versions of Jini.
>
> For Java CDC, I'm missing java.rmi.UnmarshalException
>
> UnmarshalException extends java.rmi.RemoteException, which I do have.
>
> UnmarshalException has no Serialized state, nor does it have any
> methods, only constructors.
>
> I can't go changing all existing public API methods that throw it, to
> throw say, net.jini.io.UnmarshalException since earlier platform
> versions won't have the required class file.
>
> I could throw RemoteException instead, however that might cause the
> Exception to be caught higher up the call stack.
>
> One solution seems to be to convert the serialized form to
> java.rmi.RemoteException, and then change it back somewhere, perhaps
> in JERI for java cdc?
>
> Any ideas?
>
> Cheers,
>
> Peter.
>