commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Anderson" <...@netspace.net.au>
Subject RE: UUID Reuse proposal
Date Sat, 16 Aug 2003 02:37:06 GMT
The Tyrex implementation doesn't attempt to get the
MAC address from the system, but loads it from a configuration
file.
If the address isn't configured, it falls back to using
a random no. for the MAC address.

-Tim

> -----Original Message-----
> From: Steve Downey [mailto:steve.downey@geowealth.com]
> Sent: Saturday, 16 August 2003 12:26 PM
> To: Jakarta Commons Developers List
> 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" <steitzp@yahoo.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
> <tma@netspace.net.au>
> 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 <tma@netspace.net.au> 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/mai
> n/tyrex/se
> > > rvices/UUID.java?rev=1.6
> > >
> > > -Tim
> > >
> > > > -----Original Message-----
> > > > From: Tim Reilly [mailto:tim.reilly@consultant.com]
> > > > Sent: Friday, 15 August 2003 11:32 AM
> > > > To: axis-dev@ws.apache.org; commons-dev@jakarta.apache.org
> > > > 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: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > http://sitebuilder.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



Mime
View raw message