Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Riena » Using Riena and JodaTime
Using Riena and JodaTime [message #10243] Thu, 04 September 2008 06:37 Go to next message
boss182  is currently offline boss182
Messages: 10
Registered: July 2009
Junior Member
Hi Riena Team,

I encountered some problems when using Riena in combination with JodaTime
(i.e. org.joda.time.LocalDate). When sending over the wire from server to
client everything works fine. The other direction causes an
java.lang.InstantiationException, because hessian tries to instantiate the
abstract class Chronology instead of the real class ISOChronology. A part
of the stacktrace is following below.

Perhaps you can help me with some useful hints to solve or bypass this
problem. While googling the problem i found
http://maillist.caucho.com/pipermail/hessian-interest/2007-A pril/000054.html,
but this thread is not really a help.

Thanks in advance
Johannes

----Part of the Stacktrace----
Caused by: com.caucho.hessian.io.HessianFieldException:
org.joda.time.LocalDate.iChronology: org.joda.time.Chronology:null
at
com.caucho.hessian.io.JavaDeserializer.logDeserializeError(J avaDeserializer.java:586)
at
com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:387)
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
at
com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
at
com.caucho.hessian.io.SerializerFactory.readMap(SerializerFa ctory.java:343)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1929)
at
com.caucho.hessian.io.CollectionDeserializer.readList(Collec tionDeserializer.java:78)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1666)
at
com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
at
com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkel eton.java:149)
at
org.eclipse.riena.communication.publisher.hessian.HessianRie naDispatcherServlet.service(HessianRienaDispatcherServlet.ja va:153)
... 18 more
Caused by: com.caucho.hessian.io.IOExceptionWrapper:
org.joda.time.Chronology:null
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:147)
at com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
at
com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
... 34 more
Caused by: java.lang.InstantiationException
at
sun.reflect.InstantiationExceptionConstructorAccessorImpl.ne wInstance(InstantiationExceptionConstructorAccessorImpl.java :30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:4 94)
at
com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeser ializer.java:270)
at
com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:139)
... 36 more
Re: Using Riena and JodaTime [message #10276 is a reply to message #10243] Thu, 04 September 2008 08:28 Go to previous messageGo to next message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
my best guess is that you method specifies the abstract type in its method signature like

Chronology getSomething();

while the server actually passes back the ISOChronology.

the problem is that hessian (since it is a bundle) cannot see the class ISOChronology in its classpath. It tries to load
that class with Class.forName(...). that fails and it takes the Class object from the signature of the method that it
has already in its "hand".

Solution is to add something to the bundle that has ISOChronology in it. First a dependency to riena.communication.core
and then a Eclipse-RegisterBudy: org.eclipse.riena.communication.core

then communication.core Sees that class and since it is a buddy to hessian, also hessian gets to see this.

still unsure what I mean ? look at bundle org.eclipse.riena.communication.sample.common. The manifest.mf shows you how
to do it. (make sure you have a dependency and a buddy policy, buddies dont work without dependency)

hope that helps, otherwise let me know
christian


boss182 schrieb:
> Hi Riena Team,
>
> I encountered some problems when using Riena in combination with
> JodaTime (i.e. org.joda.time.LocalDate). When sending over the wire from
> server to client everything works fine. The other direction causes an
> java.lang.InstantiationException, because hessian tries to instantiate
> the abstract class Chronology instead of the real class ISOChronology. A
> part of the stacktrace is following below.
>
> Perhaps you can help me with some useful hints to solve or bypass this
> problem. While googling the problem i found
> http://maillist.caucho.com/pipermail/hessian-interest/2007-A pril/000054.html,
> but this thread is not really a help.
>
> Thanks in advance
> Johannes
>
> ----Part of the Stacktrace----
> Caused by: com.caucho.hessian.io.HessianFieldException:
> org.joda.time.LocalDate.iChronology: org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.logDeserializeError(J avaDeserializer.java:586)
>
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:387)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.SerializerFactory.readMap(SerializerFa ctory.java:343)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1929)
> at
> com.caucho.hessian.io.CollectionDeserializer.readList(Collec tionDeserializer.java:78)
>
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1666)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkel eton.java:149)
> at
> org.eclipse.riena.communication.publisher.hessian.HessianRie naDispatcherServlet.service(HessianRienaDispatcherServlet.ja va:153)
>
> ... 18 more
> Caused by: com.caucho.hessian.io.IOExceptionWrapper:
> org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:147)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> ... 34 more
> Caused by: java.lang.InstantiationException
> at
> sun.reflect.InstantiationExceptionConstructorAccessorImpl.ne wInstance(InstantiationExceptionConstructorAccessorImpl.java :30)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:4 94)
> at
> com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeser ializer.java:270)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:139)
> ... 36 more
>
Re: Using Riena and JodaTime [message #10343 is a reply to message #10276] Thu, 04 September 2008 16:17 Go to previous messageGo to next message
boss182  is currently offline boss182
Messages: 10
Registered: July 2009
Junior Member
Hi Christian,

thanks for your answer. But it still doesn't work. I've already had an
buddy-policy to com.caucho.hessian. Now I added the further policy to
riena.communication.core - with no success.
Your guess with the method Chornology getSomething(); is nearly right.
JodaTime further serializes the ISOChronology with the writeReplace-method
to an inner class called Stub, which is private static final to
ISOChronology. I thought the problem is, that this Stub is private static
final. But on client side it works fine.
Are there any differences between the serializing-mechanism of the server
and the client? I still don't understand why it works sending the
LocalDate from the server to the client, but not the other direction. The
only noticeable difference for me while debugging is that the client uses
HessianInput and the server Hessian2Input, but the same JavaDeserializer.

Best regards
Johannes
Re: Using Riena and JodaTime [message #10374 is a reply to message #10343] Fri, 05 September 2008 08:34 Go to previous messageGo to next message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
hi johannes

I can only guess since I dont know the classes and project you are using.

You are right that there shouldnt be a difference between client 2 server or server 2 client. I never had that problem
except if there was no buddy policy because then Hessian looks at the method signature for the return-type.

I briefly looked at the code and found a view things that looked strange and are maybe worthwhile looking at (the code
in the post you refer with the URL)

- so you create the Stub in the writeReplace method but the readResolve in Stub refers to a transient field iZone. (isnt
that bound to be null ?), transient fields are not transferred by hessian

- the stacktrace in the first post has a exception message of null
Caused by: com.caucho.hessian.io.IOExceptionWrapper: org.joda.time.Chronology:null

where does this null come from ?

- when the JavaDeserializer calls new Instance for the class to be serialized (probably Stub) it gets
Caused by: java.lang.InstantiationException
at
sun.reflect.InstantiationExceptionConstructorAccessorImpl.ne wInstance(InstantiationExceptionConstructorAccessorImpl.java :30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:4 94)
at com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeser ializer.java:270)
at com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:139)
... 36 more

Find the cause why constructing the instance fails.

- When deserializing Hessian always calls the constructor with to smallest number of parameters. For Stub this seems to be.
Stub(DateTimeZone zone) {
iZone = zone;
}
all parameters are set to null in this initial constructor call.

does that help ? let me know about your progress.....

You seem to do very interesting stuff. If you like post something about it, what you are doing. We are interested to
hear it.

regards
christian campo

boss182 schrieb:
> Hi Christian,
>
> thanks for your answer. But it still doesn't work. I've already had an
> buddy-policy to com.caucho.hessian. Now I added the further policy to
> riena.communication.core - with no success.
> Your guess with the method Chornology getSomething(); is nearly right.
> JodaTime further serializes the ISOChronology with the
> writeReplace-method to an inner class called Stub, which is private
> static final to ISOChronology. I thought the problem is, that this Stub
> is private static final. But on client side it works fine.
> Are there any differences between the serializing-mechanism of the
> server and the client? I still don't understand why it works sending the
> LocalDate from the server to the client, but not the other direction.
> The only noticeable difference for me while debugging is that the client
> uses HessianInput and the server Hessian2Input, but the same
> JavaDeserializer.
>
> Best regards
> Johannes
>
Re: Using Riena and JodaTime [message #10407 is a reply to message #10374] Fri, 05 September 2008 13:37 Go to previous messageGo to next message
boss182  is currently offline boss182
Messages: 10
Registered: July 2009
Junior Member
Hi Christian,

I simply have to agree to you, when you say the code of JodaTime,
especially the ISOChronology looks strange...
I've just now found out why the wrong Constructor is called and why the
result of the two directions differ.
The direction server2client uses Hessian2Input, like it is hardly coded in
the HessianRienaDispatcherServlet. The direction client2server asks the
RienaHessianProxyFactory which AbstractHessianInput to use
(getHessianInput(InputStream is)). There I always get an HessianInput.

For deserializing Hessian2Input uses the method
getObjectDeserializer(String type, Class cl) of the SerializerFactory. By
contrast HessianInput uses the the method getObjectDeserializer(String
type).
The first method returns the wrong Deserializer because of the following
lines of code:
---------
Deserializer reader = getObjectDeserializer(type);
if (cl == null
|| cl == reader.getType()
|| cl.isAssignableFrom(reader.getType())) {
return reader;
}
...
return getDeserializer(cl);
---------
debug info of variables:
cl=org.joda.time.Chronology
reader.getType()=org.joda.time.chrono.ISOChronology$Stub

The condition fails because of the Stub, which was created in the
writeReplace(). So it falls back to get an Deserializer for the class,
which is the abstract class Chronology. And then the known error occurs.
HessianInput's method simply uses the getObjectDeserializer(type);

I hope this explanation is clearly. Otherwise let me know.
Are there any considerations to use a (configureable) factory in the
HessianRienaDispatcherServlet for creating the input like it is done in
the RienaHessianProxyFactory? This would possibly offer me the ability to
bypass this bug (or missing feature) in hessian. What are the benefits of
taking the Hessian2Input insteadof HessianInput?

regards
Johannes
Re: Using Riena and JodaTime [message #10534 is a reply to message #10407] Mon, 08 September 2008 09:09 Go to previous messageGo to next message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
Hi Johannes,

clearly a bug somewhere in the code. So I created bugzilla entries 246533, 246534 and 246535 to track various of the
issues in this problems. 246534 is of most interest for you.

There is currently no plan for a configurable factory. Sounds like a good plan. Please open a bugzilla entry to track
that feature request.

christian campo


boss182 schrieb:
> Hi Christian,
>
> I simply have to agree to you, when you say the code of JodaTime,
> especially the ISOChronology looks strange...
> I've just now found out why the wrong Constructor is called and why the
> result of the two directions differ.
> The direction server2client uses Hessian2Input, like it is hardly coded
> in the HessianRienaDispatcherServlet. The direction client2server asks
> the RienaHessianProxyFactory which AbstractHessianInput to use
> (getHessianInput(InputStream is)). There I always get an HessianInput.
>
> For deserializing Hessian2Input uses the method
> getObjectDeserializer(String type, Class cl) of the SerializerFactory.
> By contrast HessianInput uses the the method
> getObjectDeserializer(String type).
> The first method returns the wrong Deserializer because of the following
> lines of code:
> ---------
> Deserializer reader = getObjectDeserializer(type);
> if (cl == null
> || cl == reader.getType()
> || cl.isAssignableFrom(reader.getType())) {
> return reader;
> }
> ..
> return getDeserializer(cl);
> ---------
> debug info of variables: cl=org.joda.time.Chronology
> reader.getType()=org.joda.time.chrono.ISOChronology$Stub
>
> The condition fails because of the Stub, which was created in the
> writeReplace(). So it falls back to get an Deserializer for the class,
> which is the abstract class Chronology. And then the known error occurs.
> HessianInput's method simply uses the getObjectDeserializer(type);
>
> I hope this explanation is clearly. Otherwise let me know.
> Are there any considerations to use a (configureable) factory in the
> HessianRienaDispatcherServlet for creating the input like it is done in
> the RienaHessianProxyFactory? This would possibly offer me the ability
> to bypass this bug (or missing feature) in hessian. What are the
> benefits of taking the Hessian2Input insteadof HessianInput?
>
> regards
> Johannes
>
Re: Using Riena and JodaTime [message #10567 is a reply to message #10534] Mon, 08 September 2008 15:44 Go to previous messageGo to next message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
I have explained it in detail in 246534. So just for reference. Jodatime does not work with Hessian in many ways. So
Riena cannot fix these problems and WONT. Sorry about that, but the problem is in the way Jodatime is implemented, as
explained in bugzilla.....

christian campo


Christian Campo schrieb:
> Hi Johannes,
>
> clearly a bug somewhere in the code. So I created bugzilla entries
> 246533, 246534 and 246535 to track various of the issues in this
> problems. 246534 is of most interest for you.
>
> There is currently no plan for a configurable factory. Sounds like a
> good plan. Please open a bugzilla entry to track that feature request.
>
> christian campo
>
>
> boss182 schrieb:
>> Hi Christian,
>>
>> I simply have to agree to you, when you say the code of JodaTime,
>> especially the ISOChronology looks strange...
>> I've just now found out why the wrong Constructor is called and why
>> the result of the two directions differ.
>> The direction server2client uses Hessian2Input, like it is hardly
>> coded in the HessianRienaDispatcherServlet. The direction
>> client2server asks the RienaHessianProxyFactory which
>> AbstractHessianInput to use (getHessianInput(InputStream is)). There I
>> always get an HessianInput.
>>
>> For deserializing Hessian2Input uses the method
>> getObjectDeserializer(String type, Class cl) of the SerializerFactory.
>> By contrast HessianInput uses the the method
>> getObjectDeserializer(String type).
>> The first method returns the wrong Deserializer because of the
>> following lines of code:
>> ---------
>> Deserializer reader = getObjectDeserializer(type);
>> if (cl == null
>> || cl == reader.getType()
>> || cl.isAssignableFrom(reader.getType())) {
>> return reader;
>> }
>> ..
>> return getDeserializer(cl);
>> ---------
>> debug info of variables: cl=org.joda.time.Chronology
>> reader.getType()=org.joda.time.chrono.ISOChronology$Stub
>>
>> The condition fails because of the Stub, which was created in the
>> writeReplace(). So it falls back to get an Deserializer for the class,
>> which is the abstract class Chronology. And then the known error occurs.
>> HessianInput's method simply uses the getObjectDeserializer(type);
>>
>> I hope this explanation is clearly. Otherwise let me know.
>> Are there any considerations to use a (configureable) factory in the
>> HessianRienaDispatcherServlet for creating the input like it is done
>> in the RienaHessianProxyFactory? This would possibly offer me the
>> ability to bypass this bug (or missing feature) in hessian. What are
>> the benefits of taking the Hessian2Input insteadof HessianInput?
>>
>> regards
>> Johannes
>>
Re: Using Riena and JodaTime [message #10818 is a reply to message #10243] Mon, 15 September 2008 09:01 Go to previous message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
A new feature in the HEAD of Riena's CVS allows you now to specify SerializerFactories to help you transport types like
JodaTime. Bugzilla 246549 explains with some sample code how that is done in detail.

Note this wont work with M4 because it requirs the changes that we did after that in the HEAD of Riena.

Hope that helps everyone with this same kind of problem.

christian


boss182 schrieb:
> Hi Riena Team,
>
> I encountered some problems when using Riena in combination with
> JodaTime (i.e. org.joda.time.LocalDate). When sending over the wire from
> server to client everything works fine. The other direction causes an
> java.lang.InstantiationException, because hessian tries to instantiate
> the abstract class Chronology instead of the real class ISOChronology. A
> part of the stacktrace is following below.
>
> Perhaps you can help me with some useful hints to solve or bypass this
> problem. While googling the problem i found
> http://maillist.caucho.com/pipermail/hessian-interest/2007-A pril/000054.html,
> but this thread is not really a help.
>
> Thanks in advance
> Johannes
>
> ----Part of the Stacktrace----
> Caused by: com.caucho.hessian.io.HessianFieldException:
> org.joda.time.LocalDate.iChronology: org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.logDeserializeError(J avaDeserializer.java:586)
>
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:387)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.SerializerFactory.readMap(SerializerFa ctory.java:343)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1929)
> at
> com.caucho.hessian.io.CollectionDeserializer.readList(Collec tionDeserializer.java:78)
>
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1666)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkel eton.java:149)
> at
> org.eclipse.riena.communication.publisher.hessian.HessianRie naDispatcherServlet.service(HessianRienaDispatcherServlet.ja va:153)
>
> ... 18 more
> Caused by: com.caucho.hessian.io.IOExceptionWrapper:
> org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:147)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> ... 34 more
> Caused by: java.lang.InstantiationException
> at
> sun.reflect.InstantiationExceptionConstructorAccessorImpl.ne wInstance(InstantiationExceptionConstructorAccessorImpl.java :30)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:4 94)
> at
> com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeser ializer.java:270)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:139)
> ... 36 more
>
Re: Using Riena and JodaTime [message #574278 is a reply to message #10243] Thu, 04 September 2008 08:28 Go to previous message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
my best guess is that you method specifies the abstract type in its method signature like

Chronology getSomething();

while the server actually passes back the ISOChronology.

the problem is that hessian (since it is a bundle) cannot see the class ISOChronology in its classpath. It tries to load
that class with Class.forName(...). that fails and it takes the Class object from the signature of the method that it
has already in its "hand".

Solution is to add something to the bundle that has ISOChronology in it. First a dependency to riena.communication.core
and then a Eclipse-RegisterBudy: org.eclipse.riena.communication.core

then communication.core Sees that class and since it is a buddy to hessian, also hessian gets to see this.

still unsure what I mean ? look at bundle org.eclipse.riena.communication.sample.common. The manifest.mf shows you how
to do it. (make sure you have a dependency and a buddy policy, buddies dont work without dependency)

hope that helps, otherwise let me know
christian


boss182 schrieb:
> Hi Riena Team,
>
> I encountered some problems when using Riena in combination with
> JodaTime (i.e. org.joda.time.LocalDate). When sending over the wire from
> server to client everything works fine. The other direction causes an
> java.lang.InstantiationException, because hessian tries to instantiate
> the abstract class Chronology instead of the real class ISOChronology. A
> part of the stacktrace is following below.
>
> Perhaps you can help me with some useful hints to solve or bypass this
> problem. While googling the problem i found
> http://maillist.caucho.com/pipermail/hessian-interest/2007-A pril/000054.html,
> but this thread is not really a help.
>
> Thanks in advance
> Johannes
>
> ----Part of the Stacktrace----
> Caused by: com.caucho.hessian.io.HessianFieldException:
> org.joda.time.LocalDate.iChronology: org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.logDeserializeError(J avaDeserializer.java:586)
>
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:387)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.SerializerFactory.readMap(SerializerFa ctory.java:343)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1929)
> at
> com.caucho.hessian.io.CollectionDeserializer.readList(Collec tionDeserializer.java:78)
>
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1666)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkel eton.java:149)
> at
> org.eclipse.riena.communication.publisher.hessian.HessianRie naDispatcherServlet.service(HessianRienaDispatcherServlet.ja va:153)
>
> ... 18 more
> Caused by: com.caucho.hessian.io.IOExceptionWrapper:
> org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:147)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> ... 34 more
> Caused by: java.lang.InstantiationException
> at
> sun.reflect.InstantiationExceptionConstructorAccessorImpl.ne wInstance(InstantiationExceptionConstructorAccessorImpl.java :30)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:4 94)
> at
> com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeser ializer.java:270)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:139)
> ... 36 more
>
Re: Using Riena and JodaTime [message #574332 is a reply to message #10276] Thu, 04 September 2008 16:17 Go to previous message
boss182  is currently offline boss182
Messages: 10
Registered: July 2009
Junior Member
Hi Christian,

thanks for your answer. But it still doesn't work. I've already had an
buddy-policy to com.caucho.hessian. Now I added the further policy to
riena.communication.core - with no success.
Your guess with the method Chornology getSomething(); is nearly right.
JodaTime further serializes the ISOChronology with the writeReplace-method
to an inner class called Stub, which is private static final to
ISOChronology. I thought the problem is, that this Stub is private static
final. But on client side it works fine.
Are there any differences between the serializing-mechanism of the server
and the client? I still don't understand why it works sending the
LocalDate from the server to the client, but not the other direction. The
only noticeable difference for me while debugging is that the client uses
HessianInput and the server Hessian2Input, but the same JavaDeserializer.

Best regards
Johannes
Re: Using Riena and JodaTime [message #574366 is a reply to message #10343] Fri, 05 September 2008 08:34 Go to previous message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
hi johannes

I can only guess since I dont know the classes and project you are using.

You are right that there shouldnt be a difference between client 2 server or server 2 client. I never had that problem
except if there was no buddy policy because then Hessian looks at the method signature for the return-type.

I briefly looked at the code and found a view things that looked strange and are maybe worthwhile looking at (the code
in the post you refer with the URL)

- so you create the Stub in the writeReplace method but the readResolve in Stub refers to a transient field iZone. (isnt
that bound to be null ?), transient fields are not transferred by hessian

- the stacktrace in the first post has a exception message of null
Caused by: com.caucho.hessian.io.IOExceptionWrapper: org.joda.time.Chronology:null

where does this null come from ?

- when the JavaDeserializer calls new Instance for the class to be serialized (probably Stub) it gets
Caused by: java.lang.InstantiationException
at
sun.reflect.InstantiationExceptionConstructorAccessorImpl.ne wInstance(InstantiationExceptionConstructorAccessorImpl.java :30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:4 94)
at com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeser ializer.java:270)
at com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:139)
... 36 more

Find the cause why constructing the instance fails.

- When deserializing Hessian always calls the constructor with to smallest number of parameters. For Stub this seems to be.
Stub(DateTimeZone zone) {
iZone = zone;
}
all parameters are set to null in this initial constructor call.

does that help ? let me know about your progress.....

You seem to do very interesting stuff. If you like post something about it, what you are doing. We are interested to
hear it.

regards
christian campo

boss182 schrieb:
> Hi Christian,
>
> thanks for your answer. But it still doesn't work. I've already had an
> buddy-policy to com.caucho.hessian. Now I added the further policy to
> riena.communication.core - with no success.
> Your guess with the method Chornology getSomething(); is nearly right.
> JodaTime further serializes the ISOChronology with the
> writeReplace-method to an inner class called Stub, which is private
> static final to ISOChronology. I thought the problem is, that this Stub
> is private static final. But on client side it works fine.
> Are there any differences between the serializing-mechanism of the
> server and the client? I still don't understand why it works sending the
> LocalDate from the server to the client, but not the other direction.
> The only noticeable difference for me while debugging is that the client
> uses HessianInput and the server Hessian2Input, but the same
> JavaDeserializer.
>
> Best regards
> Johannes
>
Re: Using Riena and JodaTime [message #574392 is a reply to message #10374] Fri, 05 September 2008 13:37 Go to previous message
boss182  is currently offline boss182
Messages: 10
Registered: July 2009
Junior Member
Hi Christian,

I simply have to agree to you, when you say the code of JodaTime,
especially the ISOChronology looks strange...
I've just now found out why the wrong Constructor is called and why the
result of the two directions differ.
The direction server2client uses Hessian2Input, like it is hardly coded in
the HessianRienaDispatcherServlet. The direction client2server asks the
RienaHessianProxyFactory which AbstractHessianInput to use
(getHessianInput(InputStream is)). There I always get an HessianInput.

For deserializing Hessian2Input uses the method
getObjectDeserializer(String type, Class cl) of the SerializerFactory. By
contrast HessianInput uses the the method getObjectDeserializer(String
type).
The first method returns the wrong Deserializer because of the following
lines of code:
---------
Deserializer reader = getObjectDeserializer(type);
if (cl == null
|| cl == reader.getType()
|| cl.isAssignableFrom(reader.getType())) {
return reader;
}
...
return getDeserializer(cl);
---------
debug info of variables:
cl=org.joda.time.Chronology
reader.getType()=org.joda.time.chrono.ISOChronology$Stub

The condition fails because of the Stub, which was created in the
writeReplace(). So it falls back to get an Deserializer for the class,
which is the abstract class Chronology. And then the known error occurs.
HessianInput's method simply uses the getObjectDeserializer(type);

I hope this explanation is clearly. Otherwise let me know.
Are there any considerations to use a (configureable) factory in the
HessianRienaDispatcherServlet for creating the input like it is done in
the RienaHessianProxyFactory? This would possibly offer me the ability to
bypass this bug (or missing feature) in hessian. What are the benefits of
taking the Hessian2Input insteadof HessianInput?

regards
Johannes
Re: Using Riena and JodaTime [message #574497 is a reply to message #10407] Mon, 08 September 2008 09:09 Go to previous message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
Hi Johannes,

clearly a bug somewhere in the code. So I created bugzilla entries 246533, 246534 and 246535 to track various of the
issues in this problems. 246534 is of most interest for you.

There is currently no plan for a configurable factory. Sounds like a good plan. Please open a bugzilla entry to track
that feature request.

christian campo


boss182 schrieb:
> Hi Christian,
>
> I simply have to agree to you, when you say the code of JodaTime,
> especially the ISOChronology looks strange...
> I've just now found out why the wrong Constructor is called and why the
> result of the two directions differ.
> The direction server2client uses Hessian2Input, like it is hardly coded
> in the HessianRienaDispatcherServlet. The direction client2server asks
> the RienaHessianProxyFactory which AbstractHessianInput to use
> (getHessianInput(InputStream is)). There I always get an HessianInput.
>
> For deserializing Hessian2Input uses the method
> getObjectDeserializer(String type, Class cl) of the SerializerFactory.
> By contrast HessianInput uses the the method
> getObjectDeserializer(String type).
> The first method returns the wrong Deserializer because of the following
> lines of code:
> ---------
> Deserializer reader = getObjectDeserializer(type);
> if (cl == null
> || cl == reader.getType()
> || cl.isAssignableFrom(reader.getType())) {
> return reader;
> }
> ..
> return getDeserializer(cl);
> ---------
> debug info of variables: cl=org.joda.time.Chronology
> reader.getType()=org.joda.time.chrono.ISOChronology$Stub
>
> The condition fails because of the Stub, which was created in the
> writeReplace(). So it falls back to get an Deserializer for the class,
> which is the abstract class Chronology. And then the known error occurs.
> HessianInput's method simply uses the getObjectDeserializer(type);
>
> I hope this explanation is clearly. Otherwise let me know.
> Are there any considerations to use a (configureable) factory in the
> HessianRienaDispatcherServlet for creating the input like it is done in
> the RienaHessianProxyFactory? This would possibly offer me the ability
> to bypass this bug (or missing feature) in hessian. What are the
> benefits of taking the Hessian2Input insteadof HessianInput?
>
> regards
> Johannes
>
Re: Using Riena and JodaTime [message #574514 is a reply to message #10534] Mon, 08 September 2008 15:44 Go to previous message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
I have explained it in detail in 246534. So just for reference. Jodatime does not work with Hessian in many ways. So
Riena cannot fix these problems and WONT. Sorry about that, but the problem is in the way Jodatime is implemented, as
explained in bugzilla.....

christian campo


Christian Campo schrieb:
> Hi Johannes,
>
> clearly a bug somewhere in the code. So I created bugzilla entries
> 246533, 246534 and 246535 to track various of the issues in this
> problems. 246534 is of most interest for you.
>
> There is currently no plan for a configurable factory. Sounds like a
> good plan. Please open a bugzilla entry to track that feature request.
>
> christian campo
>
>
> boss182 schrieb:
>> Hi Christian,
>>
>> I simply have to agree to you, when you say the code of JodaTime,
>> especially the ISOChronology looks strange...
>> I've just now found out why the wrong Constructor is called and why
>> the result of the two directions differ.
>> The direction server2client uses Hessian2Input, like it is hardly
>> coded in the HessianRienaDispatcherServlet. The direction
>> client2server asks the RienaHessianProxyFactory which
>> AbstractHessianInput to use (getHessianInput(InputStream is)). There I
>> always get an HessianInput.
>>
>> For deserializing Hessian2Input uses the method
>> getObjectDeserializer(String type, Class cl) of the SerializerFactory.
>> By contrast HessianInput uses the the method
>> getObjectDeserializer(String type).
>> The first method returns the wrong Deserializer because of the
>> following lines of code:
>> ---------
>> Deserializer reader = getObjectDeserializer(type);
>> if (cl == null
>> || cl == reader.getType()
>> || cl.isAssignableFrom(reader.getType())) {
>> return reader;
>> }
>> ..
>> return getDeserializer(cl);
>> ---------
>> debug info of variables: cl=org.joda.time.Chronology
>> reader.getType()=org.joda.time.chrono.ISOChronology$Stub
>>
>> The condition fails because of the Stub, which was created in the
>> writeReplace(). So it falls back to get an Deserializer for the class,
>> which is the abstract class Chronology. And then the known error occurs.
>> HessianInput's method simply uses the getObjectDeserializer(type);
>>
>> I hope this explanation is clearly. Otherwise let me know.
>> Are there any considerations to use a (configureable) factory in the
>> HessianRienaDispatcherServlet for creating the input like it is done
>> in the RienaHessianProxyFactory? This would possibly offer me the
>> ability to bypass this bug (or missing feature) in hessian. What are
>> the benefits of taking the Hessian2Input insteadof HessianInput?
>>
>> regards
>> Johannes
>>
Re: Using Riena and JodaTime [message #574837 is a reply to message #10243] Mon, 15 September 2008 09:01 Go to previous message
Christian Campo is currently offline Christian Campo
Messages: 590
Registered: July 2009
Senior Member
A new feature in the HEAD of Riena's CVS allows you now to specify SerializerFactories to help you transport types like
JodaTime. Bugzilla 246549 explains with some sample code how that is done in detail.

Note this wont work with M4 because it requirs the changes that we did after that in the HEAD of Riena.

Hope that helps everyone with this same kind of problem.

christian


boss182 schrieb:
> Hi Riena Team,
>
> I encountered some problems when using Riena in combination with
> JodaTime (i.e. org.joda.time.LocalDate). When sending over the wire from
> server to client everything works fine. The other direction causes an
> java.lang.InstantiationException, because hessian tries to instantiate
> the abstract class Chronology instead of the real class ISOChronology. A
> part of the stacktrace is following below.
>
> Perhaps you can help me with some useful hints to solve or bypass this
> problem. While googling the problem i found
> http://maillist.caucho.com/pipermail/hessian-interest/2007-A pril/000054.html,
> but this thread is not really a help.
>
> Thanks in advance
> Johannes
>
> ----Part of the Stacktrace----
> Caused by: com.caucho.hessian.io.HessianFieldException:
> org.joda.time.LocalDate.iChronology: org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.logDeserializeError(J avaDeserializer.java:586)
>
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:387)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.SerializerFactory.readMap(SerializerFa ctory.java:343)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1929)
> at
> com.caucho.hessian.io.CollectionDeserializer.readList(Collec tionDeserializer.java:78)
>
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1666)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:199)
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:141)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkel eton.java:149)
> at
> org.eclipse.riena.communication.publisher.hessian.HessianRie naDispatcherServlet.service(HessianRienaDispatcherServlet.ja va:153)
>
> ... 18 more
> Caused by: com.caucho.hessian.io.IOExceptionWrapper:
> org.joda.time.Chronology:null
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:147)
> at
> com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input .java:1634)
> at
> com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializ er.deserialize(JavaDeserializer.java:383)
>
> ... 34 more
> Caused by: java.lang.InstantiationException
> at
> sun.reflect.InstantiationExceptionConstructorAccessorImpl.ne wInstance(InstantiationExceptionConstructorAccessorImpl.java :30)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:4 94)
> at
> com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeser ializer.java:270)
>
> at
> com.caucho.hessian.io.JavaDeserializer.readMap(JavaDeseriali zer.java:139)
> ... 36 more
>
Previous Topic:Modular JPA
Next Topic:Riena Snippets (call for action)
Goto Forum:
  


Current Time: Thu Oct 30 14:30:17 GMT 2014

Powered by FUDForum. Page generated in 0.02988 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software