>So will the stream based WSS4J solve this issue? If so, is there a ticket for >it that I can track?
Yes, stream based WSS4J will not load the whole message if it is not needed. You can track https://issues.apache.org/jira/browse/WSS-359 in WSS4J. It is planned for WSS4J 2.0. >As a workaround, I'm trying to implement my own TimestampValidator which will >compare the timestamp with the time that the service is first invoked (i.e. >i'll create my own interceptor which will be at the top of the chain and stash >the current time on the MessageContext for the modified TimestampValidator to >use). Is this a good approach? Is there any other way of obtaining the time >that a cxf web service is first called? For me it is a valid workaround. Perhaps Colm can suggest the best approach. Andrei. -----Original Message----- From: kongar [mailto:[email protected]] Sent: Donnerstag, 25. Oktober 2012 22:31 To: [email protected] Subject: Re: WSS4J Timestamp expiring before large file transfer finishes Thanks Andrei and Dan for the replies. Definitely clears things up for me. So will the stream based WSS4J solve this issue? If so, is there a ticket for it that I can track? As it currently stands, it seems like CXF secured streaming will only work if the download time is less than what is configured by ws-security.timestamp.timeToLive (which is defaulted to 5 minutes). As a workaround, I'm trying to implement my own TimestampValidator which will compare the timestamp with the time that the service is first invoked (i.e. i'll create my own interceptor which will be at the top of the chain and stash the current time on the MessageContext for the modified TimestampValidator to use). Is this a good approach? Is there any other way of obtaining the time that a cxf web service is first called? -- View this message in context: http://cxf.547215.n5.nabble.com/WSS4J-Timestamp-expiring-before-large-file-transfer-finishes-tp5717348p5717461.html Sent from the cxf-user mailing list archive at Nabble.com.
