Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 47919 invoked from network); 24 Dec 2003 22:22:55 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 24 Dec 2003 22:22:55 -0000 Received: (qmail 21810 invoked by uid 500); 24 Dec 2003 22:22:39 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 21752 invoked by uid 500); 24 Dec 2003 22:22:38 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 21739 invoked from network); 24 Dec 2003 22:22:38 -0000 Received: from unknown (HELO hume.tsdinc.steitz.com) (209.249.229.10) by daedalus.apache.org with SMTP; 24 Dec 2003 22:22:38 -0000 Content-Class: urn:content-classes:message Received: from Lavoie.tsdinc.steitz.com ([209.249.229.4]) by hume.tsdinc.steitz.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Dec 2003 17:22:36 -0500 Received: from steitz.com ([130.13.97.80]) by Lavoie.tsdinc.steitz.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Dec 2003 17:22:35 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <3FEA11AC.90102@steitz.com> Date: Wed, 24 Dec 2003 15:22:36 -0700 From: "Phil Steitz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jakarta Commons Developers List" Subject: Re: [lang] UUID Generator - was RE: UUID Generator? References: <20031224212151.1949.qmail@web60805.mail.yahoo.com> Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Dec 2003 22:22:35.0922 (UTC) FILETIME=[6EB63720:01C3CA6C] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N David Graham wrote: > --- Gary Gregory wrote: > >>So the question perhaps becomes: should we provide a 100% Java solution >>that >>is not the "best" solution or a hybrid solution on "named" platforms >>that is >>the *best* solution for that given platform? Personally (especially if >>the >>thread-based UuidClock proves to be unworkable in 'real' servers), I >>would >>rather go for one of the extremes: provide nada and point users to the >>article or provide the best (eventhough hybrid) solution. > > > Why not use a Strategy pattern for pluggable time implementations? The > default strategy would use the best 100% Java implementation possible. > Users could then decide to implement strategies using the Java 1.5 nano > second support or a native solution. I agree. This is what we have been talking about for use in [uid]. Phil > > David > > >>Gary >> >> >>>-----Original Message----- >>>From: Tim Reilly [mailto:tim.reilly@consultant.com] >>>Sent: Tuesday, December 23, 2003 22:50 >>>To: Jakarta Commons Developers List >>>Subject: RE: [lang] UUID Generator - was RE: UUID Generator? >>> >>>Hi Phil, >>> >>>I'm away for several days. I agree on the "clean room" uuid - I >> >>actually >> >>>got >>>something together last night. I'll have better connectivity after the >> >>1st >> >>>of the year, hope to share more then. >>> >>>-TR >>> >>> >>>>-----Original Message----- >>>>From: Phil Steitz [mailto:phil@steitz.com] >>>>Sent: Monday, December 22, 2003 3:24 PM >>>>To: Jakarta Commons Developers List >>>>Subject: Re: [lang] UUID Generator - was RE: UUID Generator? >>>> >>>> >>>>Tim Reilly wrote: >>>> >>>>Sorry for the response latency. See interspersed. >>>> >>>> >>>>>I guess the short answer is.. if Tyrex was thought to be a good >>>> >>>starting >>> >>>>>point, this is how Tyrex does it. >>>>>http://tyrex.sourceforge.net/api/tyrex/services/Clock.html >>>> >>>>(Same for OpenJMS >>>> >>http://openjms.sourceforge.net/xref/org/exolab/jms/util/Clock.html) >> >>>>>More on the clock issue: >>>>>System.currentTimeMillis has some resolution issues in >>>> >>>>different jvm's and >>>> >>>>>OS's. That's the rationale behind this clock. >>>>>>From JavaWorld article; >>>>>http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110- >>>> >>>timing.html >>> >>>>>"Java developers on Linux enjoy 1-millisecond (ms) resolution, >>>> >>>>while Windows >>>> >>>>>98 users suffer with 50-ms resolution. In most cases, the >>>> >>>>actual resolution >>>> >>>>>has nothing to do with the fact that System.currenTimeMillis()'s >>>> >>>return >>> >>>>>value is current time in milliseconds." Also a MAC vm bug: >>>>>http://developer.apple.com/qa/java/java20.html >>>> >>>>Thanks. I see the rationale now. >>>> >>>>>I agree within containers that forbid thread creation shouldn't >>>> >>>>be counted >>>> >>>>>out. >>>>>What if we had something like this: >>>>> >>>>>Uuid - Class representing a UUID. The recent post >>>> >>>>about kennewick >>>> >>>>> is a good start for this class I think. Thanks >>>> >>Jorg. >> >>>>>UuidGen - Generates UUIDs, one can ask for a version 1, >>>> >>>>2, 3, or 4. >>>> >>>>> Additionally, the default "clock" can be the >>>>>System.currentTimeMillis, >>>>> but a setClock method provided. If >>>> >>currentTimeMillis >> >>>>> is used then the CLOCK_SEQUENCE should be reset >>>> >>>>each call >>>> >>>>>b/c essentially >>>>> one can assume the time didn't move forward as >>>> >>>>it should. >>>> >>>>>UuidClock - Interface >>>>>UuidThreadClock - Gives the artifical time based on thread clock >>>>>UuidSystemClock - Gives the artifical time based on system clock >>>>>UuidFactory - Attempts to create the best Uuid for the >>>> >>system. >> >>>>Looks promising. An additional hurdle will obviously be the MAC >>> >>>address. >>> >>>> In terms of the Uuid class, I took a quick look at the kennewick >>> >>stuff >> >>>>and I agree that it looks reasonable. If we want to bring this in, >>>>however, we will need to get a software grant and go through the >>> >>apache >> >>>>incubator. Given that there is not really that much there, it might >>> >>be >> >>>>just as well to clean room it here in the jakarta commons sandbox. >>>> >>>>Phil >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Phil Steitz [mailto:phil@steitz.com] >>>>>>Sent: Wednesday, December 17, 2003 9:14 AM >>>>>>To: Jakarta Commons Developers List >>>>>>Subject: Re: [lang] UUID Generator - was RE: UUID Generator? >>>>>> >>>>>> >>>>>>Phil Steitz wrote: >>>>>> >>>>>> >>>>>>>Tim Reilly wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Phil, Tim, et al, >>>>>>>> >>>>>>>>I just added the thread lifecycle handling to the *draft* >>>>>>>>UuidClock.java I'd >>>>>>>>started >>>>>>>>For the timestamp of a version 1 uuid. >>>>>>>> >>>>>>>>I'll share it here. >>>>>>>>I realize it needs more work. I haven't tested it yet, but I >>>>>>> >>wanted >> >>>to >>> >>>>>>>>get >>>>>>>>some feedback before I do more. >>>>>>>> >>>>>>>>I'm not a committer on anything... would it be better to open >>>>>>> >>>>>>a bugzilla >>>>>> >>>>>> >>>>>>>>enhancement and add files like this that way? >>>>>>> >>>>>>> >>>>>>>Yes, it would be best to attach files to a Bugzilla ticket. I >>>>>> >>will >> >>>have >>> >>>>>>>a look this evening. Is this meant to be used with the axis >>>>>> >>impl? >> >>>>>> >>>>>>Tim, >>>>>> >>>>>>Can you provide a little more context on why we need this class >>>>> >>and >> >>>how >>> >>>>>>the overall solution will be structured? I am a little concerned >>>>> >>>about >>> >>>>>>the need to spawn a thread for the timer, since this should be >>>>> >>usable >> >>>in >>> >>>>>>container-managed environments. >>>>>> >>>>>>Phil >>>>>> >>>>> > === message truncated === > > > __________________________________ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.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