Home » Archived » Riena » Using Riena and JodaTime
| | | | |
| Re: Using Riena and JodaTime [message #10534 is a reply to message #10407] |
Mon, 08 September 2008 09:09   |
 Christian Campo
Messages: 597
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 |
Christian Campo
Messages: 597
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 #574497 is a reply to message #10407] |
Mon, 08 September 2008 09:09 |
Christian Campo
Messages: 597
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 |
Christian Campo
Messages: 597
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
>>
|
|
| |
Goto Forum:
Current Time: Fri Nov 08 23:53:52 GMT 2024
Powered by FUDForum. Page generated in 0.05027 seconds |
] 
Search
Help
Register
Login
Home
