Re[6]: Gump & VM

2005-12-16 Thread Alexey Panchenko
Jörg Schaible wrote: >>> This violates the requirement to recalculate the creation time from >>> the id ... >> >> Why do you need to recalculate the creation time from the id ? > This is simply part of the requirement! TimeBasedAlphanumericIdentifierGenerator ? btw, this is not mentioned in th

Re[4]: Gump & VM

2005-12-16 Thread Alexey Panchenko
Jörg Schaible wrote: >> Probably you should look at java.rmi.server.UID -- the millis are >> checked only when internal counter reaches its limit. > This violates the requirement to recalculate the creation time from > the id ... Why do you need to recalculate the creation time from the id ? Us

Re[2]: Gump & VM

2005-12-15 Thread Alexey Panchenko
Jörg Schaible wrote: > Well, no, the id generator should produce as many ids as possible. > The only requirement for this one is, that you can recreate the time > from the generated id and that the ids are generated in a natural > order. This is currently resolved by an internal counter that is >

Re: [fileupload] DefaultFileItem.getUniqueId and multiple class loaders

2005-09-27 Thread Alexey Panchenko
Mike S wrote: > Are there any suggestions as to the best way to modify the getUniqueId > method to return a unique ID across class loaders? We are thinking along the > lines of injecting a random number to concatenate with the static counter in > the DefaultFileItem, (or grabbing the start timesta

Re: [validator] EmailValidator string pattern

2005-09-14 Thread Alexey Panchenko
Tan Quach wrote: > The EmailValidator declares a constant called > String EMAIL_PATTERN = "/^(.+)@(.+)$/"; > However, this pattern accepts the following email address as valid: > [EMAIL PROTECTED]'night.com <[EMAIL PROTECTED]> System.out.println(EmailValidator.getInstance().isValid("[EMAIL P