Hi Jens,

Supporting XmlGregorianCalendar would not be an issue, but it is not a commonly 
used data type.
Date objects don't have a timezone. In order to support those we would have to 
decide with timezone to use. GMT or the local timezone of client would be 
obvious choices. Any suggestions?

- Florian


On 01/11/2011 12:42, Jens Hübel wrote:
> Hi Chemistries,
> 
>  
> 
> the client API is pretty tolerant against various data types in a property 
> map. For example, byte, int, long etc are all accepted for an Integer 
> property which is  a BigInteger in Java.
> 
>  
> 
> However for DateTime the converter is very restrictive and just allows 
> GregorianCalendar. Wouldn't it be more consistent and friendlier if we would 
> also allow a java.util.Date and an XmlGregorianCalendar here and take care of 
> the conversion? Furthermore the error message is not very helpful: "Property 
> 'xyz' is a DateTime property!" doesn't tell you anything about the accepted 
> type. "Property xyz is of type x but expected is type y" would be much better.
> 
>  
> 
> Is there any reason for this I haven't seen? 
> 
>  
> 
> It also would be helpful for the client developers guide  to provide a code 
> fragment how to set custom properties of the various types. The section 
> "Advanced use of types" only describes how to read them. The fact that the 
> Map must not necessarily be a Map<String, String> as in the various examples, 
> but can also be a Map<String, Object> may not be so obvious for everyone (not 
> a big deal of course).
> 
>  
> 
> Jens
> 
>  
> 
> 

Reply via email to