They're created as soon as Apache's Hudson gets around to building them. It triggers a build any time someone commits source code, but the Hudson server can be quite bogged down sometimes - it could be anywhere from 5 minutes to a couple hours after a commit when it is actually built.
Generally within a few hours, I think you'll be pretty safe. If you want to try new stuff any faster, you should maintain your own trunk copy. HTH, Les On Fri, May 14, 2010 at 3:35 AM, Tauren Mills <[email protected]> wrote: > Les, > Thanks for tracking this down! I'll give the new version a try. > Just curious -- how often are maven snapshots created from trunk, and does > it happen at a certain time of the day? If I update to the latest snapshot, > would these changes be in it? Or should I just checkout trunk and mvn > install? > Thanks, > Tauren > > On Fri, May 14, 2010 at 2:30 AM, Les Hazlewood <[email protected]> > wrote: >> >> Hi Tauren, >> >> This is extremely odd. The key to these messages is here: >> >> 2010-05-13 02:06:14,767 DEBUG >> [org.apache.shiro.web.servlet.SimpleCookie] - Found string value >> [deleteMe] from Cookie [rememberMe] >> 2010-05-13 02:06:14,767 TRACE >> [org.apache.shiro.web.mgt.CookieRememberMeManager] - Acquired Base64 >> encoded identity [deleteMe] >> >> Basically the SimpleCookie implementation did this to delete a cookie >> (deleting a cookie is just setting a cookie with a maxAge=0): >> >> - get the 'rememberMe' javax.servlet.http.Cookie instance from the >> incoming request >> - use that same exact instance to set the maxAge=0 and change the >> value to 'delete' me >> - take that same instance and call response.addCookie to ensure the >> cookie was deleted on the outgoing response. >> >> Apparently however, that instance is not its own copy in some >> implementations (Wicket? Tomcat? who knows). So when we were setting >> that value on the request cookie to use on the outgoing response, we >> were overwriting the cookie value that apparently was trying to be >> read later on by the CookieRememberMeManager. Nasty stuff ;) >> >> So, I updated the cookie implementation to always write out 'fresh' >> (not shared) data to the response headers. I updated SHIRO-139 [1] to >> reflect this. It is all committed. Please try it out. >> >> All the exceptions in the stack trace you pasted was related to this. >> It should be all good to go now. >> >> Best, >> >> Les >> >> [1] https://issues.apache.org/jira/browse/SHIRO-139 > >
