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:[EMAIL PROTECTED]
> Gesendet: Montag, 25. April 2005 23:36
> An: Javier Delgadillo
> Cc: [email protected]
> 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 <[EMAIL PROTECTED]> 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
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/