Re: [logging] is setting context classloader correctly mandated by J2EE container specifications?
Simon Kitching wrote: I'm wondering if we need to provide a configurable Singleton strategy that the user of the library can set. We would provide a default singleton strategy but users could override that if the default behaviour doesn't result in correct Singleton behaviour. I think it's a good idea (my 2 cents) -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Align Commons Build and Commons Sandbox Build?
On Wed, 27 Oct 2004 11:15:25 +0200, Eric Pugh wrote: Hi all, Running into some annoying Maven problems w/ [email]. Dug into it and discovered that the jakarta-commons/commons-build is quite different from jakarta-commons-sandbox/sandbox-build files. This means that a project graduating from sandbox will build differently then expected. I'd like to change sandbox-build POM to match commons-build POM. Opinions? Eric I've lost track of what's going on. I see some sandbox projects build off commons-build and some off sandbox-build? Which is correct? If they are synchronized that would be great. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-id Using ClassLoader.getSystemResourceAsStream()
On Thu, 21 Oct 2004 11:58:51 -0500, Gregg, John E. wrote: Hi all, I'm having a little trouble with the fact that commons-id's ReadOnlyResourceStateImpl uses ClassLoader.getSystemResourceAsStream to load the config file containing MAC addresses. Is that intentional? It was intentional since I was thinking the commons-id.jar and the configuration xml should be deployed to the jre/lib/ext directory - Thought process was: this way all classloaders/contexts use the same file/MAC addresses regardless of application isolation. This is much less important for the ReadOnlyResourceStateImpl, but important for the ReadWriteStateImpl. Seperate applications or even jre instances (as in vertical clusters) should all use the same configuration. The real issue is that there's no good way I can think to get a device wide mutex/or lock. I'm thinking of using the locking mechanism from sandbox-transaction (a file based locking mechanism) ReadOnlyResourceStateImpl was a mistake on my part. I thought EJB containers would be alright with non-explicit i/o, such as ClassLoader.getSystemResourceAsStream but then I was reminded that accessing classloaders is also a no-no. Do you find this implementation useful?...let me know, I was going to remove it possibly. When I'm testing my app with Maven, the only thing in the system class loader's path is Maven's forehead jar. Perhaps I can/should change that, but it causes my test to fail because my config file isn't found. yes. I think there's a way in Maven to say that a resource is a test resource only, but I don't know how. I've actually got a comment in the project.xml for [id] that says something like I want this to be a test only resource, but don't know how If I use this.getClass().getResourceAsStream(), things are fine. I can understand why the system class loader is used, however, for that particular file-- because it's based on where the app is deployed and therefore is not portable, like the rest of the app is. I was reading When Singleton's aren't Singleton's, and so having the System classloader load the uuid stuff was what I was going for I think, although that's from memory. If you think it should change to use the app's class loader, I'll submit a patch. If you think it should stay the way it is, I might consider refactoring the load() method to use inversion of control so I can better test with mock objects and not worry about environmental concerns. If I do that I'll submit a patch. After knowing the rationale I had followed, let me know if you think there is a better way. I'm still learning, so maybe I've missed on this. I know the package and class organization is gross. I'm open to suggestions there as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sandbox Id project request...
Tolga,
I'll add them. Although they'll return UUID's not String's since
that's the type these generators return. Sorry to delay, I've been
super busy. Hopefully, I'll get some time towards the end of the week.
Thanks,
-Tim
On Fri, 15 Oct 2004 10:14:27 -0700, Tolga Yalcinkaya [EMAIL PROTECTED] wrote:
Can someone add the following method to
org.apache.commons.id.IdentifierUetils ?
public static String nextUUIDVersionFourIdentifier() {
return UUID_VERSION_FOUR_GENERATOR.nextIdentifier().toString();
}
There utility methods for all other id generators, but none for UUID
(version 1 or 4).
Thanks,
Tolga.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] bug id 30686
Have you used the proposed patch for your projects? No. I was evaluating validator or really just a handful of classes from validator when I stumbled upon my basic test case failing. Instead of just filing a bug I decided to track it down, and sent patches too! I can take some time this week to look at it. Great. I know I sounded unconfident about the patch, actually its that I'm not confident that with the addition of * its most efficient regular expression. I know little to nothing about how regex engines reduce the expressions and evaluate them. But I'm confident regarding the addition of 'zero or more' clause from Martin's comments and also looking at the spec Martin referenced. Also the thoroughness of the test cases. I'll integrate this class into my project (why not.) I'm still not finding where the js counter-part for this lives? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: New componenent: i18n
Hmmm.. package is/was specified in the parent pom. Which is why I'd assumed it was the capital I in the name element instead of lower-case. Changing it to lower case let me do $maven jar ... but you're right I just assumed that once 'jar' was finding something to compile then javadoc would run too. Apologies for not testing. I'm still head scratching as to why it's needed to pull package out of the parent pom, explicitly. On Sat, 09 Oct 2004 13:42:54 +0200, Jörg Schaible wrote: Daniel Florey wrote: Did javadoc creation worked for you?? Still don't get any javadocs. Sources have been found before as the jar was created, but javadocs are still missing... Thanks, Daniel So what did you do? Just called maven? The default goal might be just to build the jar, but no docs. Call maven site for doc generation. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] handling exceptions in AbstractConfiguration implementations
Does the ASF and the FSF not get along? Philosophically Yes! The FSF philosophy is that software is a right. The Apache philosophy is basically give credit where credit is due, but your programs that are derived from ASL software need not be free, and may be commercial works. Sort of a socialism versus capitalism analogy. (Disclaimer - it's been way too long since studying Rousseau, Marx etc..so don't flame me if socialism isn't correct) From GNU - Copyleft licenses such as the GNU GPL insist that modified versions of the program must be *free software as well*. Non-copyleft licenses do not insist on this. Part of the GPL on derivative work; You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Ok, so FSF is ALL about free software and keeping it free. The GPL is all about making sure commercial programs don't swipe the code to make an enhanced for profit version. But then there's the LGPL basically created as to allow shared library code to be used by proprietary vendors as well. The problem as I see it is that the LGPL was written with C/C++ in mind, thus the words linked, object code, object files etc, are used. For example; We use this license for certain libraries in order to permit *linking* those libraries into non-free programs. - the relevance of the wording in regards to Java, scripted languages etc, makes everything less than clear. Well, the FSF is coming up to its 20th anniversary. Perhaps, we can help them celebrate by asking them to reword the licenses in a more language neutral manner. I have no legal background. I'm just expressing my own conclusions after researching this question, and trying to figure out what the problem was. On Thu, 07 Oct 2004 11:41:28 +0100, Ricardo Gladwell [EMAIL PROTECTED] wrote: Emmanuel Bourg wrote: Excluding LGPLed projects is just a political decision imho. Emmanuel Bourg Sorry for sounding newbie about this, but what exactly are the political difficulties to hosting LGPL and ASL projects on the apache.org domain. Does the ASF and the FSF not get along? Kind regards, -- Ricardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New componenent: i18n
Daniel,
Catching up on my emails for a moment...I noticed no one has replied
here, unless I missed it? Curious about your question I checked out
i18n ... hmm..seems: pomArtifactId comes from the name element and not
the id element. I recognize the error as possible missing package
element. In this case since project.xml in sandbox-build reads:
packageorg.apache.commons.${pom.artifactId.substring(8)}.*/package
... and you have a capital I18n in the name element... it didn't find
the sources for the package i18n. Just a letter-case thing.
Remember the ASL 2.0. in the project.xml
Below are 2 patches (with an additional thing (something I needed
once) in the patches. This line in project.properties and related in
the pom;
+commons.project.extendsUri=../sandbox-build/
Allowing parameterization of the relative path to sandbox-build
Index: project.properties
===
RCS file: /home/cvspublic/jakarta-commons-sandbox/i18n/project.properties,v
retrieving revision 1.3
diff -u -r1.3 project.properties
--- project.properties 6 Oct 2004 08:48:07 - 1.3
+++ project.properties 9 Oct 2004 01:50:09 -
@@ -34,3 +34,9 @@
# Jars set explicity by path.
#
maven.jar.xml-im-exporter = ${basedir}/lib/xml-im-exporter1.1.jar
+
+#
+# Commons specific
+#
+# Allow flexible checkout of these two projects
+commons.project.extendsUri=../sandbox-build/
Index: project.xml
===
RCS file: /home/cvspublic/jakarta-commons-sandbox/i18n/project.xml,v
retrieving revision 1.4
diff -u -r1.4 project.xml
--- project.xml 6 Oct 2004 08:48:07 - 1.4
+++ project.xml 9 Oct 2004 02:02:13 -
@@ -1,7 +1,23 @@
?xml version=1.0?
+!--
+ Copyright 2004 The Apache Software Foundation
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ --
project
- extend../sandbox-build/project.xml/extend
- nameCommons I18n/name
+ extend${commons.project.extendsUri}project.xml/extend
+
+ nameCommons i18n/name
idcommons-i18n/id
logo/images/i18n-logo-white.png/logo
urlhttp://jakarta.apache.org/commons/sandbox/i18n//url
@@ -21,10 +37,10 @@
iddflorey/id
email[EMAIL PROTECTED]/email
organizationApache Software Foundation/organization
- timezone+2/timezone
roles
roleJava Developer/role
/roles
+ timezone+2/timezone
/developer
/developers
hth,
-TR
On Mon, 4 Oct 2004 15:54:41 +0200, Daniel Florey [EMAIL PROTECTED] wrote:
Hi folks,
I'm a Slide committer for a while and now extracted a tiny package called
i18n that I found to be very useful in several projects in the past.
I wanted to add it to the sandbox, but unfortunately didn't even manage to
build the site with maven correctly. Everything works fine except the
javadoc generation.
The javadoc-plugin states that no sources can be found. I've upgraded to
javadoc plugin 1.7 but this won't help.
Can anyone of the maven experts around have a look at this problem? As I'm
very new to maven I think it's most likely fault.
I've just added the sources to the CVS ({sandbox}/i18n).
Many thanks in advance,
Daniel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[validator] UrlValidator
I'd posted this to commons-user back in July, never got an answer and went
on with my reqs using a regex instead.
I saw Martin's post today on a 1.1.3 release and figured I should I forward
this to see if it was a bug or only that fully 'resolved' urls are valid or
something and I was using incorrectly?
-Original Message-
From: Tim Reilly
Sent: Wednesday, July 28, 2004 11:53 AM
To: [EMAIL PROTECTED]
Subject: [validator] UrlValidator
First, I'm a newbie with validator, so maybe I'm just not using
it correctly.
I was hoping to use validator library to validate url strings
from a form. I'm finding the validation too strict for my use
case. I have a form and want to validate the the user entered a
valid url in 'simple user' terms of valid.
But...I added this test case/method to
org.apache.commons.validator.UrlTest; the url is valid from my POV.
public void testSanity() {
UrlValidator v = new UrlValidator();
assertTrue(v.isValid(http://www.google.com;));
}
But it fails.
Also testing http://www.google.com with:
isValidScheme : false
isValidAuthority : false
isValidPath : false
isValidQuery : true
isValidFragment: true
Can anyone explain the UrlValidator.isValidX ?
Why would query and fragment be valid (I guess because they
aren't specified. I'm good with that.)
But can't port and path be optional not specified as well?
Also why is the scheme (http://) not valid?
Oddly, the url http://www.google.com:80/test passes isValid(),
but fails isValidScheme(), etc..
Thanks,
-TR
(btw: Testing against HEAD / 1.1.3)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [validator] UrlValidator
Thanks Martin!
Then it appears I was using the is validScheme etc incorrectly and as well a
bug. I've open a bugzilla issue for the optional port and path issues.
I have started a patch for this.
Starting with the unit test:
The patch seems easy enough. In the arrays of test parts I'm adding empty
strings such as
- TestPair[] testPath = {new TestPair(/test1, true),
+ TestPair[] testPath = {new TestPair(, true),
+ new TestPair(/test1, true),
Question 1)
Which should be valid according to the rfc:
http://www.google.com
or
http://.google.com/
or both perhaps?
I'll adjust the test data accordingly.
Question 2)
On line 206 of UrlTest I'm confused by
new TestPair(, true)};
seems to be constructing a case where scheme may be EMPTY_STRING as valid.
I'd assumed scheme is always required of a url, but admit I've not read the
rfc you mentioned.
Question 3)
Changing the UrlValidator should be a matter of getting the regular
expression correct I believe(?) for the empty path parts.
One thought I had on port validation was to attempt to construct a
java.net.URL and do something like
if (u.getPort() 0 u.getDefaultPort() 0) {
return false;
}
which I think would mean the protocol handler for the scheme has a known
default port. Does this sound like a good approach? or is there a case where
someone has a protocol handler with default port that java.net.URL wouldn't
know about? Or a case where java.net.URL is going to throw
MalFormedUrlException where UrlValidator.isValid would otherwise return
true?
NP on the 1.1.4 status for me. If getting patches in can get it to 1.1.3
that'd be good too, either way.
Thanks,
-TR
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] how stable is id?
Hi Hernan, [Hernan Silberman wrote:] Just a quick query to check the staus/stability of the id component. With respect to the uuid package; everything is functional; however IMO it needs rework (all my naughty doings): - visibility, coupling, and maybe changes in package arrangement. I've been mentally blocked on it for a while. I'd like to add the persistence features Oliver Zeigermann suggested. The uuid's state classes could possible use a persistence abstraction at a higher level than where it is atm. If your using [id] I would recommend using some indirection - at least to the uuid functionality, so that if something changes you can manage it easily. Or pulling out what you need for now. The stuff Phil and Gary did is pretty eloquent/stable in my opinion. Judging from a quick look at CVS, things haven't changed too much recently. Please let me know if there are plans for a release in the near future. No release plans on the table. I do hope to have time in Sept to work on fixing the above if not sooner. Actually, if I wasn't architecturally challenged...probably more sooner. But no guess as to when a release might occur. Maybe Phil, or Gary, or others have more thoughts. Thanks, -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Committer rights for Brett Porter
+1 -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Collections] MultiMap status?
Maybe this article helps? I pointed people to it when we made it a convention to follow at work: http://www.jwz.org/doc/tabs-vs-spaces.html [Admittedly, it wasn't a real issue for us. We all used Eclipse anyhow, but I wanted us to follow Jakarta code conventions in case there was something for us to give back.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] util package
Right, I'm glad I asked. I realize now based on the feedback from Tim, Rob, Stephen, and Phil it was bad idea. From Stephen's post I realize I don't really want these util classes in the public api. The way it is now is fine by me. Thanks, -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Sandbox Id] How to persist?
Hi Oliver, I'm sorry I've not had time to look at this yet. Hopefully, over the weekend I will have some time. Thanks, -TR [Oliver Zeigermann wrote:] I have only modified the transaction package, not anything else and will not make any changes to the Id package, of course. I have checked in my stuff and class FileSequence in package org.apache.commons.transaction.file is the interesting one. Ok Looking forward to suggestions how efforts can be merged. Not sure if Phil has had a chance either, but I'll try to review soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs][Chainsaw]: Web start + external dependances + license=ouch
A quick but important correction... according to JSCH website: JSch 0.0.* was released under the GNU LGPL license. Later, we have switched over to a BSD-style license. --http://www.jcraft.com/jsch/LICENSE.txt So it's BSD-style. LGPL and GPL are more ambiguous AIUI, which may or might not have influenced the reponses you get. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vfs][Chainsaw]: Web start + external dependances + license=ouch
[Resending for log4j-dev list my original bounced/non-subscribed] A quick but important correction... according to JSCH website: JSch 0.0.* was released under the GNU LGPL license. Later, we have switched over to a BSD-style license. --http://www.jcraft.com/jsch/LICENSE.txt So it's BSD-style. LGPL and GPL are more ambiguous AIUI, which may or might not have influenced the reponses you get. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sandbox] active components?
Id Id is active. In terms of a release... we have some work to do on uuid stability and changing the api to match with jdk 1.5. The other identifiers have a longer history and spun-off from lang. Oliver Zeigermann has proposed some new work on sequence persistence. After that I'd imagine a release would be possible, but I don't have a set time-line in mind (except I need to get off my rear and get the uuid stuff square.) Thanks, -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ID] UUID in JDK 1.5
Noel J. Bergman wrote: FYI: http://java.sun.com/j2se/1.5.0/jcp/beta1/apidiffs/java/util/UUID.html Seems to me that it would make sense to have code in our library that provides a compatible interface. Phil Steitz wrote: Noel, I agree with you, and I don't see anything that would be difficult for us to provide there. We could fairly easily extend o.a.c.id.UUID to match the JDK 1.5 API. Am I missing anything, Tim? Sorry I didn't respond earlier. Ditto, makes sense to me as well. It should be easy enough to do. I still need to implement the version 3 uuid generation. Currently, we have version 1 and 4 (version 2 is reserved for backward compatibility.) The jdk 1.5 covers versions 3 and 4 (btw: thanks Noel, I hadn't seen this.) -- I wanted to post a next steps/to-do to get any thoughts on it: 1) Basic clean up. This is complete except the patches I'd sent caused some issues due to eol:CRLF. Need to fix. 2) Part of the patches I'd sent contained the option to indicate if Random or SecureRandom should be used in the version 4 generator. I will separate into a separate patch; or commit on my own depending on time-frames. 3) Make the modification to mirror the jdk 1.5 api (return NotYetImplemented from the version 3 calls until (4)) 4) Create the version 3 implementation. 5) As Phil indicated getting stability data from more and varied tests is probably in order. I'm thinking I might set up a long running multi-client test just for assurance sake. More unit tests. Performance data would be nice. 6) ... any thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[id] minor cleanup
I've been doing some house keeping, trivial things like updating any author
tags that are commons-Uid team to commons-Id team, adding any missing
@version tags, etc. It seems the header file has spaces that checkstyle
applies the white space checks to. I've changed the *[space] to *[nospace]
lines 3,7,9 and made the changes to all files. Does this sound ok?
Another question, is there a strong preference on the try.. } .. catch on a
new line;
try {
}
catch () {
}
versus one line;
try {
} catch () {
}
I'd like to make consistent throughout. I have no preference really, it's
also trivial and can be left as is.
Along the trival path; my preference is not to have ... I think the
checkstyle check is hides a field. I'd like to change the private boolean
wrap field to wrapping if desired, but I realize it may be over
stepping, so I'll wait for a go-ahead?
e.g.: this.wrap = wrap -to- this.wrapping = wrap
I've also added the option to make version four uuid optionally use
SecureRandom or Random, made the PRNG settable. As discussed added
IdentifierGeneratorFactory.uuidVersionOneGenerator() and
IdentifierGeneratorFactory.uuidVersionFourGenerator() code as well as -
IdentifierUtils.UUID_VERSION_ONE_GENERATOR and
IdentifierUtils.UUID_VERSION_FOUR_GENERATOR
I'll send patches for review following outcome the ?'s above.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] use of commons-logging
Since there is a dependency on commons-logging; any issues with using it?
For example in IdentifierGeneratorFactory.java line 53
-} catch (Exception ex) {
-// ignore as default implementation will be used.
+}
+catch (Exception ex) {
+if (log.isInfoEnabled()) {
+log.info(ex);
+}
There are two other similar places in the uuid packages I was think it might
be useful to log what's happening in the recoverable exceptions.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[id] hooking up UUID generation
Any thoughts on hooking-up the UUID generation like the other id generators? I was thinking something along these lines: either: IdentifierUtils.nextUUID([UUID.VERSION_ONE | UUID.VERSION_FOUR]); -or- IdentifierUtils.nextVersionOneUUID(); IdentifierUtils.nextVersionFourUUID([void | boolean:secure]); And same thought on the factory: either: IdentifierGeneratorFactory factory = IdentifierGeneratorFactory.newInstance(); UUIDGenerator generator = factory.uuidGenerator(UUID.VERSION_ONE | UUID.VERSION_FOUR); -or- VersionOneGenerator generator = factory.uuidVersionOneGenerator(); VersionFourGenerator generator = factory.uuidVersionFourGenerator(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] UUID update
I would attribute the cryptographic quality reference in section 4 as just referring to randomization. Making the PRNG pluggable might be a good compromise solution. Phil I think that sounds good, for the version 4 (random bytes) uuid (I think that's what you meant? - version 1 uses MD5 of system info or the MAC address.) The other calls to SecureRandom should be changed now that I understand more about Random randomness. I can send patches if or unless anyone wants to beat me to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] UUID update
Phil Steitz wrote: ... than updating the Apache license to 2.0. This is a good start. We need to get a better feel for stability / performance and some more eyeballs on this code, so I thought it best to get it into CVS now, even if we decide to refactor / repackage down the road. Thanks for the contribution. It is a lot easier to talk about when it's under source control. The more eyes for review the better, and as you mention below documenting the why's will be helpful to that end. Let me know your thoughts on additional tests. One I wanted to make sure of was the writes, and finalize in ReadWriteFileImpl all happen as expected. I imagine performance tests of anything using SecureRandom (VersionFourGenerator, and InMemoryStateImpl) may be dismal due to initialization. I think I did a static reference to the SecureRandom so it should be the first time that takes a while. Some other strategies can be built on top of what's there, like burst generation into a queue if need be. Some minimal xdocs, or more complete package documentation describing the implementation choices made would be a good thing to add about now. Most of this is in the code or mail archives, but it would be good to get it into the package docs or xdocs. Certainly. Hopefully, I can get this done as soon as possible - probably within the next few of days, sooner if I can. If you have not been following all of the commons-dev build stuff, you may have missed that you now need to co jakarta-commons-sandbox/sandbox-build to get the maven build to work. I did manage to catch-up on most of the list. I really appreciate Mark and other's effort doing this, I didn't want to have to checkout the entire commons tree or have to think about selecting which bits to checkout aside from [id] - so the change is welcome in my book...checking out as two eclipse projects is much smoother. It also alleviates my need for the commons.project.extendsUri=../sandbox-build/ which I was changing locally. Not sure if you want to keep it or not? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] UUID update
I will look at this stuff carefully this weekend, but one thing that jumped out at me from your post above was that the global lock issue might be avoidable by putting more into the node identifier, i.e., build in a jvm identifier. IIRC, this is essentially what tomcat when generating session ids to avoid collisions across jvms on the same host. Just something to think about. Phil I'm back. I'm thinking about this suggestion... My original concern is both with physical machines that run multiple jvm versions, as well as multiple instances of the same jvm (such as in an application server that is vertically clustered.) I don't know of an identifier that I can get that uniquely identifies a jvm instance, but there may be something (I'll dig around the tomcat code.) Coincidently, I do iterate the System properties and then create an MD5 of those concatenated with a random and a (new Object().hashCode()) to generate an artificial node id in StateHelper (used in the InMemoryStateImpl). Keep in mind, that *ideally* the Node.id is always the MAC address(s) though. I think I submitted quite a bit to digest in the zip file. Something that may make things easier all around might be if I start on creating patches just for the VersionFour uuid generator (random uuid)? We can workout naming, package structure, and how best to tie in the factory and IdentifierUtils. Afterwards, we can look at the decisions about the more complex/troublesome version 1 generator. If this sounds good to everyone I'll start a new thread around that? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] UUID update
I'll be traveling until March 1st - so I won't have much access to respond to comments or question regarding this post until after next week. However, looking forward to your thoughts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] UUID update
No worries. There is another - Bug id 25580 (originally opened under lang prior to the formation of sandbox id), which someone posted to today. I think that was the confusion. I will try to close that one. -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 9:52 PM To: 'Jakarta Commons Developers List' Subject: RE: [id] UUID update I appologize for this as I mistook the ticket as a [lang] and not [sandbox] ticket. Gary -Original Message- From: Tim Reilly [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 17:28 To: Jakarta Commons Developers List Subject: RE: [id] UUID update Hi Gary, [I wrote] I'll use bugzilla to attach what I've got so that everyone interested can review it. It'll not be in the form of patches yet Bugzilla link: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27022 [Gary resolved with RESOLVED WONTFIX] Resolved wontfix is fine (since, yes there is nothing to resolve or fix - just a way to post the zip for review.) But I'm unclear if there's more meaning to the resolution's comment: Please see http://jakarta.apache.org/commons/sandbox/id/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[id] Bugzilla suggestion to use existing implementations
[This is in reply the bugzilla comments added by Dominik Stadler for bug id 25580; I've changed that bug to resolved won't fix - since it is no longer applicable for lang and we now have the sandbox-id project.] --- Additional Comments From Dominik Stadler 2004-02-18 18:05 --- There are already various implementations available, maybe you can reuse or integrate one of them? I don't know how standard-conforming these are, though. http://dev.w3.org/cvsweb/java/classes/org/w3c/util/UUID.java?rev=1.2content -type=text/x-cvsweb-markup http://www2.kuh.kumamoto-u.ac.jp/jsato/java.htm http://ebxmlrr.sourceforge.net/ebxmlrr/apidocs/com/sun/ebxml/registry/util/U UID.html Hi Dominik, First, thanks for putting together this list of implementations to have a look at, and for the suggestion. I agreed with the thought to use some existing implementation around the time I opened the enhancement request and discussed on the mailing list. The problem with most implementations is due to incompatible licensing; we decided to create an implementation from scratch. These threads contains some history: http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED] akarta.apache.orgsearchText=uuiddefaultField=subjectSearch=Search After researching the IETF draft and re-reading it several times there are some issues with some of the implementations that are out there. The list you provide is fine; except again the licensing issues. I've done some work on the uuid generation if you'd like to review here is the posting I'd made last night: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15msgNo=43845 There is a zip a file attached to this bugzilla report http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27022 Some feedback on the list of implementations provided: The w3c implementation - looks like it's sound, it should be functionally equalivant to the VersionOneGenerator using an InMemoryStateImpl in the zip file referenced above. W3C license seems compatible, but we'd also have to distribute the NOTICE etc. The jsato implementation - uses the Runtime exec to call uuidgen. No problem here except afaik libuuid.so now generates version 4 uuid's, no option for a version 1 due to a security concern (or perhaps it's always been that way.) Also, I don't have a uuidgen command on windows, but if I'm reading the source correctly that's what it tries to call? It could be changed to make Window Script Host issue a CoCreateGUID() but anyhow. No mention of licensing terms. The ebxmlrr implementation - is technically fine (version 4 uuid) The sourceforge summary page claims Apache license which I assume means ASF like license. Looking at the actually source the copyright is attributed to SUN under the Sun Community License? com.sun is also in the package structure, so I assume Sun is a contributor to that project. The o.a.c.id.uuid.VersionFourGenerator in the zip file referenced above contains similar code. Thanks -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[id] UUID update
I'm writing tests, and getting ready to put some tentative documentation together for the uuid code I'd like to contribute. I've made some changes described below. (Note: I'm using http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-02.txt for the specification) Version 1 uuid generation in java is much more challenging perhaps than in native code for essentially three reasons: - Time resolution Java provides millisecond time resolution, the uuid spec calls for 100-nanosecond intervals since the Gregorian changeover epoch. The spec allows for artificial clocking in systems that do not provide the required time resolution. An additional challenge comes from the windows operating system and low time resolution issues. The effective resolution on windows can be from 1ms to reportedly 54ms. I create a NativeWin32ClockImpl implementation of the Clock interface, but its performance was miserable (~30 min for 11K timestamps), so not included. - Persisting state The uuid specification recommends persisting the clock sequence, node identifier, and last uuid timestamp to stable storage. The spec offers some hints of acceptable practices when writing to stable storage is not feasible on every single uuid generation call due to performance concerns. Additionally provisions are made for systems that do not have or can not use stable storage. In java this is not necessarily an issue, except some containers prevent file i/o, etc (which is for myself the first think that comes to mind when I hear stable storage.) - Device Wide Mutex's The version 1 algorithm calls for obtaining a system wide lock during uuid generation. Java virtual machines as far is know have no built in means of working with a system wide mutex (some workarounds; such as opening a socket, nio file locks, jni, are possible.) For java when multiple vm instances are running, or multiple vm's in general are running the uuid generator needs some way to know it is the only generator creating an id for the given timestamp, clock sequence, node identifier (mac address) at that instance. So to address these issues I've created two new packages, o.a.c.i.uuid.state, and o.a.c.i.uuid.clock, as well as an o.a.c.i.uuid.NodeManager interface. Various implementations are possible to work around the issues mentioned above. I've not used commons Discovery before (hint, hint, code review), but the intention is to allow discovery to locate the configured implementations. The clock package: Implementations of the o.a.c.i.uuid.clock.Clock interface may address the time resolution issue in different ways (for example if a system has available a java real-time library the implementer could use that.) The state package: Many diffent ways of addressing stable storage are possible, and the container in which the code must execute may determine what implemation is most appropriate. I've create 3 implementations; InMemoryOnlyImpl, ReadOnlyResourceImpl, and ReadWriteFileImpl. More implementations are possible; such as a jdbc, jndi, etc. [So long as some sort of locking is create or used] The NodeManager: The NodeManager implementation I've worked on makes the assumption that each jvm instance is assigned it's own node identifier (mac-address) Other implementations of the node manager could attempt to use the same set of node identifiers across vm's if they obtain a device wide lock; such as by opening a socket, using a file lock, etc. Other approaches to solving these issues are certainly possible. I could see where one might publish an rmi service on a known port to service uuid generation requests (the first vm to obtain the port would become the server, any additional vm's would become clients.) My intent is not to solve every possible implementation, but hopefully the three major spi's allow for flexibility in version 1 generation, and provide a few implementations that likely solve many of the requirements. I'll use bugzilla to attach what I've got so that everyone interested can review it. It'll not be in the form of patches yet (unless someone asks.) I wanted to get some opinions prior to creating patches and submitting for possible cvs commit. Additionally, I do have more tests todo and so I'm not sure certain what expectation within a sandbox project is in terms of stability of code. Some of the tests I want to do involve determining how each implementation performs, as well as what I'd consider integration tests (making sure the interaction between classes generates the correct events.) Other notes: With the number of classes this ends up being, I stopped prefixing everything with UUIDXxxxXxx since it's redundant with the package name and dropped the prefix from existing (this can be changed if there are objections.) I've added commons-codec as a dependency since the Hex.encode/decode methods are so handy. I'm assuming we want to keep dependencies at a minimum. Hope it's ok. The zip I'll attach to bugzilla is out of synch with head, but
RE: [lang] Array concat?
I've been trying to resist commenting (since I've not contributed anything
here) but I agree with Janek; an Array's join method has a different meaning
in other languages (ECMAScript, VBScript, and others). IMHO following the
expectations users have who know the other languages helps the usability of
the library.
e.g.
Object[] anArray = {one, two, three};
ArrayUtil.join(anArray, , );
outputs one, two, three
This would also compliment java.lang.String.split(regex);
Some other suggestions for the join name:
merge(Object[], Object[]) //Rename of join()
mergeNoDuplicates(Object[], Object[]) //Merges and eliminates duplicates
append(Object[], Object[]) //Convenience method calls merge a, b
append(Object[], Object) //Convenience method calls add
prepend(Object[], Object[]) //Convenience method calls merge b, a
prepend(Object[], Object) //Convenience method calls add using pos 0
join(Object[], String) //
http://www.devguru.com/Technologies/ecmascript/quickref/join.html
Instead of just throwing up ideas I decided to create these and so attached
are patches. The convenience methods aren't that important. It would be nice
to see the merge, mergeNoDuplicates, and join make it?
p.s. I didn't create test-cases at least for the time being. Let's see what
others think first. Hope the attachments make it, if not I can do
Bugzilla/Jira
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 8:45 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] Array concat?
Hello,
I've committed to HEAD three new ArrayUtils methods and unit tests:
add(Object[], Object)
add(Object[], int, Object)
join(Object[], Object[])
Please comment on method names or impl.
Thank you to Maarten for the patch the add methods are based on.
Ticket is: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26056
Gary
-Original Message-
From: Janek Bogucki [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 14:27
To: Jakarta Commons Developers List
Subject: RE: [lang] Array concat?
On Thu, 2004-01-29 at 12:05, Gary Gregory wrote:
Ah, I do recall join now, much better.
Thanks,
Gary
concat is the best choice because join implies the introduction of a
delimiter between the two arrays which is not the outcome, while append
implies the extension of an existing object somehow and arrays don't get
extended. To me, concat does hint at the production of a new object.
-Janek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: ArrayUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java,v
retrieving revision 1.37
diff -u -r1.37 ArrayUtils.java
--- ArrayUtils.java 30 Jan 2004 02:12:22 - 1.37
+++ ArrayUtils.java 30 Jan 2004 06:58:20 -
@@ -1279,36 +1279,36 @@
}
/**
- * pJoins the elements of the provided arrays into a single new array./p
+ * pMerges the elements of the provided arrays into a single new array./p
* pThe new array contains all of the element of the first array followed
* by all of the elements from the second array./p
*
* pre
- * ArrayUtils.join(null, null) = null
- * ArrayUtils.join(array1, null) = array1
- * ArrayUtils.join(null, array2) = array2
- * ArrayUtils.join([], []) = []
- * ArrayUtils.join([null], [null]) = [null, null]
- * ArrayUtils.join([a, b, c], [1, 2, 3]) = [a, b, c, 1, 2,
3]
+ * ArrayUtils.merge(null, null) = null
+ * ArrayUtils.merge(array1, null) = array1
+ * ArrayUtils.merge(null, array2) = array2
+ * ArrayUtils.merge([], []) = []
+ * ArrayUtils.merge([null], [null]) = [null, null]
+ * ArrayUtils.merge([a, b, c], [1, 2, 3]) = [a, b, c, 1, 2,
3]
* /pre
*
- * @param array1 the first array of values to join together, may be null
- * @param array2 the second array of values to join together, may be null
- * @return The new joined array, codenull/code if null array inputs.
- * The type of the joined array is the type of the first array.
+ * @param array1 the first array of values to merge together, may be null
+ * @param array2 the second array of values to merge together, may be null
+ * @return The new merged array, codenull/code if null array inputs.
+ * The type of the merged array is the type of the first array.
* @since 2.1
*/
-public static Object[] join(Object[] array1, Object[] array2) {
+public static Object[] merge(Object[] array1, Object[] array2) {
if (array1 == null) {
return array2;
} else if (array2 == null) {
return array1;
} else {
-Object[]
[codec] ibiblio maven
I noticed commons-codec 1.2 jar is not in http://www.ibiblio.org/maven I don't know if it's supposed to be? or if anyone has requested it be published there, but thought I'd ask? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] UUID sending more code and a question or two
That sounds like a PITA and I wonder if we are really thinking about this correctly. Interleaving JNI calls and comparing timestamps will be hard and ultimately inconclusive, IIUC. What exactly did you have in mind here? Why not run the native code, capture the output, and compare? Let me start from what brought me to testing the time against the C code. I was working on UUIDGenerator.java and once far enough along I felt I should compare the string output from a ms-guid to the values I generated. Reversing the time fields should have given me approximate values. It didn't. My next step was to add a test to tell me if the time I was generating was close to the time from someone else's uuid implementation. Going back to the ietf-draft was an easy choice since the appendix contains reference C code. After banging my head against the wall due to the time differences I'd get (which turned out to be an overflow in my C code.) The java time generation was fine, so I need to look elsewhere. I agree the JNI will be a PITA for me, especially since I'm re-learning C. I have a simple program working on Win2K and RH8. I'm not sure if the code would need to be recompiled for each target platform (at least making it an optional test might be good)? Perhaps running the test initially was sufficient? I'm not sure if Phil is minus on the JNI testing or for native code in the range test realizing what I'd proposed wouldn't work anyhow? Regardless, both points above are valid. The sample output (run2) below shows the interleaving calls not working which is logical without some delay in the calls, and as Noel suggests capture the output and compare would probably be the approach. I don't mind doing the jni (learn something new) but Phil are you minus on the jni range testing (past my own sanity tests here) or jni in the unit tests generally speaking? Sample output from my tests; right now I call an .exe using Runtime.exec... //Run 1 From C reference code 13294040293125 From java 13294040293125 From C reference code 132940402931562500 //Run 2 From C reference code 132940403477187500 From java 13294040347718 From C reference code 132940403477343750 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Change domains after faking a POST?
Its off topic for HttpClient (if I understand you need a transcoding proxy), but here are some resources that may help. You may want to have a look at some Jetspeed classes and related. Specifically the jetspeed.util.rewriter package, websurf portlet, and the webclipping portlet. http://jakarta.apache.org/jetspeed/api/org/apache/jetspeed/util/rewriter/pac kage-summary.html http://jakarta.apache.org/jetspeed/site/community-portlets.html http://jakarta.apache.org/jetspeed/site/portlet_config_WebClippingPortlet.ht ml Cocoon may also have some similar code as I recall. HTH -Original Message- From: D Alvarado [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 12:32 PM To: [EMAIL PROTECTED] Subject: Re: Re: Change domains after faking a POST? If you try and think this through carefully, you will see that the term in the context of will inadvertly lead to ambiguities. What about images referenced by the document, how must they be resolved? What about links to other domains, do we still have to use the proxy or can we just reach them directly? Please for the sake of the architecture of your application, do not blindly relay content to the client. The Http Proxy standard was specifically made for that purpose. So do not believe you can do better - you will fail terribly. Ok, well I definitely won't pursue the blind route. How would an HTTP Proxy behave in this situation? Surely it wouldn't parse out HTML. Also, not that this matters, but there will never be images or links, just the relative url in the action form tag. I have also considered the case that this situation has no elegant answer. If so, I will let this die. - Care2 make the world greener! Eighty-six nations have signed the international Framework Convention on Tobacco Control. Help get the U.S. on the list! http://www.care2.com/go/z/10840/1060 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[id] UUID sending more code and a question or two
I'd decided to test my time (clock) values against the example code in the
uuid draft. The problem was (a: I'm 10yrs rusty in C/C++) and b) I'd get
about a 34.07xx year difference in my return values versus what the C code
in the draft is giving. Eventually, I figured out to upcast the time
struct's return values to unsigned long long before multiplying and that
gave much better results. ... anyone see anything not ok, I think I'm ok
with this?
int main() {
struct timeval tp;
gettimeofday(tp, (struct timezone *)0);
/* Offset between UUID formatted times and Unix formatted times.
UUID UTC base time is October 15, 1582.
Unix base time is January 1, 1970.*/
unsigned long long offset = 0x01B21DD213814000;
printf (\nUUID w/o upcast: %llu, (tp.tv_sec * 1000) +
(tp.tv_usec * 10) + offset);
printf (\nUUID: %llu, ((unsigned long long)tp.tv_sec * 1000)
+ ((unsigned long long)tp.tv_usec * 10) + offset);
return 0;
}
With that I'll create a bugzilla enhancement to add the UUIDClock and
UUIDSystemClock code for review. UUIDClock has changed to an interface,
UUIDSystemClock uses the System class to get the time, without the thread
and other code to compensate for time resolution issues. The code that was
in UUIDClock I now have in a class called UUIDThreadClock (having some
issues with the unit tests seeming to hang, I'll send when I can get that
resolved).
It would be difficult for me to use the C code in the unit tests (but not
impossible I suppose.) I guess the question is .. should the unit tests have
this / JNI code? I felt it was important to test against the C reference
code in the UUID draft appendix, since any errors in implementation for this
code can't be fixed easily (the unique contract depends on correctly
implementing the spec.)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: refresh header proxy
Not to beat a dead horse... but I was surprised this is a non-standard header so for anyone interested here are my of interest links. As Odi mentions Netscape introduced the header (the meta tag is the html equivalent to the (non-standard) http header.) Early draft refers to the Refresh header but marks it TBS http://www.w3.org/Protocols/HTTP/1.1/spec.html#Refresh Later an issue from the working group says the follow: was not in the 1.1 spec, due to unexplored security implications Post from a 2000 w3c list. Good information for anyone implementing the behavior expected and wanting to know why 3xx doesn't cover what's done in the Refresh: http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0412.html The Netscape vision for the header. http://wp.netscape.com/assist/net_sites/pushpull.html JavaBoutique article showing usage. http://javaboutique.internet.com/tutorials/JSP/part08/page02.html mentions non-standard header, but that NS and IE support it. [trunc] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [id] Need some help figuring this out
If I understand correctly the struct and the fact that its SqlServer on Intel P4 means I'm seeing little endian first in the DWORD and WORD fields? That makes the pattern intelligible: TypeField HexOctet DWORD Data1 - [lsb0][lsb1][msb0][msb1] WORDData2 - [lsb][msb] WORDData3 - [lsb][msb] BYTEData4[8] - just bytes I'm not sure what this should mean to o.a.c.id.uuid.UUID...since the UUID implementation I've worked out uses BigInteger to store the 128-bits, and I also allow a constructor from a BigInteger. I felt systems that wish to store the byte value and not the char value could benefit. (For example, to store in db2 I would use a the 16 byte value not the 36 byte string representation.) The IETF Draft spec says the 128 bit object should be composed of the various fields in network byte order, so it seems the numeric value returned from ms-sql is system specific? and the a.o.c.id.uuid implementation is ok by the spec? I'm going off of: http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt (Section: 4.1.2 Layout and byte order) I'm wondering if someone might try to construct an o.a.c.id.UUID from the hexidecimal value they pulled from MS-SQL? It may be a long shot, but perhaps a note in the documentation is needed? e.g. String fromMSSQL = 0904F0B4F8CE2248802CDEB20704C365; BigInteger bInt = new BigInteger(fromMSSQL, 16); UUID myUUID = new UUID(bInt); System.out.println(myUUID.toString()); Outputs: 0904f0b4-f8ce-2248-802c-deb20704c365 and Not B4F00409-CEF8-4822-802C-DEB20704C365 and would not produce the same GUID from ms-sql to o.a.c.id.uuid.UUID because the hexidecimal representation from ms-sql is this way. Another option might be a new method parseMSSQLHexidecimal(String)? Any thoughts? PS Thanks Martin... I would not have figured out that out. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[id] Need some help figuring this out
Below are some transact SQL (MS-SQL Server) statements that I ran in Query Analyzer. I'm trying to figure out how it is that a UUID in character format translates to the hexidecimal format SQLServer uses. An example is: String format is: B4F00409-CEF8-4822-802C-DEB20704C365 Hexidecimal format is: 0x0904F0B4F8CE2248802CDEB20704C365 I see a pattern, but I can't explain it. My first thought was that it's an endian problem, but that doesn't seem to pan out. Anyone have any ideas? The pattern I see is the last 2 fields are the same. But the high order bytes / half are swapped B4F00409-CEF8-4822-802C-DEB20704C365 \ / \/ \/ / \ /\ /\ 0904F0B4 F8CE 2248 802C DEB20704C365 //T-SQL Statements DECLARE @tmpuuid uniqueidentifier DECLARE @myuuid uniqueidentifier SET @myuuid = newid() print 'MyUUID String Format: ' print Convert(char(36), @myuuid) print '' print 'MyUUID Binary Format: ' print Convert(binary(16), @myuuid) print '' SET @tmpuuid = Convert(binary(16), @myuuid) print 'tmpuuid converted back: ' print @tmpuuid ==OUTPUT== MyUUID String Format: B4F00409-CEF8-4822-802C-DEB20704C365 MyUUID Binary Format: 0x0904F0B4F8CE2248 802CDEB20704C365 tmpuuid converted back: B4F00409-CEF8-4822-802C-DEB20704C365 == Reformatted == MyUUID String Format: B4 F0 04 09 - CE F8- 48 22- 802C-DEB20704C365 MyUUID Binary Format: 0x 09 04 F0 B4 F8 CE 22 48 802C DEB20704C365 tmpuuid converted back: B4F00409-CEF8-4822-802C-DEB20704C365 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] Uuid
I had few questions about the Uuid code and/or coding conventions:
First, sorry to be a newbie, but I'm seeing the
$Header tags $Header:...$ and @version $Revision: ... $ tags.
They look like xdoclet tags perhaps, are they something a contributor should
be adding, or is this something committers add prior to a commit? If
contributor's should be maintaining prior to sending patches, what is the
convention for updating the version? For example sending a patch for
something that has version 1.1 I assume should be changed to 1.2? When or
what determines a major version/revision 2.0?
Second, I had some questions about the level of compliance with the
checkstyle checks:
I'm adding some code I normally wouldn't so that checkstyle checks pass, but
I'm wondering if I should be doing these things (what is the expected
checkstyle compliance?)
For instance:
To avoid magic numbers
I changed
{
buf.insert(8, '-');
buf.insert(13, '-');
buf.insert(18, '-');
buf.insert(23, '-');
}
-- to --
public static final int TOKENS_IN_UUID = 5;
private static final int[] FORMAT_POSITIONS = {8, 13, 18, 23};
...
for (int i = 0; i TOKENS_IN_UUID - 1; i++) {
buf.insert(FORMAT_POSITIONS[i], '-');
}
but the first way seems more efficient to me.
Also to avoid Definition of equals with corresponding definition of
hashCode warning I've added:
/** @see java.lang.Object#hashCode() */
public int hashCode() {
return super.hashCode();
}
Third, based on some previous discussions on this list, I think Sun
convention is to use the UUID naming instead of Uuid. Should these be
renamed?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] UuidClock patch1
Hi Phil, I've sent my WIP (Work in Progress) directly / off-list. Not sure if that's bad protocol, but just wanted to send an update and get initial thoughts. I've got lots to do still... re-integrating tests, new tests, I need to verify something's about the implementations and the spec, etc, etc. Refactoring... Haven't even though about the C code yet, hopefully APR has the MAC address code. Pls have a look at the test that I added for UuidClock. I don't think that I have the accuracy part right and I am seeing sporadic (say, every 10th time on a *fast* linux box) failures in the uniqueness test. I do need to catch up on the changes / new things since I got back. My initial thought on the failed test is...ut-oh. I'll definitely check. I wanted to get some of the code I started the other week closer, so I haven't looked yet. Also, please make sure that you can build the whole project let us know what you think about the setup. As long as whatever we end up with in uuid can implement the StringIdentifierGenerator interface, things should work fine. Sounds reasonable. I would like to have the option to get the Uuid object as well as the String representation. I'm starting to think about how to get something like SQLServer uniqueidentfier data type working with our DB2 database(s) but I may or may not use a SQL_BINARY I added a maven-generated ant build.xml, which should work if you don't like/use maven. Ahh, Maven I've been wanting to start using it. I'm using Eclipse so Ant is easier AFIAK at the moment, but I've been wanting to try out Mavenide. I appreciate the build script. -TR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [uid] UuidClock patch1
- * multiprocessors. If a system overruns the clock adjustment by requesting
- * too many UUIDs within a single system clock tick, the UUID service may
- * raise an exception, handled in a system or process-dependent manner
- * either by:
- * terminating the request
- * reissuing the request until it succeeds
- * stalling the UUID generator until the system clock catches up.
- *
- * If the processors overrun the UUID generation frequently, additional
node
- * identifiers and clocks may need to be added.
- *
- *
- * @version $Revision: 1.1 $ $Date: 2003/12/24 08:59:45 $
- * @author Tim Reilly
- */
-
-public class UuidClock extends Thread {
-
-/** Default life of the UuidClock thread in milliseconds */
-public static final long DEFAULT_THREAD_LIFE = 200;
-
-/** Offset from GregorianCalendar Change over to Jan 1 1970 00:00:00.00
*/
-public static final long GREGORIAN_CHANGE_OFFSET = 1221929280L;
-
-/** Maximum ticks per millisecond interval */
-public static final long TICKS_PER_MILLI = 1L;
-
-/** Life time of the clock thread in milliseconds */
-private static long threadLife = DEFAULT_THREAD_LIFE;
-
-/** Singleton instance of the UuidClock */
-private static UuidClock clock = null;
-
-/** The counter for nanoseconds generated during this system
interval(ms) */
-private int generatedThisMilli;
-
-/** The current time in milliseconds held in this clock thread. */
-private long currentTimeMillis;
-
-/** Time when the clock thread should die */
-private long expires = threadLife;
-
-/**
- * Private constructor for clock implementation. Utilizes a single
thread to
- * increment the clock every milli seconds this should be more
- * accurate than System.currentTimeMillis() as described in
- * the javaworld article:
- *
http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110-timing.html
- */
-
-private UuidClock() {
-setDaemon(true);
-setPriority(Thread.MAX_PRIORITY);
-currentTimeMillis = System.currentTimeMillis();
-start();
-}
-
-/**
- * Returns the thread life in milliseconds. If the clock thread is not
- * accessed within this time span the thread will die off.
- *
- * @return thread life time span in milliseconds
- */
-public static long getThreadLife() {
-return UuidClock.threadLife;
-}
-
-/**
- * @param threadLife milliseconds this thread should live for. Each
- * call to getCurrentTime resets the expiration time value.
- */
-public static void setThreadLife(long threadLife) {
-UuidClock.threadLife = threadLife;
-}
-
-/**
- * Threads run method that increments the clock and resets the
generated
- * nano seconds counter.
- */
-public void run() {
-try {
-while (--expires = 0) {
-Thread.sleep(1);
-currentTimeMillis++;
-generatedThisMilli = 1;
-}
-} catch (InterruptedException e) {
-System.out.println(UuidClock thread interrupted);
-}
-}
-
-/**
- * Returns the internal time milliseconds for the UuidClock instance
- * @return the clock threads current time in milliseconds
- */
-private long getCurrentTimeMillis() {
-return currentTimeMillis;
-}
-
-/**
- * Returns the current time as described in the clock resolution and
- * timestamp sections of the uuid specification.
- *
- * @return the current time in 100-nano second intervals (simulated)
- */
-private long currentTime() {
-this.expires = threadLife;
-// Stall until counter is reset to limit only 1 intervals per
-// millisecond interval
-while (generatedThisMilli TICKS_PER_MILLI) {
-//wait for thread to reset
-}
-
-long currentTime =
-((currentTimeMillis + GREGORIAN_CHANGE_OFFSET) * TICKS_PER_MILLI);
-
-return currentTime + (generatedThisMilli++);
-}
-
-/**
- * Static method returns the clocks current time in 100-nanosecond
intervals
- * since the Gregorian calander change. Calendar.GREGORIAN_OFFSET
- *
- * @return Coordinated Universal Time (UTC) as a count of 100-
nanosecond
- * intervals since 00:00:00.00, 15 October 1582
- */
-public static synchronized long getCurrentTime() {
-if (clock == null || !clock.isAlive()) {
-clock = null;
-clock = new UuidClock();
-}
-return clock.currentTime();
-}
-
-}
+/*
+ * $Header:
/home/cvspublic/jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/
uuid/UuidClock.java,v 1.1 2003/12/24 08:59:45 psteitz Exp $
+ *
+ *
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 2001-2003 The Apache Software
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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] UUID Generator - was RE: UUID Generator?
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? /* * The Apache Software License, Version 1.1 * * Copyright (c) 2000 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 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 end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. * * 4. The names Apache and Apache Software Foundation must *not be used to endorse or promote products derived from this *software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, *nor may Apache appear in their name, without prior written *permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``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 THE APACHE SOFTWARE FOUNDATION 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. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ package org.apache.commons.lang.identifier; import java.io.IOException; import java.io.InputStream; import java.util.Properties; /** * UuidClock.java provides a timing mechanism for returning the current time in * 100-nano second intervals since 00:00:00.00, 15 October 1582 * * As described below this is useful for generating Version 1 UUIDs * * For more information regarding the IETF Draft Uuid specification * @see http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt * * Selected segements of Draft pertaining to this class: * * * Timestamp * The timestamp is a 60 bit value. For Uuid version 1, this is * represented by Coordinated Universal Time (UTC) as a count of 100- * nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of * Gregorian reform to the Christian calendar). * * Clock Adjustment * UUIDs may be created at a rate greater than the system clock resolution. * Therefore, the system must also maintain an adjustment value to be added to * the lower-order bits of the time. Logically, each time the system clock * ticks, the adjustment value is cleared. Every time a UUID is generated, * the current adjustment value is read and incremented atomically, then added * to the UTC time field of the UUID. * * Clock Overrun * The 100 nanosecond granularity of time should prove sufficient even for * bursts of UUID creation in the next generation of high-performance * multiprocessors. If a system overruns the clock adjustment by requesting * too many UUIDs within a single system clock tick, the UUID service may * raise an exception, handled in a system or process-dependent manner * either by: * terminating the requester * reissuing the request until it succeeds * stalling the UUID generator until the system clock catches up. * * If the processors overrun the UUID generation frequently, additional node * identifiers and
RE: [configuration] Documentation Patch
RE: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25459 Was the patch I sent ok? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] UUID Generator - was RE: UUID Generator?
Yes, it would be best to attach files to a Bugzilla ticket. Ok, I'm opening one now under lang, later on if these need to go elsewhere - ok, but for now I'm opening under lang enhancement. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25580 I will have a look this evening. The bugzilla attachment on the ER is refactored/simplified. Is this meant to be used with the axis impl? Nope, not for the axis impl. UuidClock is for version 1 uuid. It should give the proper time resolution behavior; would be used to get the current time as 100 millisecond intervals since Gregorian offset for the time_hi, time_mid, time_lo fields. Purpose: - overcome issues with System.currentTimeMillis() - account for clock overrun - account for clock resolution at 100 nanos intervals -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 9:12 AM To: Jakarta Commons Developers List Subject: Re: [lang] UUID Generator - was RE: UUID Generator? 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? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: UUID Generator?
Recently in the jetspeed-dev list I decribe the unresolved licensing questions I ran into http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] che.orgmsgNo=10234 [Inlined:] Response to: A copyright question (Barnhill William) From: Tim Reilly [EMAIL PROTECTED] Subject: A copyright question Date: Fri, 5 Dec 2003 20:32:58 -0500 Content-Type: multipart/mixed; boundary==_NextPart_000_00DB_01C3BB6E.F843DEA0 Hello Bill, I started on something quite a few months ago: commons-lang welcomed adapting a UUID implementation. The problem I ran into was - the consensus at the time was to use the Tyrex UUID for various reasons (also found in Castor with slight changes.) And elsewhere in exolab projects. I started the discussion wanting to get the Axis uuid moved into commons. http://marc.theaimsgroup.com/?l=jakarta-commons-devw=2r=1s=UUIDq=b But since I want this as a pure Apache license class for the sake of reuse in apache projects I did not know how to take from one license source Exolab and put under ASL. I tried contacting Assaf Arkin; rather [EMAIL PROTECTED] to see about a contribution put no luck. -- Would you leave the original license in the file? But then all ASF source must have the ASF license. Would you pre-pend both licenses? Add the Tyrex license to the distribution? Reduce a modified Tyrex jar to distribute with only the 3 classes and the license and uuid.properties? And call it something else? -- FYI just noticed Turbine has org.apache.turbine.util.db.UUIdGenerator that allows for a properties file with the MAC address. (That was one of the requests from commons-lang.) -- When I didn't get answers to these questions I toyed with creating an implementation modeled after the Tyrex version. I planned to allow the clock thread to die after some timeout between calls. No idea if that's a smart thing or not; I also didn't understand the need to re-synchronize with the System time? Can threads sleep longer than you say tell them - I mean I know load and thread priority come into play, but I thought not that long. Anyhow, not feeling confident in what I was doing I decided to abandon it. I know attachments sometimes don't make it, but I'll try to attach a rough **draft** here. If you have interest in continuing this feel free or we can work on it together. I don't have a much time but I can make some somewhere and I'll learn some stuff. It would be nice to follow through on the original thought and get something to commons-lang identifiers; so all these UUID that are about might live in commons. Let me know your thoughts. -TR -Original Message- From: Tim Anderson [mailto:[EMAIL PROTECTED] Sent: Monday, December 15, 2003 8:20 PM To: Jakarta Commons Developers List Subject: RE: UUID Generator? This question came up earlier this year. Refer to the following thread: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15msgNo=32065 -Tim -Original Message- From: Hernan Silberman [mailto:[EMAIL PROTECTED] Sent: Tuesday, 16 December 2003 10:33 AM To: [EMAIL PROTECTED] Subject: UUID Generator? Is there code to generate UUIDs in Jakarta? thanks... hernan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] nIndexOf/ordinalIndexOf
For thought: In Coldfusion world it's stringFind(String str, String search, int ordinal) stringFind(String str, String search, int ordinal, int start) -and- stringFindNoCase(String str, String search, int ordinal) stringFindNoCase(String str, String search, int ordinal, int start) -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 1:56 PM To: 'Jakarta Commons Developers List' Subject: RE: [lang] nIndexOf/ordinalIndexOf Just for arg's sake: 1) ordinalIndexOf (String str, String searchStr, int ordinal) 2) indexOfOrdinal (String str, String searchStr, int ordinal) Gary -Original Message- From: Arun Thomas [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 10:02 To: Jakarta Commons Developers List Subject: [lang] nIndexOf/ordinalIndexOf I've got to say that I like the parallelism with the other methods. For what it's worth, I like: ordinalIndexOf(String str, String searchStr, int ordinal) -AMT -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2003 11:27 PM To: 'Jakarta Commons Developers List' Subject: RE: [VOTE] Release of Commons Lang 2.0 [take 2] Inline: -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2003 23:11 To: Jakarta Commons Developers List Subject: Re: [VOTE] Release of Commons Lang 2.0 [take 2] Gary Gregory wrote: Ah, well, in that sprit, then comments on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22719 would be appreciated but I do not expect this to go in 2.0 unless other folks like/need it. Looks useful to me. I would go ahead and add it. Here are a couple of small comments: 1. Yes, the name sucks, but nothing nice jumps out at me. Of the alternatives that you have listed, I like indexOfOccurrence the best. Another one to consider might be ordinalIndexOf. b/w the 2, I like indexOfOccurrence better but let's see what other folks like. 2. Make sure to change the method names in the javadoc examples to match the chosen name. Also, the last two examples should probably be replaced by one using a * for the integer argument. I am not fond of that one since I would need to put a x or i or something that is not the real answer to the example and since the point of the method is to pass in a count, an example for both 1 and 2 is nice. I could add another entry with * and i I guess. gg Phil Gary -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2003 20:24 To: Jakarta Commons Developers List Subject: Re: [VOTE] Release of Commons Lang 2.0 [take 2] Gary Gregory wrote: I'll take the blame for causing any confusion on this one since I had committed these Javadoc changes during the vote, which was made more difficult due to the extremely long email delays caused by the current batch of viruses going 'round. My thought was that we were indeed voting on the build based on tagged sources and that any new commits would be in a post 2.0 release (even though, these changes being Javadoc changes are harmless and beneficial to the release IMHO ;-) If we want to implement a code freeze in our environment on top of using tags, we could do that. I guess we'd have to vote on it too :-) Sorry if I misunderstood things. I thought we were still adding things to the release. I see no reason to freeze code if we have a tagged release. I am +1 for releasing the code prior to the javadoc changes that occurred during the vote or to adding them and retagging. If that requires a new vote, then I am OK with that as well. In any case, we should not have to stop everything as we wait for the release to go. I would also very much like to see 2.0 get out the door. Phil Gary -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Sunday, August 24, 2003 00:00 To: Jakarta Commons Developers List Subject: RE: [VOTE] Release of Commons Lang 2.0 [take 2] Well, if there is a question about policy/process, why not just freeze the code and restart the vote? By tagging the CVS, he effectively has frozen the code for the Release. I was simply curious about the policy because, as I said, other projects are stricter. For example the HTTPd team has different rules (http://httpd.apache.org/dev/release.html). A Release Manager makes a release build, and it is automatically an alpha. It becomes a beta release when at least three Committers have voted beta status, and there are more +1 than -1. It becomes a GA release when at least three
RE: getMethod.getResponseBody() leaks handles
FYI - Thanks much for this information. We had a what seemed like a bug using Linux/WPS/IBM-JDK to Windows/IIS using NTLM Auth... the code ran once or twice then started getting 401 responses. I believe the socket closed / or connection closed (then the NTLM negotiation was not performed again.) Using a single HttpClient instead of new one for each method invokation plus using getResponseBodyAsString instead of getResonseBodyAsStream resolved it for us. IMHO adding Roland's 1..4 below to the site/tutorial would be a good thing. Thanks -TR -Original Message- From: Roland Weber [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 4:13 AM To: Commons HttpClient Project Subject: RE: getMethod.getResponseBody() leaks handles David, Michael, I get the feeling you have entered a closed loop in your discussion. Please let me add an observer's view, in hope to break the loop. I'll adress this mail to David, since it's whom we are trying to help with his problem. I want to point out that I did not dive into the source code for this mail, neither into that of the HTTP client nor that of David's test program. I gathered my evidence just from the natural language parts of the correspondence, and from my user-level knowledge of the HTTP client. So, David: HttpMethod is not meant to close connections. It is meant to use them, and then give them back to the connection manager, which will decide whether to close or reuse them. There are some cases in which the HttpMethod knows that the connection cannot be reused and closes them, but that's not the regular case. From one of Michaels remarks I learned that you are creating a new instance of the HTTP client and connection manager for each request. Which means you are not using the HTTP client in the way it is meant to be used. This may or may not indicate a deficiency in the documentation. It probably does, see below. Actually, the connections do not leak when you execute your HTTP method, or finish executing it. They leak when you forget about the current connection manager rather than reusing it for the next request. The difference in behavior between Linux and Windows is due to the fact that the Linux JVM has a fall-back cleanup mechanism which closes the connection, while the Windows JVM has not. If you restructure your application, no fall-back cleanup will come into this and behaviour will be similar on both platforms. I guess the sample code on how to use the HTTP client for a single request does not point out which part of the code is a one-time initialization and which part needs to be repeated for each request. So let me tell you: 1. The HTTP Client instance and it's connection manager should be created once, during initialization of the application. Both are meant to be reused for all subsequent requests. 2. Connections will be opened, closed or reused implicitly by the connection manager (see 4). 3. The HttpMethod objects can be created for each request, or recycled if you want to. 4. HttpMethod.releaseConnection() must be invoked after each request. It will make sure that the connection used for that request is given back to the connection manager. I hope this helps, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: UUID Reuse proposal
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 [EMAIL PROTECTED] * * 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
