You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Tim Reilly <ti...@consultant.com> on 2003/08/15 03:31:47 UTC
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
Re: UUID Reuse proposal
Posted by Steve Loughran <st...@iseran.com>.
Tim Reilly wrote:
> I'd like to ask the axis developers to donate the java package
> org.apache.axis.components.uuid to the Jakarta commons.
UUID creation is an important thing in many places (POI?), so, yes,
having a commons impl is a good thing.
The only worry I have is that it adds another core dependency to Axis,
and that makes build, test & use of the system harder. We have lots of
dependencies already, and, especially client-side, some people find this
(and the resultant size of axis) an issue. I have just been busy writing
a reflection based binding to commons-modeler, for example, so that if
that jar is there we can auto-register parts for JMX management, but if
it isnt, all still works.
>
> 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
>
Re: UUID Reuse proposal
Posted by Steve Loughran <st...@iseran.com>.
Tim Reilly wrote:
> I'd like to ask the axis developers to donate the java package
> org.apache.axis.components.uuid to the Jakarta commons.
UUID creation is an important thing in many places (POI?), so, yes,
having a commons impl is a good thing.
The only worry I have is that it adds another core dependency to Axis,
and that makes build, test & use of the system harder. We have lots of
dependencies already, and, especially client-side, some people find this
(and the resultant size of axis) an issue. I have just been busy writing
a reflection based binding to commons-modeler, for example, so that if
that jar is there we can auto-register parts for JMX management, but if
it isnt, all still works.
>
> 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
Re: UUID Reuse proposal
Posted by Steve Loughran <st...@iseran.com>.
Tim Reilly wrote:
> I'd like to ask the axis developers to donate the java package
> org.apache.axis.components.uuid to the Jakarta commons.
UUID creation is an important thing in many places (POI?), so, yes,
having a commons impl is a good thing.
The only worry I have is that it adds another core dependency to Axis,
and that makes build, test & use of the system harder. We have lots of
dependencies already, and, especially client-side, some people find this
(and the resultant size of axis) an issue. I have just been busy writing
a reflection based binding to commons-modeler, for example, so that if
that jar is there we can auto-register parts for JMX management, but if
it isnt, all still works.
>
> 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
>
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
Apologies for the triple post, but power just glitched here again, and my
mail hiccuped.
-SMD
----- Original Message -----
From: "Steve Downey" <st...@geowealth.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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" <st...@yahoo.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> <tm...@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 <tm...@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/main/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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
Apologies for the triple post, but power just glitched here again, and my
mail hiccuped.
-SMD
----- Original Message -----
From: "Steve Downey" <st...@geowealth.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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" <st...@yahoo.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> <tm...@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 <tm...@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/main/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
>
>
>
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
From: "Phil Steitz" <ph...@steitz.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, August 18, 2003 3:05 AM
Subject: Re: UUID Reuse proposal
<SNIP>
> Sorry, I had forgotten about the existing IdentifierUtils. I would
> suggest that all of the things above could be added there, at least to
> start.
>
As a long time user of a UUID class, I would suggest *not* adding it to the
existing IdentifierUtils class. There is more than enough behavior in a UUID
to warrant its own class, even if most of that behavior revolves around
creating immutable instances of itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
From: "Phil Steitz" <ph...@steitz.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, August 18, 2003 3:05 AM
Subject: Re: UUID Reuse proposal
<SNIP>
> Sorry, I had forgotten about the existing IdentifierUtils. I would
> suggest that all of the things above could be added there, at least to
> start.
>
As a long time user of a UUID class, I would suggest *not* adding it to the
existing IdentifierUtils class. There is more than enough behavior in a UUID
to warrant its own class, even if most of that behavior revolves around
creating immutable instances of itself.
Re: UUID Reuse proposal
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> Thanks for the positive response to adapting a UUID class in commons lang.
> [The Axis list has responded with favoring option 2 which is basically to
> not make changes at this time, but has no problem with use of the UUID code
> from Axis in the commons.]
> I'm looking for direction on next steps - I believe after answering the
> following questions; I would create an enhancement in bugzilla and attach
> patches or sources?
Yes. I would start by patching IdentifierUtils (see below) to add some
additional methods, assuming that there are no objections to this approach.
>
> I think at this time there are two questions to resolve:
>
> ~1) Where to place the UUID code.
> I personally prefer a package and separate classes as Phil Steitz suggests:
> "
>
>>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 believe the alternative is to add the UUID code to the existing
> IdentifierUtils.java.
Sorry, I had forgotten about the existing IdentifierUtils. I would
suggest that all of the things above could be added there, at least to
start.
> (As a user of the library I believe it would be much easier to locate and so
> more valuable to have in a "suitably named package" of IdentifierUtils.)
>
> ~2) Which UUID implementation to use:
> Tim Anderson suggested using:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
> rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know
> if there are any issues with the license on this. It seems it would be okay
> as long as this license information were included along with the apache
> license in the source. (Would we also need an additional UUID-License.txt?
> I'm not sure how to interpret item 2 of license) The alternative is to use
> the Axis UUID and add features such as those in Tyrex's later. If a real
> issue exists I could try contacting them so find a suitable solution.
I don't know about the license, but as I said above, I like the tyrex
impl better. In any case, making the implementation threadsafe would be
a good idea, as would (IMHO) allowing the node ID to be read from a
properties file. I would also be interested in others' opinions on the
value of the UUID "standard", especially minus the MAC address.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: UUID Reuse proposal
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> Thanks for the positive response to adapting a UUID class in commons lang.
> [The Axis list has responded with favoring option 2 which is basically to
> not make changes at this time, but has no problem with use of the UUID code
> from Axis in the commons.]
> I'm looking for direction on next steps - I believe after answering the
> following questions; I would create an enhancement in bugzilla and attach
> patches or sources?
Yes. I would start by patching IdentifierUtils (see below) to add some
additional methods, assuming that there are no objections to this approach.
>
> I think at this time there are two questions to resolve:
>
> ~1) Where to place the UUID code.
> I personally prefer a package and separate classes as Phil Steitz suggests:
> "
>
>>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 believe the alternative is to add the UUID code to the existing
> IdentifierUtils.java.
Sorry, I had forgotten about the existing IdentifierUtils. I would
suggest that all of the things above could be added there, at least to
start.
> (As a user of the library I believe it would be much easier to locate and so
> more valuable to have in a "suitably named package" of IdentifierUtils.)
>
> ~2) Which UUID implementation to use:
> Tim Anderson suggested using:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
> rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know
> if there are any issues with the license on this. It seems it would be okay
> as long as this license information were included along with the apache
> license in the source. (Would we also need an additional UUID-License.txt?
> I'm not sure how to interpret item 2 of license) The alternative is to use
> the Axis UUID and add features such as those in Tyrex's later. If a real
> issue exists I could try contacting them so find a suitable solution.
I don't know about the license, but as I said above, I like the tyrex
impl better. In any case, making the implementation threadsafe would be
a good idea, as would (IMHO) allowing the node ID to be read from a
properties file. I would also be interested in others' opinions on the
value of the UUID "standard", especially minus the MAC address.
Phil
RE: UUID Reuse proposal
Posted by Tim Reilly <ti...@consultant.com>.
Thanks for the positive response to adapting a UUID class in commons lang.
[The Axis list has responded with favoring option 2 which is basically to
not make changes at this time, but has no problem with use of the UUID code
from Axis in the commons.]
I'm looking for direction on next steps - I believe after answering the
following questions; I would create an enhancement in bugzilla and attach
patches or sources?
I think at this time there are two questions to resolve:
~1) Where to place the UUID code.
I personally prefer a package and separate classes as Phil Steitz suggests:
"
>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 believe the alternative is to add the UUID code to the existing
IdentifierUtils.java.
(As a user of the library I believe it would be much easier to locate and so
more valuable to have in a "suitably named package" of IdentifierUtils.)
~2) Which UUID implementation to use:
Tim Anderson suggested using:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know
if there are any issues with the license on this. It seems it would be okay
as long as this license information were included along with the apache
license in the source. (Would we also need an additional UUID-License.txt?
I'm not sure how to interpret item 2 of license) The alternative is to use
the Axis UUID and add features such as those in Tyrex's later. If a real
issue exists I could try contacting them so find a suitable solution.
The license is inlined here:
#######
/**
* Redistribution and use of this software and associated documentation
* ("Software"), with or without modification, are permitted provided
* that the following conditions are met:
*
* 1. Redistributions of source code must retain copyright
* statements and notices. Redistributions must also contain a
* copy of this document.
*
* 2. Redistributions in binary form must reproduce the
* above copyright notice, this list of conditions and the
* following disclaimer in the documentation and/or other
* materials provided with the distribution.
*
* 3. The name "Exolab" must not be used to endorse or promote
* products derived from this Software without prior written
* permission of Intalio. For written permission,
* please contact info@exolab.org.
*
* 4. Products derived from this Software may not be called "Exolab"
* nor may "Exolab" appear in their names without prior written
* permission of Intalio. Exolab is a registered
* trademark of Intalio.
*
* 5. Due credit should be given to the Exolab Project
* (http://www.exolab.org/).
*
* THIS SOFTWARE IS PROVIDED BY INTALIO AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT
* NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* INTALIO OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Copyright 1999-2001 (C) Intalio Inc. All Rights Reserved.
#######
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: UUID Reuse proposal
Posted by Tim Reilly <ti...@consultant.com>.
Thanks for the positive response to adapting a UUID class in commons lang.
[The Axis list has responded with favoring option 2 which is basically to
not make changes at this time, but has no problem with use of the UUID code
from Axis in the commons.]
I'm looking for direction on next steps - I believe after answering the
following questions; I would create an enhancement in bugzilla and attach
patches or sources?
I think at this time there are two questions to resolve:
~1) Where to place the UUID code.
I personally prefer a package and separate classes as Phil Steitz suggests:
"
>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 believe the alternative is to add the UUID code to the existing
IdentifierUtils.java.
(As a user of the library I believe it would be much easier to locate and so
more valuable to have in a "suitably named package" of IdentifierUtils.)
~2) Which UUID implementation to use:
Tim Anderson suggested using:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone know
if there are any issues with the license on this. It seems it would be okay
as long as this license information were included along with the apache
license in the source. (Would we also need an additional UUID-License.txt?
I'm not sure how to interpret item 2 of license) The alternative is to use
the Axis UUID and add features such as those in Tyrex's later. If a real
issue exists I could try contacting them so find a suitable solution.
The license is inlined here:
#######
/**
* Redistribution and use of this software and associated documentation
* ("Software"), with or without modification, are permitted provided
* that the following conditions are met:
*
* 1. Redistributions of source code must retain copyright
* statements and notices. Redistributions must also contain a
* copy of this document.
*
* 2. Redistributions in binary form must reproduce the
* above copyright notice, this list of conditions and the
* following disclaimer in the documentation and/or other
* materials provided with the distribution.
*
* 3. The name "Exolab" must not be used to endorse or promote
* products derived from this Software without prior written
* permission of Intalio. For written permission,
* please contact info@exolab.org.
*
* 4. Products derived from this Software may not be called "Exolab"
* nor may "Exolab" appear in their names without prior written
* permission of Intalio. Exolab is a registered
* trademark of Intalio.
*
* 5. Due credit should be given to the Exolab Project
* (http://www.exolab.org/).
*
* THIS SOFTWARE IS PROVIDED BY INTALIO AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT
* NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
* INTALIO OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Copyright 1999-2001 (C) Intalio Inc. All Rights Reserved.
#######
RE: UUID Reuse proposal
Posted by Tim Anderson <tm...@netspace.net.au>.
The configured MAC address is supposed to be valid.
I think the original idea was that an installer
would generate the tyrex configuration file with a valid MAC
address, relating to one of those on the local machine.
And yes, it does change the version field if it falls
back to a random MAC address.
-Tim
> -----Original Message-----
> From: Steve Downey [mailto:steve.downey@geowealth.com]
> Sent: Saturday, 16 August 2003 1:30 PM
> To: Jakarta Commons Developers List; tma@netspace.net.au
> Subject: Re: UUID Reuse proposal
>
>
> That's not good, since your fake MAC address could conflict with someone
> else's real MAC address. If you're going to use random numbers for UUIDs,
> you need to change the version field, also.
>
> -SMD
> ----- Original Message -----
> From: "Tim Anderson" <tm...@netspace.net.au>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, August 15, 2003 10:37 PM
> Subject: RE: UUID Reuse proposal
>
>
> > 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
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: UUID Reuse proposal
Posted by Tim Anderson <tm...@netspace.net.au>.
The configured MAC address is supposed to be valid.
I think the original idea was that an installer
would generate the tyrex configuration file with a valid MAC
address, relating to one of those on the local machine.
And yes, it does change the version field if it falls
back to a random MAC address.
-Tim
> -----Original Message-----
> From: Steve Downey [mailto:steve.downey@geowealth.com]
> Sent: Saturday, 16 August 2003 1:30 PM
> To: Jakarta Commons Developers List; tma@netspace.net.au
> Subject: Re: UUID Reuse proposal
>
>
> That's not good, since your fake MAC address could conflict with someone
> else's real MAC address. If you're going to use random numbers for UUIDs,
> you need to change the version field, also.
>
> -SMD
> ----- Original Message -----
> From: "Tim Anderson" <tm...@netspace.net.au>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, August 15, 2003 10:37 PM
> Subject: RE: UUID Reuse proposal
>
>
> > 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
> >
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
That's not good, since your fake MAC address could conflict with someone
else's real MAC address. If you're going to use random numbers for UUIDs,
you need to change the version field, also.
-SMD
----- Original Message -----
From: "Tim Anderson" <tm...@netspace.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, August 15, 2003 10:37 PM
Subject: RE: UUID Reuse proposal
> 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" <st...@yahoo.com>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> > <tm...@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 <tm...@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
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
That's not good, since your fake MAC address could conflict with someone
else's real MAC address. If you're going to use random numbers for UUIDs,
you need to change the version field, also.
-SMD
----- Original Message -----
From: "Tim Anderson" <tm...@netspace.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, August 15, 2003 10:37 PM
Subject: RE: UUID Reuse proposal
> 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" <st...@yahoo.com>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> > <tm...@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 <tm...@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
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
RE: UUID Reuse proposal
Posted by Tim Anderson <tm...@netspace.net.au>.
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" <st...@yahoo.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> <tm...@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 <tm...@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
>
>
RE: UUID Reuse proposal
Posted by Tim Anderson <tm...@netspace.net.au>.
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" <st...@yahoo.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> <tm...@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 <tm...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
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" <st...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<tm...@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 <tm...@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/main/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
>
>
>
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
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" <st...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<tm...@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 <tm...@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/main/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
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
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" <st...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<tm...@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 <tm...@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/main/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
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
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" <st...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<tm...@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 <tm...@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/main/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
>
>
>
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
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" <st...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<tm...@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 <tm...@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/main/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
Re: UUID Reuse proposal
Posted by Steve Downey <st...@geowealth.com>.
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" <st...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<tm...@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 <tm...@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/main/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
>
>
>
RE: UUID Reuse proposal
Posted by Phil Steitz <st...@yahoo.com>.
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/components/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 <tm...@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/main/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
RE: UUID Reuse proposal
Posted by Phil Steitz <st...@yahoo.com>.
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/components/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 <tm...@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/main/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
RE: UUID Reuse proposal
Posted by Tim Anderson <tm...@netspace.net.au>.
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: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
>
>
RE: UUID Reuse proposal
Posted by Tim Anderson <tm...@netspace.net.au>.
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: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