You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Werner Dittmann <We...@t-online.de> on 2005/05/06 10:07:30 UTC
Re: AW: Created Element
Ian, all,
thanks for the code. I modified it a bit and put it into our source tree.
Before I really start to use it to create timestamps in the current
implementation
I like to ask if the use of timestamps that include milliseconds would
pose any
interop problems in current deployments.
Receiving timestamps in both formats is not a problem (thanks to Ian's
code).
I would not like to support new timestamps and old ones (without
milliseconds)
in parallel during creation of timestamps. This would require yet another
configuration/deployment parameter - and we already have quite a lot of it.
Any thoughts to use the new timestamp format? Comments are highly
appreciated.
TIA.
Regards,
Werner
Ian Springer schrieb:
> Hi,
>
> In case its of interest to anyone, a while back I wrote a Java
> DateFormat for formatting/parsing xsd:dateTime's. The parse() method
> was snarfed from an Axis utility method with better error reporting
> added. It's pretty robust. The format() method uses: new
> SimpleDateFormat( "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" ).parse( date ).
> Source file and test case attached.
>
> Cheers,
> Ian
>
> Dittmann Werner wrote:
>
>> Javier,
>>
>> WSS4J uses the following format to parse
>> the times:
>>
>> SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")
>>
>> thus we don't parse milliseconds.
>>
>> Regards,
>> Werner
>>
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Davanum Srinivas [mailto:davanum@gmail.com] Gesendet: Montag,
>>> 25. April 2005 23:36
>>> An: Javier Delgadillo
>>> Cc: fx-dev@ws.apache.org
>>> Betreff: Re: Created Element
>>>
>>>
>>> Javier,
>>>
>>> don't remember running into any vendor who uses milliseconds...all
>>> that the spec
>>> (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
>>>
>>
>> message-security-1.0.pdf)
>> says is:
>>
>> The <wsu:Timestamp> element provides a mechanism for expressing the
>> creation and expiration times of the security semantics in a message.
>> All times MUST be in UTC format as specified by the XML Schema type
>> (dateTime). It should be 1300 noted that times support time precision
>> as defined in the XML Schema specification.
>>
>> it's an interop thing....
>>
>> thanks,
>> dims
>>
>> On 4/25/05, Javier Delgadillo <jd...@esri.com> wrote:
>>
>>
>>>
>>> All,
>>> We were doing some inter-operability tests with webMethods Glue. They
>>> produce the following timestamp:
>>> <wsse:Created>2005-04-15T00:47:01.792Z</wsse:Created>
>>> webMethods has stated they have some versions in QA that will fix
>>> the prefix
>>> and correctly mark it as wsu. My question is about the milliseconds
>>> in the
>>> actual timestamp. Even after fixing the prefix, the wss4j libraries
>>> throw
>>> an exception trying to parse the actual timestamp.
>>> I haven't been able to validate whether or not the milliseconds are
>>> allowed
>>> here.
>>> Has anyone else run into this? How can I make wss4j parse the
>>> timestamp
>>> correctly, assuming the milliseconds are valid?
>>> --- Javier Delgadillo
>>> ESRI Internet Solutions Division
>>> (909) 793-2853 x1068
>>> http://arcweb.esri.com/sc/index.html
>>>
>>
>>
>>
>>
>>
Re: AW: Created Element
Posted by Ian Springer <ip...@apache.org>.
Werner,
No prob, glad you were able to use it.
As far as whether you guys should include milliseconds in dateTimes you
produce, I'd think about how clients will use the timestamps and if the
added precision of milliseconds would ever be valuable to them. If so,
I'd include the milliseconds. If not, I think you could go either way.
Regards,
Ian
Werner Dittmann wrote:
> Ian, all,
>
> thanks for the code. I modified it a bit and put it into our source tree.
>
> Before I really start to use it to create timestamps in the current
> implementation
> I like to ask if the use of timestamps that include milliseconds would
> pose any
> interop problems in current deployments.
>
> Receiving timestamps in both formats is not a problem (thanks to Ian's
> code).
>
> I would not like to support new timestamps and old ones (without
> milliseconds)
> in parallel during creation of timestamps. This would require yet another
> configuration/deployment parameter - and we already have quite a lot
> of it.
>
> Any thoughts to use the new timestamp format? Comments are highly
> appreciated.
>
> TIA.
>
> Regards,
> Werner
>
> Ian Springer schrieb:
>
>> Hi,
>>
>> In case its of interest to anyone, a while back I wrote a Java
>> DateFormat for formatting/parsing xsd:dateTime's. The parse() method
>> was snarfed from an Axis utility method with better error reporting
>> added. It's pretty robust. The format() method uses: new
>> SimpleDateFormat( "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" ).parse( date ).
>> Source file and test case attached.
>>
>> Cheers,
>> Ian
>>
>> Dittmann Werner wrote:
>>
>>> Javier,
>>>
>>> WSS4J uses the following format to parse
>>> the times:
>>>
>>> SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")
>>>
>>> thus we don't parse milliseconds.
>>>
>>> Regards,
>>> Werner
>>>
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Davanum Srinivas [mailto:davanum@gmail.com] Gesendet: Montag,
>>>> 25. April 2005 23:36
>>>> An: Javier Delgadillo
>>>> Cc: fx-dev@ws.apache.org
>>>> Betreff: Re: Created Element
>>>>
>>>>
>>>> Javier,
>>>>
>>>> don't remember running into any vendor who uses milliseconds...all
>>>> that the spec
>>>> (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
>>>>
>>>
>>>
>>> message-security-1.0.pdf)
>>> says is:
>>>
>>> The <wsu:Timestamp> element provides a mechanism for expressing the
>>> creation and expiration times of the security semantics in a message.
>>> All times MUST be in UTC format as specified by the XML Schema type
>>> (dateTime). It should be 1300 noted that times support time precision
>>> as defined in the XML Schema specification.
>>>
>>> it's an interop thing....
>>>
>>> thanks,
>>> dims
>>>
>>> On 4/25/05, Javier Delgadillo <jd...@esri.com> wrote:
>>>
>>>
>>>>
>>>> All, We were doing some inter-operability tests with webMethods
>>>> Glue. They
>>>> produce the following timestamp:
>>>> <wsse:Created>2005-04-15T00:47:01.792Z</wsse:Created> webMethods
>>>> has stated they have some versions in QA that will fix the prefix
>>>> and correctly mark it as wsu. My question is about the
>>>> milliseconds in the
>>>> actual timestamp. Even after fixing the prefix, the wss4j
>>>> libraries throw
>>>> an exception trying to parse the actual timestamp. I haven't been
>>>> able to validate whether or not the milliseconds are allowed
>>>> here. Has anyone else run into this? How can I make wss4j parse
>>>> the timestamp
>>>> correctly, assuming the milliseconds are valid?
>>>> --- Javier Delgadillo
>>>> ESRI Internet Solutions Division
>>>> (909) 793-2853 x1068
>>>> http://arcweb.esri.com/sc/index.html
>>>
>>>
>>>
>>>
>>>
>>>
>
>