Apologies for the triple post, but power just glitched here again, and my mail hiccuped.
-SMD ----- Original Message ----- From: "Steve Downey" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Friday, August 15, 2003 10:25 PM Subject: Re: UUID Reuse proposal > I've posted a version of a UUID class previously that meets the random > number version of the leech spec. > > Getting MAC addresses portably is mildly difficult, and requires root access > on most systems. Using a cryptographically good random number generator is a > reasonably good alternative, and if done right, won't collide with the UUIDs > generated using MAC addresses. > > I've used them heavily for synthetic primary keys in database tables. > > If there's interest, I could repost the class. > > -SMD > ----- Original Message ----- > From: "Phil Steitz" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Friday, August 15, 2003 7:11 PM > Subject: RE: UUID Reuse proposal > > > > Having looked now at both implementations (assuming the axis impl is > what's > > in CVS at > > > http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis/component > s/uuid/), > > I agree that the tyrex implementation is better for two reasons: > > > > 1. It appears to be threadsafe. > > > > 2. It allows the node ID to be read from a properties file (getting around > > the inaccessability of the MAC address in Java). > > > > The axis implementation uses random bits from a SecureRandom initialized > in > > a static initialization block for the node ID. I don't see the big value > in > > a UUID implementation that uses random bits for the node ID. While you > can > > get very low probability of collision like this, it is no longer > > guaranteed, so why not just use a purely random string (which lang already > > has in RandomStringUtils)? The only value that remains in the UUID > > algorithm when you remove the "U" is that it is a standard and you can > > decompose it into the time bits and the node bits. > > > > I do like the idea of lang providing a home for "IdentifierUtils" suitably > > named and packaged. There are really multiple types here: > > > > * UUID (pseudo) standard, non-random, non-secure > > * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils) > > * Random, "secure", not guaranteed unique (e.g. Tomcat session IDs) > > * Part random, "secure", guaranteed unique (what Tomcat really needs ;-) > > * Bounded sequential(e.g. Betwixt's io identifiers) > > * Cyclic > > > > I am still +1 for including a good implementation of the UUID pseudo-spec. > > Starting with the tyrex base would probably be easier; but we could > > certainly just add the necessary features to the axis impl. > > > > Phil > > > > > > --- Tim Anderson <[EMAIL PROTECTED]> wrote: > > > Tyrex also provides support for UUID generation, and > > > should perform better than the Axis impl. > > > > > > See > > > > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se > > > rvices/UUID.java?rev=1.6 > > > > > > -Tim > > > > > > > -----Original Message----- > > > > From: Tim Reilly [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, 15 August 2003 11:32 AM > > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > > Subject: UUID Reuse proposal > > > > > > > > > > > > I'd like to ask the axis developers to donate the java package > > > > org.apache.axis.components.uuid to the Jakarta commons. > > > > > > > > I'm cross-posting this message on both jakarta commons-dev list > > > > and axis-dev > > > > list as commons could adopt this package and place somewhere > > > > sensible to the > > > > commons. My suggestion would be as an addition to > > > org.apache.commons.lang > > > > since the UUID is a special/complex type (aren't all classes, but > > > > hopefully > > > > you know what I'm saying.) > > > > I know not to cross-post but given the request it only makes sense. I > > > > realize the package has some basis on the similar package in the BSD > > > > licensed http://sourceforge.net/projects/juddi/ project. It doesn't > > > make > > > > sense to include the UUIDGenFactory, which would remain in place > > > (unless > > > > anyone has good ideas on making it more generic?) > > > > > > > > The reason for this request is that the package is nicely written > > > > (kudos to > > > > the author(s)), and very useful in a number of applications. The > > > Jetspeed > > > > developers can use this package; however it does not necessarily > > > > make sense > > > > for Jetspeed to create a dependency on the axis jar, solely to use > this > > > > package. There are numerous other applications of UUID's that make it > > > an > > > > ideal candidate for the Jakarta-commons, and I feel that > > > donating/adopting > > > > this package within the commons fits nicely with the vision of > > > > the commons. > > > > Other uses abound, for example struts could use the classes to > > > guarantee a > > > > form is submitted only once. A search of theserverside.com brings > > > > back some > > > > patterns that use guid/uuid. > > > > > > > > I'd be willing to send the patches to the Axis team if the commons > > > > committers are willing to adopt the package and Axis wishes the same. > > > > Basically this would be to depreciate > > > > org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend > > > > org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the > > > > "org.apache.axis.components.uuid.SimpleUUID" strings within the CVS. > Or > > > if > > > > there is a better way.. I'd be will to do whatever is agreed upon. > > > > > > > > Please consider this request; I'll keep an eye on each list and if > both > > > > projects agree that would be great and we can proceed. > > > > A lesser alternative would be for jakarta-commons to adopt the > > > > package, but > > > > axis makes no changes. This is the perhaps the lesser approach since > > > reuse > > > > is not fully accomplished but if the Axis committers are reluctant > then > > > > perhaps they could give their "okays" to the lesser approach, and > > > > jakarta-commons could still adopt the classes. > > > > > > > > For more information on UUID: > > > > Per javadoc comment - > > > > * A Universally Unique Identifier (UUID) is a 128 bit number generated > > > > * according to an algorithm that is guaranteed to be unique in time > and > > > > space > > > > * from all other UUIDs. It consists of an IEEE 802 Internet Address > and > > > > * various time stamps to ensure uniqueness. For a complete > > > specification, > > > > * see > > > > ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt [leach]. > > > > > > > > Thank you for considering. > > > > -Tim Reilly > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site design software > > http://sitebuilder.yahoo.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]