@Mark my use case was easier to understand maybe: we just needed to control and make not readable jvmroutes in urls Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
2014-02-14 14:27 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 14/02/2014 13:15, Rainer Jung wrote: >> I ran into a special requirement for the session id generator >> (uniqueness of session id for a longer time interval). While I think >> that the requirement needed isn't a useful general purpose extension, I >> stumbled over the fact, that the SessionIdGenerator class is not pluggable. >> >> Would it make sense to introduce a new interface for the session Id >> generation, probably including setJvmRoute(), setSessionIdLength() and >> generateSessionId(), letting the current implementation be the base >> implementation, probably switching getRandomBytes() to protected, and >> allowing to set the implementation class in ManagerBase - or the Manager >> interface (trunk)? >> >> I haven't worked it out in detail, but it looks easy to do and useful. >> >> WDYT? > > I'm struggling to understand the use case. Are you saying the current > implementation generates collisions? That would be bad given that > SecureRandom is being used. > > Ignoring the previous question, why can't the requirement be met with a > custom implementation of SecureRandom? > > If the requirement is to be certain that a duplicate session ID is not > generated I'd use a custom Manager and check the returned ID against > those currently in use request a new one in the highly unlikely event of > a duplicate being returned. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
