| Home » Archived » Riena » Using Riena and JodaTime
 Goto Forum:| 
| Using Riena and JodaTime [message #10243] | Thu, 04 September 2008 02:37  |  | 
| Eclipse User  |  |  |  |  | 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 #10534 is a reply to message #10407] | Mon, 08 September 2008 05:09   |  | 
| Eclipse User  |  |  |  |  | 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 11:44   |  | 
| Eclipse User  |  |  |  |  | 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 05:01  |  | 
| Eclipse User  |  |  |  |  | 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 04:28  |  | 
| Eclipse User  |  |  |  |  | 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 12:17  |  | 
| Eclipse User  |  |  |  |  | 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 04:34  |  | 
| Eclipse User  |  |  |  |  | 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 09:37  |  | 
| Eclipse User  |  |  |  |  | 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 05:09  |  | 
| Eclipse User  |  |  |  |  | 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 11:44  |  | 
| Eclipse User  |  |  |  |  | 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 05:01  |  | 
| Eclipse User  |  |  |  |  | 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
 >
 |  |  |  | 
 
 
 Current Time: Fri Oct 31 07:21:31 EDT 2025 
 Powered by FUDForum . Page generated in 0.06691 seconds |