DO NOT REPLY [Bug 22414] - FileUpload default constructor doesn't work

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22414.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22414

FileUpload default constructor doesn't work





--- Additional Comments From [EMAIL PROTECTED]  2003-08-15 06:28 ---
In that case I think you should remove the default constructor. Or at least 
modify its Javadoc, the current 

Constructs an instance of this class which uses the default factory to create 
FileItem instances. 

is quite misleading.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [pool] faulty change of synchronization? - Re: cvs commit: jakarta-commons/pool/src/java/org/apache/commons/pool/implGenericObjectPool.java

[Dirk Verbeeck]

Hi Marc

Very nice link you gave, very interesting.
The changes I'm doing is a work in progress. Before releasing it we will 
do a formal review including a vote,
beta test on release canidate and then the actual release. You will get 
enough time to review.

But the code is not very good yet. There should be a simpler way to 
solve these synchronization issues.
I'll have another go at it...

Dirk

Marc Slemko wrote:

jOn Wed, 13 Aug 2003, Dirk Verbeeck wrote:

 

_numActive is an int so the synchronized block wasn't needed.
But the extra synchronized is in the case where a new object
has to be created and not in the critical get from pool code path.
All the success code paths have now one synchronized block.
I'll leave it as is for now.
   

No, you need the synchronization (or some other thread safe approach),
otherwise you risk all sorts of errors.  There are a very limited
set of cases where you can avoid synchronization when you need concurrent
access from multiple threads.
Synchronization in java handles both mutual exclusion and visibility.
There is no guarantee that a change made in one thread to a variable
is visible to another without synchronization.
See some of the references linked to from:

	http://www.cs.umd.edu/~pugh/java/memoryModel/

There appear to be all sorts of race conditions in borrowObject() now...
_numActive, accesses to _pool, _maxActive... you can't check the value of
a counter outside a synchronized block then only synchronize to modify it!
I think you need to step back and reconsider what problems these changes
are trying to fix.  You need to find the real operation that is
bottlenecking things (which for connection pools would normally be calling
into the JDBC driver to open a connection), and move that operation
outside the synchronized block without doing unsafe things.
Now, ideally that whole thing would be reworked even further to have the
connection opener in a seperate thread to allow the getConnection() to
time out after a specified timeout, while it keeps trying to open the
connection in the background.  In fact, if you do that you may be able to
just leave the whole method synchronized and wait on the opener thread,
but there are some extra efforts required to ensure fairness, etc. that
may make that more complex.
I strongly recommend you roll back the synchronization changes unless
someone who fully understands what has to be synchronized and why can
review possible fixes, I don't have time just now, maybe next week; the
current state is _NOT_ good enough.
-
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 Reuse proposal

[Shapira, Yoav]

Howdy,
+1... I recall having something in lang already like IdentityUtil that
might be merged with this?

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2003 9:33 PM
To: 'Jakarta Commons Developers List'
Subject: RE: UUID Reuse proposal

+1.

Another UUID extension I'd like to see and use is a GUID
implementation,
that's what MS calls a UUID.

WRT to lang.uuid, I am not sure that a new namespace is justified
though.
I'd just put it in .lang like other basic types.

gg

 -Original Message-
 From: Tim Reilly [mailto:[EMAIL PROTECTED]
 Sent: Thursday, August 14, 2003 18:32
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: UUID Reuse proposal

 I'd like to ask the axis developers to donate the java package
 org.apache.axis.components.uuid to the Jakarta commons.

 I'm cross-posting this message on both jakarta commons-dev list and
axis-
 dev
 list as commons could adopt this package and place somewhere sensible
to
 the
 commons. My suggestion would be as an addition to
org.apache.commons.lang
 since the UUID is a special/complex type (aren't all classes, but
 hopefully
 you know what I'm saying.)
 I know not to cross-post but given the request it only makes sense. I
 realize the package has some basis on the similar package in the BSD
 licensed http://sourceforge.net/projects/juddi/ project. It doesn't
make
 sense to include the UUIDGenFactory, which would remain in place
(unless
 anyone has good ideas on making it more generic?)

 The reason for this request is that the package is nicely written
(kudos
 to
 the author(s)), and very useful in a number of applications. The
Jetspeed
 developers can use this package; however it does not necessarily make
 sense
 for Jetspeed to create a dependency on the axis jar, solely to use
this
 package. There are numerous other applications of UUID's that make it
an
 ideal candidate for the Jakarta-commons, and I feel that
donating/adopting
 this package within the commons fits nicely with the vision of the
 commons.
 Other uses abound, for example struts could use the classes to
guarantee
a
 form is submitted only once. A search of theserverside.com brings
back
 some
 patterns that use guid/uuid.

 I'd be willing to send the patches to the Axis team if the commons
 committers are willing to adopt the package and Axis wishes the same.
 Basically this would be to depreciate
 org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend
 org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the
 org.apache.axis.components.uuid.SimpleUUID strings within the CVS.
Or
if
 there is a better way.. I'd be will to do whatever is agreed upon.

 Please consider this request; I'll keep an eye on each list and if
both
 projects agree that would be great and we can proceed.
 A lesser alternative would be for jakarta-commons to adopt the
package,
 but
 axis makes no changes. This is the perhaps the lesser approach since
reuse
 is not fully accomplished but if the Axis committers are reluctant
then
 perhaps they could give their okays to the lesser approach, and
 jakarta-commons could still adopt the classes.

 For more information on UUID:
 Per javadoc comment -
 * A Universally Unique Identifier (UUID) is a 128 bit number
generated
 * according to an algorithm that is guaranteed to be unique in time
and
 space
 * from all other UUIDs. It consists of an IEEE 802 Internet Address
and
 * various time stamps to ensure uniqueness. For a complete
specification,
 * see ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt
 [leach].

 Thank you for considering.
 -Tim Reilly


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/pool/src/java/org/apache/commons/pool/impl GenericObjectPool.java

[dirkv]

dirkv   2003/08/15 06:34:05

  Modified:pool/src/java/org/apache/commons/pool/impl
GenericObjectPool.java
  Log:
  refactored borrowObject to reduce the number of synchronized blocks needed
  
  Revision  ChangesPath
  1.24  +57 -84
jakarta-commons/pool/src/java/org/apache/commons/pool/impl/GenericObjectPool.java
  
  Index: GenericObjectPool.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/pool/src/java/org/apache/commons/pool/impl/GenericObjectPool.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- GenericObjectPool.java13 Aug 2003 19:05:23 -  1.23
  +++ GenericObjectPool.java15 Aug 2003 13:34:05 -  1.24
  @@ -707,82 +707,36 @@
   //-- ObjectPool methods --
   
   public Object borrowObject() throws Exception {
  -// Warning: because the method synchonization is gone
  -// _numActive should be incremented as soon as possible
  -// otherwise the pool can go over the limit
  -// decrement on error (do not forget to notifyAll)
  -
  -assertOpen();
   long starttime = System.currentTimeMillis();
   boolean newlyCreated = false;
   for(;;) {
   ObjectTimestampPair pair = null;
  -// if there are any sleeping, just grab one of those
  -if (!_pool.isEmpty()) { // no need to synchronize when pool is empty
  -synchronized(this) {
  -try {
  -_numActive++;
  -pair = (ObjectTimestampPair)(_pool.removeFirst());
  -} catch(NoSuchElementException e) {
  -; /* ignored */
  -}
  -if(null == pair) { // someone took the last one before us
  -_numActive--;
  -notifyAll();
  -}
  +
  +synchronized(this) {
  +assertOpen();
  +
  +// if there are any sleeping, just grab one of those
  +try {
  +pair = (ObjectTimestampPair)(_pool.removeFirst());
  +} catch(NoSuchElementException e) {
  +; /* ignored */
   }
  -}
  -// otherwise
  -if(null == pair) {
  -// check if we can create one
  -// (note we know that the num sleeping is 0, else we wouldn't be 
here)
  -if(_maxActive = 0 || _numActive  _maxActive) {
  -try {
  -synchronized(this) {
  -_numActive++;
  -}
  -Object obj = _factory.makeObject();
  -pair = new ObjectTimestampPair(obj);
  -newlyCreated = true;
  -}
  -finally { 
  -if(null == pair) {
  -synchronized(this) {
  -_numActive--;
  -notifyAll();
  -}
  -}
  -}
  -} else {
  -// the pool is exhausted
  -switch(_whenExhaustedAction) {
  -case WHEN_EXHAUSTED_GROW:
  -try {
  -synchronized(this) {
  -_numActive++;
  -}
  -Object obj = _factory.makeObject();
  -pair = new ObjectTimestampPair(obj);
  -newlyCreated = true;
  -}
  -finally {
  -if(null == pair) {
  -synchronized(this) {
  -_numActive--;
  -notifyAll();
  -}
  -}
  -}
  -break;
  -case WHEN_EXHAUSTED_FAIL:
  -throw new NoSuchElementException();
  -case WHEN_EXHAUSTED_BLOCK:
  -synchronized(this) {
  -// only sleep when the pool is really empty
  -// between the isEmpty check at the beginning
  -// and here, an object could have been added 
  -// to the pool
  -if (_pool.isEmpty()) {
  +
  +// otherwise
  + 

Commons Pool/DBCP minIdle Implementation

[Richard Wareing]

Hello everyone,

For a project I'm working on we needed the capability to have the number
of idle objects in the pool (database connections via DBCP in this case)
to stay at some minimum level for performance reasons.

The main performance benefit I saw for this was X number of connections
always being available in the event the pools connections became stale
for some reason (e.g. database went down and came back up some time
later).  For high latency database connections (250ms) this equates to
a substantial savings in query time as well as adds to the QOS (rather
than having the first person in after the pool being cleaned out trigger
a new connection).

Anyhow, I implemented the feature in commons-pool as well as
commons-dbcp and I was wondering if you might consider it for
integration into the main trees?  If so how does one go about
contributing this to the project?  The changes were relatively trivial
and IMHO :) really improve the performance and resilience of the
package.

Richard Wareing
Software Engineer
Reimer Technology Group



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Commons Pool/DBCP minIdle Implementation

[Shapira, Yoav]

Howdy,
One way to do it would be to post an enhacenment request and bugzilla
and attach your patch (with any relevant files, e.g. unit tests) to the
bugzilla item.  Committers review this list periodically, and certainly
before every release.

Yoav Shapira
Millennium ChemInformatics


-Original Message-
From: Richard Wareing [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 9:45 AM
To: [EMAIL PROTECTED]
Subject: Commons Pool/DBCP minIdle Implementation

Hello everyone,

For a project I'm working on we needed the capability to have the
number
of idle objects in the pool (database connections via DBCP in this
case)
to stay at some minimum level for performance reasons.

The main performance benefit I saw for this was X number of connections
always being available in the event the pools connections became stale
for some reason (e.g. database went down and came back up some time
later).  For high latency database connections (250ms) this equates to
a substantial savings in query time as well as adds to the QOS (rather
than having the first person in after the pool being cleaned out
trigger
a new connection).

Anyhow, I implemented the feature in commons-pool as well as
commons-dbcp and I was wondering if you might consider it for
integration into the main trees?  If so how does one go about
contributing this to the project?  The changes were relatively trivial
and IMHO :) really improve the performance and resilience of the
package.

Richard Wareing
Software Engineer
Reimer Technology Group



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [lang] Why ObjectUtils.Null?

[Henri Yandell]

Shall I claim I was drunk when I asked the question? :)

Thanks,

Hen

On Fri, 15 Aug 2003, Stephen Colebourne wrote:

 Void:
  * The Void class is an uninstantiable placeholder class to hold a
  * reference to the Class object representing the Java keyword
  * void.

 ObjectUtils.Null:
 A placeholder to represent null when null cannot be used. Usually used in
 collections (eg.Vector/Hashtable) or in caches (to represent that the search
 has been performed but returned nothing)

 Stephen

 - Original Message -
 From: Henri Yandell [EMAIL PROTECTED]
 To: Jakarta Commons Developers List [EMAIL PROTECTED]
 Sent: Friday, August 15, 2003 1:15 AM
 Subject: [lang] Why ObjectUtils.Null?


 
  Out of interest, what service does ObjectUtils.Null have over
  java.lang.VOID?
 
  Hen
 
 
  -
  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] 2.0 left to do

[Henri Yandell]

Okay. I'll build rc2 tonight.

[My company monitor the US power grid, so we're a bit busy at the moment.
http://www.genscape.com/blackout-replay.swf is pretty cool :) ]

Hen

On Fri, 15 Aug 2003, Stephen Colebourne wrote:

 +1
 A comment of a method, and its time to go RC2.

 Stephen

 - Original Message -
 From: Phil Steitz [EMAIL PROTECTED]
+1 to yanking the time code to address #22172
 
+1 to applying Pete's javadoc patch if we have it in the next day or
  two, but otherwise calling it quits for 2.0.  Sure, we could keep
  refining tests and javadoc, but I think that the consensus is that we
  are in pretty good shape for the stuff that is going to be released.  I
  at least am happy with all of the stuff that I have reviewed/contributed
  to.  The only packages that I have not looked at carefully are builder
  and enum.  I notice some test path coverage gaps in exception, but the
  key stuff appears to be well tested and if others have confidence in the
  code, I am +1 for release as is.
 
  Not sure exactly what to do about #22393.  I posted a comment pointing
  out that serialization of Nestable is actually tested in
  NestableExceptionTestCase and asking for sample code.
 
  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]

Re: [combo] Commons Core release?

[Rodney Waldhoff]

On Wed, 13 Aug 2003, Craig R. McClanahan wrote:

 Trying to define combo as anything other than the latest released
 version of every Commons package seems like it's guaranteed to cause
 arguments.  The collection you propose below, for example, is totally
 useless to me and all the projects I work on.  But commons-combo as it is
 currently built would be useful to me, and to you, and to anyone else.

I'm with Craig on this. +0 to a combo that contains everything in
commons (even httpclient) in a single JAR (and we'll cross our fingers
that won't introduce any versioning issues.)  -1 anything like
commons-core that tries to pick and choose which products the user is
likely to want.  This is impractical at best, and political at worst.

 
  =
  Apache Commons Core v1.0 consists of:
 
  Jakarta Commons BeanUtils 1.6.1
  Makes the JavaBean specification easier to deal with.
 
  Jakarta Commons CLI 1.0
  A command line interpreter. Used to handle all the flags passed to your
  program on the command line.
 
  Jakarta Commons Codec 1.1
  Common encoders and decoders.
 
  Jakarta Commons Collections 2.1
  Many more implementations that fit the Collections API.
 
  Jakarta Commons Lang 1.0.1
  Enhancements to classes found in java.lang.
  ===

 
  A url to a build is: http://www.apache.org/~bayard/commons-core/
 
  I'm doing some trickery to turn BeanUtils' commons-logging dependency into
  a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient
  and maybe Net [with some regexp trickery] and consider that a version 1.0.
 

 We can talk about that on a [beanutils] specific thread, but I'd be -1 on
 doing this to the real BeanUtils code.  A very large number of BeanUtils
 users do not have the luxury to run on a 1.4 JDK.


This is probably better suited to another thread, but I'm -1 on making
BeanUtils require JDK 1.4.



With respect to versioning of something like commons-combo, I'd rather see
either: (1) straight incremental version numbers--release 1,
release 2, ... , release n--or (2) a straight date based
system--17 Aug 2003, 23 Sept 2003, etc.  Anything else is going to
confuse the suitation more than clarifying it.  If you want to know which
specific versions of each component are contained, you're gonna have to
look at the release notes anyway.

- Rod http://radio.weblogs.com/0122027/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/time DateUtils.java

[bayard]

bayard  2003/08/15 09:14:35

  Modified:lang/src/test/org/apache/commons/lang/time
DateUtilsTest.java
   lang/src/java/org/apache/commons/lang/time DateUtils.java
  Log:
  Commented out the parseCVS code for consideration/fixing for Lang 2.1
  
  Revision  ChangesPath
  1.9   +9 -8  
jakarta-commons/lang/src/test/org/apache/commons/lang/time/DateUtilsTest.java
  
  Index: DateUtilsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/time/DateUtilsTest.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- DateUtilsTest.java10 Aug 2003 13:30:33 -  1.8
  +++ DateUtilsTest.java15 Aug 2003 16:14:35 -  1.9
  @@ -363,10 +363,10 @@
   } catch (ClassCastException ex) {}
   }
   
  -/**
  +// TODO: Decide whether this code is removed or goes into 2.1
  +/*
* Tests the parse method, which is supposed to handle various strings
* as flexibly as CVS supports.
  - */
   public void testParseCVS() throws Exception {
   try {
   DateUtils.parseCVS(null);
  @@ -414,12 +414,12 @@
   assertEquals(parseCVS format MMM d,  h:mm a,
 now, DateUtils.parseCVS(new SimpleDateFormat(MMM d,  h:mm 
a).format(now.getTime())), 50);
   // h:mm z
  -/*
  - * This format is difficult to test using the current time because the
  - * parseCVS method applies the default date of January 1, 1970 to the
  - * parsed time. The most straightforward way to test the parse is to
  - * pass in a known value, and test the output against this know value.
  - */
  +//
  +// This format is difficult to test using the current time because the
  +// parseCVS method applies the default date of January 1, 1970 to the
  +// parsed time. The most straightforward way to test the parse is to
  +// pass in a known value, and test the output against this know value.
  +// 
   now = Calendar.getInstance();
   now.setTime(new SimpleDateFormat(h:mm z).parse(16:30 GMT));
   assertEquals(parseCVS format h:mm z 16:30 GMT, 
  @@ -567,6 +567,7 @@
   assertEquals(parseCVS last January,
   now, DateUtils.parseCVS(last January), 50);
   }
  + */
   
   /**
* Tests the iterator exceptions
  
  
  
  1.12  +4 -3  
jakarta-commons/lang/src/java/org/apache/commons/lang/time/DateUtils.java
  
  Index: DateUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/DateUtils.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- DateUtils.java10 Aug 2003 13:32:16 -  1.11
  +++ DateUtils.java15 Aug 2003 16:14:35 -  1.12
  @@ -409,14 +409,14 @@
   
   }
   
  +// TODO: Decide whether this code is removed or goes into 2.1
   //---
  -/**
  +/*
* pParses a date string formatted in CVS format./p
* 
* @param dateStr  the date to parse
* @return the parsed date
* @throws IllegalArgumentException if the date cannot be parsed
  - */
   public static Calendar parseCVS(String dateStr) {
   if (dateStr == null) {
   throw new IllegalArgumentException(The date must not be null);
  @@ -527,6 +527,7 @@
   
   throw new IllegalArgumentException(Unable to parse ' + dateStr + '.);
   }
  + */
   
   //---
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22464] New: - [math] binomail distribution patch

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22464.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22464

[math] binomail distribution patch

   Summary: [math] binomail distribution patch
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Sandbox
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I created the binomial distribution.  along with this, I created a discrete 
distribution heirarchy similar to the continuous case.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22464] - [math] binomail distribution patch

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22464.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22464

[math] binomail distribution patch





--- Additional Comments From [EMAIL PROTECTED]  2003-08-15 16:25 ---
Created an attachment (id=7834)
patch file

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22121] - required validator doesn't work with String[] (multi-selects)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22121.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22121

required validator doesn't work with String[] (multi-selects)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|commons-|[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
Summary|[patch] The required  |required validator doesn't
   |validator doesn't work with |work with String[] (multi-
   |String[] (multi-selects)|selects)



--- Additional Comments From [EMAIL PROTECTED]  2003-08-15 16:31 ---
I just ran into this problem as well and will commit a variation on the 
suggested approach soon.  I think we should check for Collection and String[] 
(let's refer to these collectively as the list).  If the list is empty we 
return , else we return list.toString().  This way we'll only be returning 
null when there's an error retrieving the property.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [net][patch] jdk 1.4 specific call in VMSFTPEntryParser.java

[Daniel F. Savarese]

In message [EMAIL PROTECTED], Daniel F. Savar
ese writes:
In message [EMAIL PROTECTED], 
R
ory Winston writes:
I've cleaned up a bit (applied my changes to a fresh checkout) and generated
a diff file. I've taken out the XHDR addition for now, as XOVER seems to be
the preferred mechanism for this kind of thing. The functionality added is:

This is great, but I'm having trouble applying the patch because of
formatting issues (I believe lines longer than around 79 columns were
split in two with newlines by your email client).  Could you resubmit
the patch as an attachment of some sort that will preserve the patch
intact?

My email reception got knocked offline for a couple of days so I may have
missed some mail.  Was a new patch ever submitted?  I can't find one in
the archives.  I'd like to get the patch applied before voting on a release,
but if it doesn't make it in before then it's not the end of the world.

daniel



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Betwixt] Using NameMapper

[Daniel Rall]

Robert, using BeanDescriptor.getName() worked well, enabling me to
remove the custom parsing code from ImportIssues -- was that what you
had in mind?  I didn't notice the new test case, and wrote this along
the way.  Something I should check in?


Index: TestHyphenatedNameMapper.java
===
RCS file: 
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/strategy/TestHyphenatedNameMapper.java,v
retrieving revision 1.5
diff -u -u -r1.5 TestHyphenatedNameMapper.java
--- TestHyphenatedNameMapper.java   30 Dec 2002 18:16:48 -  1.5
+++ TestHyphenatedNameMapper.java   15 Aug 2003 18:48:47 -
@@ -62,6 +62,7 @@
 
 package org.apache.commons.betwixt.strategy;
 
+import java.beans.BeanDescriptor;
 import java.util.ArrayList;
 
 import junit.framework.Test;
@@ -93,6 +94,13 @@
 assertEquals(foo-bar, result);
 }
 
+public void testLowerCaseViaBeanDescriptor() {
+HyphenatedNameMapper mapper = new HyphenatedNameMapper(false, _);
+BeanDescriptor bd = new BeanDescriptor(getClass());
+String result = mapper.mapTypeToElementName(bd.getName());
+assertEquals(test_hyphenated_name_mapper, result);
+}
+
 public void testUpperCase()  {
 HyphenatedNameMapper mapper = new HyphenatedNameMapper(true, _);
 String result = mapper.mapTypeToElementName(FooBar);


robert burrell donkin [EMAIL PROTECTED] writes:

 hi daniel
 
 i've taken a look into this (and even added another test case to
 convince myself that i'm right). the BeanDescriptor name is passed to
 the name mapper to create the element. i'm pretty sure that this
 should be the class name without the package. (it is on my machine at
 least).
 
 
 it is possible that this is an issue with the alpha1 release that has
 resolved itself since then.
 
 
 - robert
 
 On Wednesday, August 13, 2003, at 07:53 PM, Daniel Rall wrote:
 
  Daniel Rall [EMAIL PROTECTED] writes:
  ...
  is it possible to use HyphenatedNameMapper's
  mapTypeToElementName(String typeName) (or something of the sort) to
  transform ScarabIssues.class into the String scarab-issues (to
  obviate the hard-coding of magic strings)?
 
  To answer my own quesiton, it is possible:
 
  http://scarab.tigris.org/source/browse/scarab/src/java/org/tigris/scarab/
  util/xmlissues/ImportIssues.java.diff?r1=1.25r2=1.26
 
  You'll notice that I had to add a local mapTypeToElementName(Class,
  NameMapper) method which strips the package name off of the class name
  before handing off to HyphenatedNameMapper for resolution to a XML
  element.  This same code must be present somewhere within Betwixt, and
  I would prefer to take advantage of it rather than re-implementing it
  in Scarab's ImportIssues class.  It may be only a few trivial lines,
  but I feel that my inclusion of it infringes on ideal encapsulation
  (even with my update of Betwixt's JavaDoc).  A possible improvement
  would be to loosen the API of NameMapper to accept Object rather than
  String, then use instanceof Class inside of HyphenatedNameMapper to
  detemine whether a package name should be stripped off of the input.
  This would shift all mapping responsibility out of elsewhere in
  Betwixt (called from somewhere in BeanReader, I assume) down into
  NameMapper implementations.  Perhaps not what is wanted, of course --
  just a suggestion.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: UUID Reuse proposal

[Tim Anderson]

Tyrex also provides support for UUID generation, and
should perform better than the Axis impl.

See
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
rvices/UUID.java?rev=1.6

-Tim

 -Original Message-
 From: Tim Reilly [mailto:[EMAIL PROTECTED]
 Sent: Friday, 15 August 2003 11:32 AM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: UUID Reuse proposal


 I'd like to ask the axis developers to donate the java package
 org.apache.axis.components.uuid to the Jakarta commons.

 I'm cross-posting this message on both jakarta commons-dev list
 and axis-dev
 list as commons could adopt this package and place somewhere
 sensible to the
 commons. My suggestion would be as an addition to org.apache.commons.lang
 since the UUID is a special/complex type (aren't all classes, but
 hopefully
 you know what I'm saying.)
 I know not to cross-post but given the request it only makes sense. I
 realize the package has some basis on the similar package in the BSD
 licensed http://sourceforge.net/projects/juddi/ project. It doesn't make
 sense to include the UUIDGenFactory, which would remain in place (unless
 anyone has good ideas on making it more generic?)

 The reason for this request is that the package is nicely written
 (kudos to
 the author(s)), and very useful in a number of applications. The Jetspeed
 developers can use this package; however it does not necessarily
 make sense
 for Jetspeed to create a dependency on the axis jar, solely to use this
 package. There are numerous other applications of UUID's that make it an
 ideal candidate for the Jakarta-commons, and I feel that donating/adopting
 this package within the commons fits nicely with the vision of
 the commons.
 Other uses abound, for example struts could use the classes to guarantee a
 form is submitted only once. A search of theserverside.com brings
 back some
 patterns that use guid/uuid.

 I'd be willing to send the patches to the Axis team if the commons
 committers are willing to adopt the package and Axis wishes the same.
 Basically this would be to depreciate
 org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend
 org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the
 org.apache.axis.components.uuid.SimpleUUID strings within the CVS. Or if
 there is a better way.. I'd be will to do whatever is agreed upon.

 Please consider this request; I'll keep an eye on each list and if both
 projects agree that would be great and we can proceed.
 A lesser alternative would be for jakarta-commons to adopt the
 package, but
 axis makes no changes. This is the perhaps the lesser approach since reuse
 is not fully accomplished but if the Axis committers are reluctant then
 perhaps they could give their okays to the lesser approach, and
 jakarta-commons could still adopt the classes.

 For more information on UUID:
 Per javadoc comment -
 * A Universally Unique Identifier (UUID) is a 128 bit number generated
 * according to an algorithm that is guaranteed to be unique in time and
 space
 * from all other UUIDs. It consists of an IEEE 802 Internet Address and
 * various time stamps to ensure uniqueness. For a complete specification,
 * see
 ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt [leach].

 Thank you for considering.
 -Tim Reilly


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateInteger.js validateFloatRange.js validateFloat.js validateEmail.js validateDate.js validateCreditCard.js validateByte.js

[rleland]

rleland 2003/08/15 13:20:40

  Modified:validator/src/javascript/org/apache/commons/validator/javascript
validateInteger.js validateFloatRange.js
validateFloat.js validateEmail.js validateDate.js
validateCreditCard.js validateByte.js
  Log:
  Place CVS version info in file.
  
  Revision  ChangesPath
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateInteger.js
  
  Index: validateInteger.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateInteger.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateInteger.js18 May 2003 21:34:41 -  1.1
  +++ validateInteger.js15 Aug 2003 20:20:40 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateInteger(form) {
   var bValid = true;
  
  
  
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateFloatRange.js
  
  Index: validateFloatRange.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateFloatRange.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateFloatRange.js 18 May 2003 21:35:37 -  1.1
  +++ validateFloatRange.js 15 Aug 2003 20:20:40 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateFloatRange(form) {
   var isValid = true;
  
  
  
  1.3   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateFloat.js
  
  Index: validateFloat.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateFloat.js,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- validateFloat.js  15 Aug 2003 18:30:29 -  1.2
  +++ validateFloat.js  15 Aug 2003 20:20:40 -  1.3
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateFloat(form) {
   var bValid = true;
  
  
  
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateEmail.js
  
  Index: validateEmail.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateEmail.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateEmail.js  18 May 2003 21:36:21 -  1.1
  +++ validateEmail.js  15 Aug 2003 20:20:40 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateEmail(form) {
   var bValid = true;
  
  
  
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateDate.js
  
  Index: validateDate.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateDate.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateDate.js   18 May 2003 21:36:34 -  1.1
  +++ validateDate.js   15 Aug 2003 20:20:40 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateDate(form) {
  var bValid = true;
  
  
  
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js
  
  Index: validateCreditCard.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateCreditCard.js 18 May 2003 21:36:56 -  1.1
  +++ validateCreditCard.js 15 Aug 2003 20:20:40 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateCreditCard(form) {
   var bValid = true;
  
  
  
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateByte.js
  
  Index: validateByte.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateByte.js,v
  retrieving revision 1.1
  retrieving 

cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateShort.js validateMinLength.js validateMaxLength.js validateMask.js validateIntRange.js

[rleland]

rleland 2003/08/15 13:22:03

  Modified:validator/src/javascript/org/apache/commons/validator/javascript
validateShort.js validateMinLength.js
validateMaxLength.js validateMask.js
validateIntRange.js
  Log:
  Place CVS version info in file.
  
  Revision  ChangesPath
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateShort.js
  
  Index: validateShort.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateShort.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateShort.js  18 May 2003 21:34:41 -  1.1
  +++ validateShort.js  15 Aug 2003 20:22:03 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateShort(form) {
   var bValid = true;
  
  
  
  1.3   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
  
  Index: validateMinLength.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- validateMinLength.js  25 Jun 2003 02:11:41 -  1.2
  +++ validateMinLength.js  15 Aug 2003 20:22:03 -  1.3
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateMinLength(form) {
   var isValid = true;
  
  
  
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
  
  Index: validateMaxLength.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateMaxLength.js  18 May 2003 21:35:37 -  1.1
  +++ validateMaxLength.js  15 Aug 2003 20:22:03 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateMaxLength(form) {
   var isValid = true;
  
  
  
  1.2   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMask.js
  
  Index: validateMask.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMask.js,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- validateMask.js   18 May 2003 21:36:06 -  1.1
  +++ validateMask.js   15 Aug 2003 20:22:03 -  1.2
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateMask(form) {
   var isValid = true;
  
  
  
  1.3   +4 -0  
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateIntRange.js
  
  Index: validateIntRange.js
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateIntRange.js,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- validateIntRange.js   30 Jul 2003 03:28:55 -  1.2
  +++ validateIntRange.js   15 Aug 2003 20:22:03 -  1.3
  @@ -1,3 +1,7 @@
  +  //$Header$
  +  //$Revision$
  +  //$Date$
  +
   
   function validateIntRange(form) {
   var isValid = true;
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/native location.c

[remm]

remm2003/08/15 13:36:27

  Modified:daemon/src/native/unix/native location.c
  Log:
  - Fix typo.
  - Add new location for Sun's client VM.
  
  Revision  ChangesPath
  1.6   +3 -2  jakarta-commons-sandbox/daemon/src/native/unix/native/location.c
  
  Index: location.c
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/location.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- location.c10 Jun 2003 15:42:11 -  1.5
  +++ location.c15 Aug 2003 20:36:27 -  1.6
  @@ -76,7 +76,7 @@
   /usr/local/java,
   #elif defined(OS_CYGWIN)
   /cygdrive/c/WINNT/system32/java,
  -#elfif defined(OS_SYSV)
  +#elif defined(OS_SYSV)
   /opt/java,
   /opt/java/jdk13,
   #endif
  @@ -101,6 +101,7 @@
   $JAVA_HOME/../Libraries/libjvm.dylib,
   #elif defined(OS_CYGWIN)
   $JAVA_HOME/jre/bin/classic/jvm.dll,   /* Sun JDK 1.3 */
  +$JAVA_HOME/jre/bin/client/jvm.dll,/* Sun JDK 1.4 */
   #elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD) || 
defined(OS_SYSV)
   $JAVA_HOME/jre/lib/ CPU /classic/libjvm.so, /* Sun JDK 1.2 */
   $JAVA_HOME/jre/lib/ CPU /client/libjvm.so,  /* Sun JDK 1.3 */
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/native Makefile.in

[remm]

remm2003/08/15 13:40:37

  Modified:daemon/src/native/unix/native Makefile.in
  Log:
  - Build the jsvc binary one level up. Since the binaries won't be distributed,
there was no point putting them in the dist folder.
  
  Revision  ChangesPath
  1.6   +3 -4  
jakarta-commons-sandbox/daemon/src/native/unix/native/Makefile.in
  
  Index: Makefile.in
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/Makefile.in,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- Makefile.in   19 Sep 2002 16:48:47 -  1.5
  +++ Makefile.in   15 Aug 2003 20:40:37 -  1.6
  @@ -78,9 +78,8 @@
$(RANLIB) libservice.a
   
   jsvc: jsvc-unix.o libservice.a
  - mkdir -p ../../../../dist
  - $(LDCMD) $(LDFLAGS) jsvc-unix.o libservice.a -o ../../../../dist/jsvc
  + $(LDCMD) $(LDFLAGS) jsvc-unix.o libservice.a -o ../jsvc
   
   clean:
  - rm -f $(OBJS) ../../../../dist/jsvc jsvc-unix.o libservice.a
  + rm -f $(OBJS) ../jsvc jsvc-unix.o libservice.a
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/daemon build.xml

[remm]

remm2003/08/15 13:52:25

  Modified:daemon   build.xml
  Log:
  - Add a jsvc prefix to the tarred sources.
  
  Revision  ChangesPath
  1.10  +3 -3  jakarta-commons-sandbox/daemon/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/daemon/build.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- build.xml 5 Jun 2003 18:18:25 -   1.9
  +++ build.xml 15 Aug 2003 20:52:25 -  1.10
  @@ -204,7 +204,7 @@
 target name=dist depends=compile,javadoc
  description=Create binary distribution
   mkdir  dir=${dist.home}/
  -mkdir  dir=${dist.home}/bin/unix/
  +mkdir  dir=${dist.home}/bin/unix/jsvc/
   mkdir  dir=${dist.home}/lib/
   mkdir  dir=${dist.home}/logs/
   copy  file=LICENSE
  @@ -216,7 +216,7 @@
include name=*.exe /
 /fileset
   /copy
  -copy todir=${dist.home}/bin/unix
  +copy todir=${dist.home}/bin/unix/jsvc
 fileset dir=src/native/unix /
   /copy
   fixcrlf srcdir=${dist.home}/bin/unix eol=lf /
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [combo] Commons Core release?

[Stephen Colebourne]

I haven't added to the debate up till now as I wanted to see how things
went.

Firstly, my definition of 'core' is basic extensions to the JDK, no config
files, no logging, no framework.
lang
io
collections
codec (never looked at it, but may fit)
cli?? (never looked at it, but may be more framework like)

BeanUtils ought to be included, however it has been written to use logging.
I believe this to be wrong, but this is an old decision, hard to change.

JDK1.2 should be the baseline.

However, it is clear that this division is just one of many that can occur.
It makes most sense to me, but others disagree. Given the current commons
structure I would suggest agreement on the contents of core is highly
unlikely.

One way out would be a separate mailing list, or maybe a separate
Jakarta-Core subproject. Then a single release could be created. However,
this also seems to fail the reality check.

Originally, I supported commons core, by promoting collections, io, pattern
(deceased), beanutils to all depend on lang, thus forming a nice group. Now
it seems that the more independent absolute minimum dependencies route is
actually simpler for everyone. A little code duplication may occur, but that
is better than additional dependencies.

My answer to the users - just deal with the jars. Its not that hard, and
creating a combo or core jar creates really nasty versioning issues, as
commons projects release to their own timescales, not one. One product = One
jar.

Stephen

NOTE: If Java was OSS and we were in charge of adding new functions to the
JDK, matters might be different. But as outside libraries, the midset must
be different.

- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
 Last November [I think] Craig created the Combo project. It puts a whole
 lot of Commons projects into one jar and makes them available in a much
 simpler form to users.

 This is the biggest complaint about Commons at the moment [I think], that
 we have some kind of reproduction of jars going on in which more and more
 jars appear in the user's code.

 I'd like to consider a release as such from Combo of what some of us were
 calling Commons Core a while back. It's an implementation of the Combo
 ant-scripts [currently I copy and paste, but it shouldn't be hard for me
 to make a single build.xml and a shared properties file per
 'distribution' with enough Ant learning].

 My current criteria is that Commons Core _only_ depends on JDK1.4 [and
 cross-dependencies inside the distribution]. Currently I have:

 =
 Apache Commons Core v1.0 consists of:

 Jakarta Commons BeanUtils 1.6.1
 Makes the JavaBean specification easier to deal with.

 Jakarta Commons CLI 1.0
 A command line interpreter. Used to handle all the flags passed to
your
 program on the command line.

 Jakarta Commons Codec 1.1
 Common encoders and decoders.

 Jakarta Commons Collections 2.1
 Many more implementations that fit the Collections API.

 Jakarta Commons Lang 1.0.1
 Enhancements to classes found in java.lang.
 ===

 A url to a build is: http://www.apache.org/~bayard/commons-core/

 I'm doing some trickery to turn BeanUtils' commons-logging dependency into
 a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient
 and maybe Net [with some regexp trickery] and consider that a version 1.0.

 Issues I forsee
 ===

 *) Combo has never been voted into Commons-proper. How do we handle this?
 It's not a new codebase but a release mechanism.

 *) Arguments over what goes in what. Rather than create a huge jar of
 everything, which I think is unpalatable to the user, I chose the JDK 1.4
 dependency as a strict guideline and tried to make things toe the line.
 Effectively it's a Commons-J2SE distribution for adding features to a
 new J2SE install.

 *) Testing. In Core 1.0 I've chosen the latest stable releases [except
 HttpClient which is at RC2] of each project. There are no
 interdependencies, but as projects depend on each other the building of a
 combo jar becomes trickier. This is a problem for the future probably.
 Possibly the solution is that after each component is built/tested, and
 the new uber-jar is built, the tests should be re-run against that jar.

 

 My general idea for Combo is that it is a tool for creating distributions
 of Commons code. These distributions are effectively configurations of
 Combo. I'm not sure if Craig is +1 or -1 for this and what his
 original plans were, but I think there's a need for a solution and that
 this is a solution.

 No idea if it's a good solution :) It seems quite fun and interesting.

 Any ideas? Flames?

 My chief two concerns are:


 1) Can I treat Combo as a Commons Proper project.
 2) Is the idea of a Commons Core distribution viable.


 Hen


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] NotifyingCollections - the wrapping problem

[Stephen Colebourne]

This isn't the problem case. Think about:

  Collection c = new ArrayList();
  ObservableCollection oc = CollectionUtils.observableCollection(c);
  SynchronizedCollection sc = CollectionUtils.synchronizedCollection(oc);
  oc.addListener(new CollectionListener() {
public void changed(CollectionEvent e) { Collection eventCollection =
e.getCollection() }
   });

  c.add();
Fails - but all decorators ban this because c is decorated

  oc.add();
Sends event OK - eventCollection == oc, but all decorators ban this because
oc is decorated

  sc.add();
Sends event OK - BUT eventCollection == oc.
This is a problem, as if the listener then uses the collection, it will not
be synchronized. Big problem.

Stephen

- Original Message -
From: Michael Heuer [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, August 14, 2003 11:02 PM
Subject: Re: [collections] NotifyingCollections - capturing rich non-uniform
data



 On Thu, 14 Aug 2003, Stephen Colebourne wrote:

  snip
 
  The biggest problem with all this is that the collection returned by
  getSource() on the event. If the observed collection is wrapped (eg. by
a
  SyncronizedCollection) then getSource() SHOULD return the wrapped
  collection, but it can't as it doesn't know about it. This problem
applies
  to all designs so far.

 Is this also a problem?  It's general to all of the delegation
 implementations.


  private boolean heardChange = false;

  public void testChangeToBackingCollection()
  {
   Collection c = new ArrayList();
   ObservableCollection oc = CollectionUtils.observableCollection(c);
   oc.addListener(new CollectionListener()
{
 public void changed(CollectionEvent e) { heardChange = true; }
});

   c.add(hello);

   assertTrue(heardChange == true, heardChange == true);
  }


 I don't think it's possible to make this test pass -- just a
 shortcoming of the wrapper design.  That's why I was looking into
 aspect-based implementations.

michael


 -
 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: [collections] NotifyingCollections - the wrapping problem

[Chuck Daniels]

 -Original Message-
 From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
 Sent: Saturday, August 16, 2003 8:01 AM
 To: Jakarta Commons Developers List
 Subject: Re: [collections] NotifyingCollections - the wrapping problem


 This isn't the problem case. Think about:

   Collection c = new ArrayList();
   ObservableCollection oc = CollectionUtils.observableCollection(c);
   SynchronizedCollection sc = CollectionUtils.synchronizedCollection(oc);
   oc.addListener(new CollectionListener() {
 public void changed(CollectionEvent e) { Collection eventCollection =
 e.getCollection() }
});

   c.add();
 Fails - but all decorators ban this because c is decorated

   oc.add();
 Sends event OK - eventCollection == oc, but all decorators ban
 this because
 oc is decorated

   sc.add();
 Sends event OK - BUT eventCollection == oc.
 This is a problem, as if the listener then uses the collection,
 it will not
 be synchronized. Big problem.

I don't think this will actually be a problem.  If calls to sc are
synchronized, then anything that the listener does to the backing collection
(oc in this case) is still within the context of the synchronized call on
sc.  Therefore, access to the backing collection is indirectly synchronized.
Or am I missing something here?


 Stephen

 - Original Message -
 From: Michael Heuer [EMAIL PROTECTED]
 To: Jakarta Commons Developers List [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Thursday, August 14, 2003 11:02 PM
 Subject: Re: [collections] NotifyingCollections - capturing rich
 non-uniform
 data


 
  On Thu, 14 Aug 2003, Stephen Colebourne wrote:
 
   snip
  
   The biggest problem with all this is that the collection returned by
   getSource() on the event. If the observed collection is
 wrapped (eg. by
 a
   SyncronizedCollection) then getSource() SHOULD return the wrapped
   collection, but it can't as it doesn't know about it. This problem
 applies
   to all designs so far.
 
  Is this also a problem?  It's general to all of the delegation
  implementations.
 
 
   private boolean heardChange = false;
 
   public void testChangeToBackingCollection()
   {
Collection c = new ArrayList();
ObservableCollection oc = CollectionUtils.observableCollection(c);
oc.addListener(new CollectionListener()
 {
  public void changed(CollectionEvent e) { heardChange = true; }
 });
 
c.add(hello);
 
assertTrue(heardChange == true, heardChange == true);
   }
 
 
  I don't think it's possible to make this test pass -- just a
  shortcoming of the wrapper design.  That's why I was looking into
  aspect-based implementations.
 
 michael
 
 
  -
  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: UUID Reuse proposal

[Phil Steitz]

Having looked now at both implementations (assuming the axis impl is what's
in CVS at
http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis/components/uuid/),
I agree that the tyrex implementation is better for two reasons:

1. It appears to be threadsafe.

2. It allows the node ID to be read from a properties file (getting around
the inaccessability of the MAC address in Java).

The axis implementation uses random bits from a SecureRandom initialized in
a static initialization block for the node ID. I don't see the big value in
a UUID implementation that uses random bits for the node ID.  While you can
get very low probability of collision like this, it is no longer
guaranteed, so why not just use a purely random string (which lang already
has in RandomStringUtils)?  The only value that remains in the UUID
algorithm when you remove the U is that it is a standard and you can
decompose it into the time bits and the node bits. 

I do like the idea of lang providing a home for IdentifierUtils suitably
named and packaged.  There are really multiple types here:  

 * UUID (pseudo) standard, non-random, non-secure 
 * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
 * Random, secure, not guaranteed unique (e.g. Tomcat session IDs)
 * Part random, secure, guaranteed unique (what Tomcat really needs ;-)
 * Bounded sequential(e.g. Betwixt's io identifiers)
 * Cyclic

I am still +1 for including a good implementation of the UUID pseudo-spec. 
Starting with the tyrex base would probably be easier; but we could
certainly just add the necessary features to the axis impl.

Phil


--- Tim Anderson [EMAIL PROTECTED] wrote:
 Tyrex also provides support for UUID generation, and
 should perform better than the Axis impl.
 
 See

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
 rvices/UUID.java?rev=1.6
 
 -Tim
 
  -Original Message-
  From: Tim Reilly [mailto:[EMAIL PROTECTED]
  Sent: Friday, 15 August 2003 11:32 AM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: UUID Reuse proposal
 
 
  I'd like to ask the axis developers to donate the java package
  org.apache.axis.components.uuid to the Jakarta commons.
 
  I'm cross-posting this message on both jakarta commons-dev list
  and axis-dev
  list as commons could adopt this package and place somewhere
  sensible to the
  commons. My suggestion would be as an addition to
 org.apache.commons.lang
  since the UUID is a special/complex type (aren't all classes, but
  hopefully
  you know what I'm saying.)
  I know not to cross-post but given the request it only makes sense. I
  realize the package has some basis on the similar package in the BSD
  licensed http://sourceforge.net/projects/juddi/ project. It doesn't
 make
  sense to include the UUIDGenFactory, which would remain in place
 (unless
  anyone has good ideas on making it more generic?)
 
  The reason for this request is that the package is nicely written
  (kudos to
  the author(s)), and very useful in a number of applications. The
 Jetspeed
  developers can use this package; however it does not necessarily
  make sense
  for Jetspeed to create a dependency on the axis jar, solely to use this
  package. There are numerous other applications of UUID's that make it
 an
  ideal candidate for the Jakarta-commons, and I feel that
 donating/adopting
  this package within the commons fits nicely with the vision of
  the commons.
  Other uses abound, for example struts could use the classes to
 guarantee a
  form is submitted only once. A search of theserverside.com brings
  back some
  patterns that use guid/uuid.
 
  I'd be willing to send the patches to the Axis team if the commons
  committers are willing to adopt the package and Axis wishes the same.
  Basically this would be to depreciate
  org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend
  org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the
  org.apache.axis.components.uuid.SimpleUUID strings within the CVS. Or
 if
  there is a better way.. I'd be will to do whatever is agreed upon.
 
  Please consider this request; I'll keep an eye on each list and if both
  projects agree that would be great and we can proceed.
  A lesser alternative would be for jakarta-commons to adopt the
  package, but
  axis makes no changes. This is the perhaps the lesser approach since
 reuse
  is not fully accomplished but if the Axis committers are reluctant then
  perhaps they could give their okays to the lesser approach, and
  jakarta-commons could still adopt the classes.
 
  For more information on UUID:
  Per javadoc comment -
  * A Universally Unique Identifier (UUID) is a 128 bit number generated
  * according to an algorithm that is guaranteed to be unique in time and
  space
  * from all other UUIDs. It consists of an IEEE 802 Internet Address and
  * various time stamps to ensure uniqueness. For a complete
 specification,
  * see
  

Re: [collections] NotifyingCollections - the wrapping problem

[Stephen Colebourne]

From: Chuck Daniels [EMAIL PROTECTED]
sc.add();
  Sends event OK - BUT eventCollection == oc.
  This is a problem, as if the listener then uses the collection,
  it will not
  be synchronized. Big problem.

 I don't think this will actually be a problem.  If calls to sc are
 synchronized, then anything that the listener does to the backing
collection
 (oc in this case) is still within the context of the synchronized call on
 sc.  Therefore, access to the backing collection is indirectly
synchronized.
 Or am I missing something here?

Intruiging. Yes, you are probably correct, so long as the listener operates
in the same thread in a normal fashion. I was thinking of trying to spot if
the ObservedCollection was being decorated and inform it, but maybe thats
over zealous, and javadoc will do.

Stephen





  - Original Message -
  From: Michael Heuer [EMAIL PROTECTED]
  To: Jakarta Commons Developers List [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  Sent: Thursday, August 14, 2003 11:02 PM
  Subject: Re: [collections] NotifyingCollections - capturing rich
  non-uniform
  data
 
 
  
   On Thu, 14 Aug 2003, Stephen Colebourne wrote:
  
snip
   
The biggest problem with all this is that the collection returned by
getSource() on the event. If the observed collection is
  wrapped (eg. by
  a
SyncronizedCollection) then getSource() SHOULD return the wrapped
collection, but it can't as it doesn't know about it. This problem
  applies
to all designs so far.
  
   Is this also a problem?  It's general to all of the delegation
   implementations.
  
  
private boolean heardChange = false;
  
public void testChangeToBackingCollection()
{
 Collection c = new ArrayList();
 ObservableCollection oc = CollectionUtils.observableCollection(c);
 oc.addListener(new CollectionListener()
  {
   public void changed(CollectionEvent e) { heardChange = true; }
  });
  
 c.add(hello);
  
 assertTrue(heardChange == true, heardChange == true);
}
  
  
   I don't think it's possible to make this test pass -- just a
   shortcoming of the wrapper design.  That's why I was looking into
   aspect-based implementations.
  
  michael
  
  
   -
   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]

Re: [combo] Commons Core release?

[Rodney Waldhoff]

On Thu, 14 Aug 2003, Henri Yandell wrote:

 Forcing a user of three api's to grab
 dependencies for 12 other api's is going to kill combo dead in the water.

An observation: a user of 3 APIs doesn't need to grab any external
dependencies outside of those three APIs. If you never load or use the
dependent classes, you never need to load their dependencies.

For example:

 Commons-Logging:  log4j. logkit. avalon-framework.

Commons-Logging runs just fine without log4j, logkit, or avalon-framework.
Compiling Commons-Logging without these things is a different matter, of
course.

Similarly:

 it would not contain HttpClient (?) which I
 thought might be 1.4 dependent now for SSL and would not include BeanUtils
 with the current api munging.

If you're not using HTTPS support within HttpClient, you don't
need to have the SSL libraries (which weren't 1.4 dependent when I last
checked) around either.


Including a component (such as Latka or Jelly, for example) with
dependencies on a large number of external JARs would not require all
users of commons-combo to grab those external JARs. (Of course, neither
Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be
included anyway.)


   I'm doing some trickery to turn BeanUtils' commons-logging dependency into
   a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient
   and maybe Net [with some regexp trickery] and consider that a version 1.0.
  
 
  We can talk about that on a [beanutils] specific thread, but I'd be -1 on
  doing this to the real BeanUtils code.  A very large number of BeanUtils
  users do not have the luxury to run on a 1.4 JDK.

 Yeah, I've no desire to apply this to the BeanUtils code itself, and doing
 said munging concerns me that we might introduce bugs. However,
 commons-logging is not self-contained and therefore would invalidate
 commons-beanutils.

Creating a comons-beanutils-for-commons-core.jar that's different from
commons-beanutils.jar is an extremely bad idea IMO. This creates a much
worse problem than the one commons-core/commons-combo is trying to solve.

- Rod http://radio.weblogs.com/0122027/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [combo] Commons Core release?

[Henri Yandell]

On Fri, 15 Aug 2003, Rodney Waldhoff wrote:

 On Thu, 14 Aug 2003, Henri Yandell wrote:

  Forcing a user of three api's to grab
  dependencies for 12 other api's is going to kill combo dead in the water.

 An observation: a user of 3 APIs doesn't need to grab any external
 dependencies outside of those three APIs. If you never load or use the
 dependent classes, you never need to load their dependencies.

It's very hard to know though. I look at the dependency list and it says
it needs 5 jars. We don't publish a 'you need this jar for this, this jar
for this' list. Also, who wants to trust that?

Only power users will be able to deal with this easily, and they have no
need for a combo jar.

 For example:

  Commons-Logging:  log4j. logkit. avalon-framework.

 Commons-Logging runs just fine without log4j, logkit, or avalon-framework.
 Compiling Commons-Logging without these things is a different matter, of
 course.

 Similarly:

  it would not contain HttpClient (?) which I
  thought might be 1.4 dependent now for SSL and would not include BeanUtils
  with the current api munging.

 If you're not using HTTPS support within HttpClient, you don't
 need to have the SSL libraries (which weren't 1.4 dependent when I last
 checked) around either.

They come with 1.4 I believe.

 Including a component (such as Latka or Jelly, for example) with
 dependencies on a large number of external JARs would not require all
 users of commons-combo to grab those external JARs. (Of course, neither
 Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be
 included anyway.)

Automating a build of this gets difficult I believe, plus you'd have to
not run certain tests. It feels like a rather manual solution.

I'm doing some trickery to turn BeanUtils' commons-logging dependency into
a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient
and maybe Net [with some regexp trickery] and consider that a version 1.0.
   
  
   We can talk about that on a [beanutils] specific thread, but I'd be -1 on
   doing this to the real BeanUtils code.  A very large number of BeanUtils
   users do not have the luxury to run on a 1.4 JDK.
 
  Yeah, I've no desire to apply this to the BeanUtils code itself, and doing
  said munging concerns me that we might introduce bugs. However,
  commons-logging is not self-contained and therefore would invalidate
  commons-beanutils.

 Creating a comons-beanutils-for-commons-core.jar that's different from
 commons-beanutils.jar is an extremely bad idea IMO. This creates a much
 worse problem than the one commons-core/commons-combo is trying to solve.

Yeah. It should instead be commons-beanutils.jar which depends on
commons-logging-api.jar.

Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator/util ValidatorUtils.java

[dgraham]

dgraham 2003/08/15 16:44:19

  Modified:validator/src/share/org/apache/commons/validator/util
ValidatorUtils.java
  Log:
  Changed getValueAsString() to return  for empty String[]s and Collections.
  This allows easier validation of lists.  PR# 22121.
  
  Revision  ChangesPath
  1.3   +39 -18
jakarta-commons/validator/src/share/org/apache/commons/validator/util/ValidatorUtils.java
  
  Index: ValidatorUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/util/ValidatorUtils.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ValidatorUtils.java   25 May 2003 18:18:31 -  1.2
  +++ ValidatorUtils.java   15 Aug 2003 23:44:19 -  1.3
  @@ -62,6 +62,7 @@
   package org.apache.commons.validator.util;
   
   import java.lang.reflect.InvocationTargetException;
  +import java.util.Collection;
   import java.util.Iterator;
   
   import org.apache.commons.beanutils.PropertyUtils;
  @@ -97,6 +98,7 @@
String value,
String key,
String replaceValue) {
  +
if (value == null || key == null || replaceValue == null) {
return value;
}
  @@ -113,8 +115,10 @@
   
if (length == key.length()) {
value = replaceValue;
  +
} else if (end == length) {
value = value.substring(0, start) + replaceValue;
  +
} else {
value =
value.substring(0, start)
  @@ -127,24 +131,41 @@
   
/**
 * Convenience method for getting a value from a bean property as a 
  -  * codeString/code.
  +  * codeString/code.  If the property is a codeString[]/code or 
  + * codeCollection/code and it is empty, an empty codeString/code 
  + *  is returned.  Otherwise, property.toString() is returned.  This method
  + * may return codenull/code if there was an error retrieving the 
  + * property.
 */
  - public static String getValueAsString(Object bean, String property) {
  - Object value = null;
  +public static String getValueAsString(Object bean, String property) {
  +Object value = null;
   
  - try {
  - value = PropertyUtils.getProperty(bean, property);
  +try {
  +value = PropertyUtils.getProperty(bean, property);
   
  - } catch (IllegalAccessException e) {
  - log.error(e.getMessage(), e);
  - } catch (InvocationTargetException e) {
  - log.error(e.getMessage(), e);
  - } catch (NoSuchMethodException e) {
  - log.error(e.getMessage(), e);
  - }
  +} catch (IllegalAccessException e) {
  +log.error(e.getMessage(), e);
  +} catch (InvocationTargetException e) {
  +log.error(e.getMessage(), e);
  +} catch (NoSuchMethodException e) {
  +log.error(e.getMessage(), e);
  +}
  +
  +if (value == null) {
  +return null;
  +}
  +
  +if (value instanceof String[]) {
  +return ((String[]) value).length  0 ? value.toString() : ;
  +
  +} else if (value instanceof Collection) {
  +return ((Collection) value).isEmpty() ?  : value.toString();
  +
  +} else {
  +return value.toString();
  +}
   
  - return (value != null ? value.toString() : null);
  - }
  +}
   
/**
 * Makes a deep copy of a codeFastHashMap/code if the values 
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/httpclient/xdocs authentication.xml

[adrian]

adrian  2003/08/15 17:09:37

  Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH NTLM.java NTCredentials.java
   httpclient/src/java/org/apache/commons/httpclient/auth Tag:
HTTPCLIENT_2_0_BRANCH NTLMScheme.java
   httpclient/xdocs Tag: HTTPCLIENT_2_0_BRANCH
authentication.xml
  Log:
  Removed auto-configuration of JCE and updated documentation relating to NTLM.
  
  PR: Bug 22073 and Bug 22424
  Reviewed by:  Oleg Kalnichevski and Michael Becke
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.12.2.1  +24 -39
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/Attic/NTLM.java
  
  Index: NTLM.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/Attic/NTLM.java,v
  retrieving revision 1.12
  retrieving revision 1.12.2.1
  diff -u -r1.12 -r1.12.2.1
  --- NTLM.java 11 Feb 2003 03:41:14 -  1.12
  +++ NTLM.java 16 Aug 2003 00:09:37 -  1.12.2.1
  @@ -66,7 +66,6 @@
   import java.io.UnsupportedEncodingException;
   import java.security.InvalidKeyException;
   import java.security.NoSuchAlgorithmException;
  -import java.security.Security;
   
   import javax.crypto.BadPaddingException;
   import javax.crypto.Cipher;
  @@ -86,6 +85,12 @@
* protocol is a proprietary Microsoft protocol and as such no RFC
* exists for it.  This class is based upon the reverse engineering
* efforts of a wide range of people./p
  + * 
  + * pPlease note that an implementation of JCE must be correctly installed and 
configured when
  + * using NTLM support./p
  + * 
  + * pThis class should not be used externally to HttpClient as it's API is 
specifically
  + * designed to work with HttpClient's use case, in particular it's connection 
management./p
*
* @deprecated this class will be made package access for 2.0beta2
*
  @@ -110,31 +115,6 @@
   /** Character encoding */
   public static final String DEFAULT_CHARSET = ASCII;
   
  -//Initialize the security provider
  -static {
  -//TODO: do not use System properties
  -final String secProviderName 
  -= System.getProperty(httpclient.security.provider,
  -com.sun.crypto.provider.SunJCE);
  -try {
  -java.security.Provider secProvider = (java.security.Provider)
  -Class.forName(secProviderName).newInstance();
  -Security.addProvider(secProvider);
  -} catch (ClassNotFoundException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  could not be found by the class loader, e);
  -} catch (ClassCastException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  is not of type java.security.Provider, e);
  -} catch (InstantiationException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  could not be instantiated, e);
  -} catch (IllegalAccessException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  does not allow access to the constructor, e);
  -}
  -}
  -
   /**
* Returns the response for the given message.
*
  @@ -280,10 +260,12 @@
   }
   
   /**
  - * TODO: Figure out what this method really does.
  - * @param host The host
  - * @param domain The domain
  - * @return String
  + * Creates the first message (type 1 message) in the NTLM authentication 
sequence.
  + * This message includes the user name, domain and host for the authentication 
session.
  + * 
  + * @param host the computer name of the host requesting authentication.
  + * @param domain The domain to authenticate with.
  + * @return String the message to add to the HTTP request header.
*/
   private String getType1Message(String host, String domain) {
   host = host.toUpperCase();
  @@ -372,11 +354,14 @@
   }
   
   /** 
  - * Creates the type 3 message using the given server nonce.
  - * @param user The user.
  + * Creates the type 3 message using the given server nonce.  The type 3 message 
includes all the
  + * information for authentication, host, domain, username and the result of 
encrypting the
  + * nonce sent by the server using the user's password as the key.
  + * 
  + * @param user The user name.  This should not include the domain name.
* @param password The password.
  - * @param host The host.
  - * @param domain The domain.
  + * @param host The host that is originating the authentication request.
  + * @param domain The domain to authenticate within.
* 

cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient NTCredentials.java

[adrian]

adrian  2003/08/15 17:41:24

  Modified:httpclient/src/java/org/apache/commons/httpclient/auth
NTLMScheme.java NTLM.java
   httpclient/xdocs authentication.xml
   httpclient/src/java/org/apache/commons/httpclient
NTCredentials.java
  Log:
  Removed auto-configuration of JCE and updated documentation relating to NTLM.
  
  PR: Bug 22073 and Bug 22424
  Reviewed by:  Oleg Kalnichevski and Michael Becke
  
  Revision  ChangesPath
  1.11  +10 -8 
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLMScheme.java
  
  Index: NTLMScheme.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLMScheme.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- NTLMScheme.java   13 Aug 2003 19:57:10 -  1.10
  +++ NTLMScheme.java   16 Aug 2003 00:41:24 -  1.11
  @@ -68,10 +68,9 @@
   import org.apache.commons.logging.Log;
   import org.apache.commons.logging.LogFactory;
   
  -/**
  - * p
  - * Microsoft proprietary NTLM authentication scheme.
  - * /p
  +/** An implementation of the Microsoft proprietary NTLM authentication scheme.  For 
a detailed
  + * explanation of the NTLM scheme please see a 
href=http://davenport.sourceforge.net/ntlm.html;
  + * http://davenport.sourceforge.net/ntlm.html/a.
* 
* @author a href=mailto:[EMAIL PROTECTED]Remy Maucherat/a
* @author Rodney Waldhoff
  @@ -154,7 +153,10 @@
   
   
   /**
  - * Returns authentication parameter with the given name, if available.
  + * Returns the authentication parameter with the given name, if available.
  + * 
  + * pThere are no valid parameters for NTLM authentication so this method 
always returns
  + * ttnull/tt./p
* 
* @param name The name of the parameter to be returned
* 
  
  
  
  1.4   +24 -39
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLM.java
  
  Index: NTLM.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/auth/NTLM.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- NTLM.java 22 Jul 2003 18:10:25 -  1.3
  +++ NTLM.java 16 Aug 2003 00:41:24 -  1.4
  @@ -66,7 +66,6 @@
   import java.io.UnsupportedEncodingException;
   import java.security.InvalidKeyException;
   import java.security.NoSuchAlgorithmException;
  -import java.security.Security;
   
   import javax.crypto.BadPaddingException;
   import javax.crypto.Cipher;
  @@ -88,6 +87,12 @@
* exists for it.  This class is based upon the reverse engineering
* efforts of a wide range of people./p
*
  + * pPlease note that an implementation of JCE must be correctly installed and 
configured when
  + * using NTLM support./p
  + *
  + * pThis class should not be used externally to HttpClient as it's API is 
specifically
  + * designed to work with HttpClient's use case, in particular it's connection 
management./p
  + *
* @author a href=mailto:[EMAIL PROTECTED]Adrian Sutton/a
* @author a href=mailto:[EMAIL PROTECTED]Jeff Dever/a
* @author a href=mailto:[EMAIL PROTECTED]Mike Bowler/a
  @@ -109,31 +114,6 @@
   /** Character encoding */
   public static final String DEFAULT_CHARSET = ASCII;
   
  -//Initialize the security provider
  -static {
  -//TODO: do not use System properties
  -final String secProviderName 
  -= System.getProperty(httpclient.security.provider,
  -com.sun.crypto.provider.SunJCE);
  -try {
  -java.security.Provider secProvider = (java.security.Provider)
  -Class.forName(secProviderName).newInstance();
  -Security.addProvider(secProvider);
  -} catch (ClassNotFoundException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  could not be found by the class loader, e);
  -} catch (ClassCastException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  is not of type java.security.Provider, e);
  -} catch (InstantiationException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  could not be instantiated, e);
  -} catch (IllegalAccessException e) {
  -LOG.error(Specified security provider  + secProviderName 
  -+  does not allow access to the constructor, e);
  -}
  -}
  -
   /**
* Returns the response for the given message.
*
  @@ -278,10 +258,12 @@
   }
   
   /**
  - * TODO: Figure out what this method really does.
  - * @param host The host
  - * @param 

Re: UUID Reuse proposal

[Steve Downey]

I've posted a version of a UUID class previously that meets the random
number version of the leech spec.

Getting MAC addresses portably is mildly difficult, and requires root access
on most systems. Using a cryptographically good random number generator is a
reasonably good alternative, and if done right, won't collide with the UUIDs
generated using MAC addresses.

I've used them heavily for synthetic primary keys in database tables.

If there's interest, I could repost the class.

-SMD
- Original Message -
From: Phil Steitz [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 7:11 PM
Subject: RE: UUID Reuse proposal


 Having looked now at both implementations (assuming the axis impl is
what's
 in CVS at

http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis/component
s/uuid/),
 I agree that the tyrex implementation is better for two reasons:

 1. It appears to be threadsafe.

 2. It allows the node ID to be read from a properties file (getting around
 the inaccessability of the MAC address in Java).

 The axis implementation uses random bits from a SecureRandom initialized
in
 a static initialization block for the node ID. I don't see the big value
in
 a UUID implementation that uses random bits for the node ID.  While you
can
 get very low probability of collision like this, it is no longer
 guaranteed, so why not just use a purely random string (which lang already
 has in RandomStringUtils)?  The only value that remains in the UUID
 algorithm when you remove the U is that it is a standard and you can
 decompose it into the time bits and the node bits.

 I do like the idea of lang providing a home for IdentifierUtils suitably
 named and packaged.  There are really multiple types here:

  * UUID (pseudo) standard, non-random, non-secure
  * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
  * Random, secure, not guaranteed unique (e.g. Tomcat session IDs)
  * Part random, secure, guaranteed unique (what Tomcat really needs ;-)
  * Bounded sequential(e.g. Betwixt's io identifiers)
  * Cyclic

 I am still +1 for including a good implementation of the UUID pseudo-spec.
 Starting with the tyrex base would probably be easier; but we could
 certainly just add the necessary features to the axis impl.

 Phil


 --- Tim Anderson [EMAIL PROTECTED] wrote:
  Tyrex also provides support for UUID generation, and
  should perform better than the Axis impl.
 
  See
 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
  rvices/UUID.java?rev=1.6
 
  -Tim
 
   -Original Message-
   From: Tim Reilly [mailto:[EMAIL PROTECTED]
   Sent: Friday, 15 August 2003 11:32 AM
   To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
   Subject: UUID Reuse proposal
  
  
   I'd like to ask the axis developers to donate the java package
   org.apache.axis.components.uuid to the Jakarta commons.
  
   I'm cross-posting this message on both jakarta commons-dev list
   and axis-dev
   list as commons could adopt this package and place somewhere
   sensible to the
   commons. My suggestion would be as an addition to
  org.apache.commons.lang
   since the UUID is a special/complex type (aren't all classes, but
   hopefully
   you know what I'm saying.)
   I know not to cross-post but given the request it only makes sense. I
   realize the package has some basis on the similar package in the BSD
   licensed http://sourceforge.net/projects/juddi/ project. It doesn't
  make
   sense to include the UUIDGenFactory, which would remain in place
  (unless
   anyone has good ideas on making it more generic?)
  
   The reason for this request is that the package is nicely written
   (kudos to
   the author(s)), and very useful in a number of applications. The
  Jetspeed
   developers can use this package; however it does not necessarily
   make sense
   for Jetspeed to create a dependency on the axis jar, solely to use
this
   package. There are numerous other applications of UUID's that make it
  an
   ideal candidate for the Jakarta-commons, and I feel that
  donating/adopting
   this package within the commons fits nicely with the vision of
   the commons.
   Other uses abound, for example struts could use the classes to
  guarantee a
   form is submitted only once. A search of theserverside.com brings
   back some
   patterns that use guid/uuid.
  
   I'd be willing to send the patches to the Axis team if the commons
   committers are willing to adopt the package and Axis wishes the same.
   Basically this would be to depreciate
   org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend
   org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the
   org.apache.axis.components.uuid.SimpleUUID strings within the CVS.
Or
  if
   there is a better way.. I'd be will to do whatever is agreed upon.
  
   Please consider this request; I'll keep an eye on each list and if
both
   projects agree that 

Re: UUID Reuse proposal

[Steve Downey]

I've posted a version of a UUID class previously that meets the random
number version of the leech spec.

Getting MAC addresses portably is mildly difficult, and requires root access
on most systems. Using a cryptographically good random number generator is a
reasonably good alternative, and if done right, won't collide with the UUIDs
generated using MAC addresses.

I've used them heavily for synthetic primary keys in database tables.

If there's interest, I could repost the class.

-SMD
- Original Message -
From: Phil Steitz [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 7:11 PM
Subject: RE: UUID Reuse proposal


 Having looked now at both implementations (assuming the axis impl is
what's
 in CVS at

http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis/component
s/uuid/),
 I agree that the tyrex implementation is better for two reasons:

 1. It appears to be threadsafe.

 2. It allows the node ID to be read from a properties file (getting around
 the inaccessability of the MAC address in Java).

 The axis implementation uses random bits from a SecureRandom initialized
in
 a static initialization block for the node ID. I don't see the big value
in
 a UUID implementation that uses random bits for the node ID.  While you
can
 get very low probability of collision like this, it is no longer
 guaranteed, so why not just use a purely random string (which lang already
 has in RandomStringUtils)?  The only value that remains in the UUID
 algorithm when you remove the U is that it is a standard and you can
 decompose it into the time bits and the node bits.

 I do like the idea of lang providing a home for IdentifierUtils suitably
 named and packaged.  There are really multiple types here:

  * UUID (pseudo) standard, non-random, non-secure
  * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
  * Random, secure, not guaranteed unique (e.g. Tomcat session IDs)
  * Part random, secure, guaranteed unique (what Tomcat really needs ;-)
  * Bounded sequential(e.g. Betwixt's io identifiers)
  * Cyclic

 I am still +1 for including a good implementation of the UUID pseudo-spec.
 Starting with the tyrex base would probably be easier; but we could
 certainly just add the necessary features to the axis impl.

 Phil


 --- Tim Anderson [EMAIL PROTECTED] wrote:
  Tyrex also provides support for UUID generation, and
  should perform better than the Axis impl.
 
  See
 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
  rvices/UUID.java?rev=1.6
 
  -Tim
 
   -Original Message-
   From: Tim Reilly [mailto:[EMAIL PROTECTED]
   Sent: Friday, 15 August 2003 11:32 AM
   To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
   Subject: UUID Reuse proposal
  
  
   I'd like to ask the axis developers to donate the java package
   org.apache.axis.components.uuid to the Jakarta commons.
  
   I'm cross-posting this message on both jakarta commons-dev list
   and axis-dev
   list as commons could adopt this package and place somewhere
   sensible to the
   commons. My suggestion would be as an addition to
  org.apache.commons.lang
   since the UUID is a special/complex type (aren't all classes, but
   hopefully
   you know what I'm saying.)
   I know not to cross-post but given the request it only makes sense. I
   realize the package has some basis on the similar package in the BSD
   licensed http://sourceforge.net/projects/juddi/ project. It doesn't
  make
   sense to include the UUIDGenFactory, which would remain in place
  (unless
   anyone has good ideas on making it more generic?)
  
   The reason for this request is that the package is nicely written
   (kudos to
   the author(s)), and very useful in a number of applications. The
  Jetspeed
   developers can use this package; however it does not necessarily
   make sense
   for Jetspeed to create a dependency on the axis jar, solely to use
this
   package. There are numerous other applications of UUID's that make it
  an
   ideal candidate for the Jakarta-commons, and I feel that
  donating/adopting
   this package within the commons fits nicely with the vision of
   the commons.
   Other uses abound, for example struts could use the classes to
  guarantee a
   form is submitted only once. A search of theserverside.com brings
   back some
   patterns that use guid/uuid.
  
   I'd be willing to send the patches to the Axis team if the commons
   committers are willing to adopt the package and Axis wishes the same.
   Basically this would be to depreciate
   org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend
   org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the
   org.apache.axis.components.uuid.SimpleUUID strings within the CVS.
Or
  if
   there is a better way.. I'd be will to do whatever is agreed upon.
  
   Please consider this request; I'll keep an eye on each list and if
both
   projects agree that 

Re: UUID Reuse proposal

[Steve Downey]

I've posted a version of a UUID class previously that meets the random
number version of the leech spec.

Getting MAC addresses portably is mildly difficult, and requires root access
on most systems. Using a cryptographically good random number generator is a
reasonably good alternative, and if done right, won't collide with the UUIDs
generated using MAC addresses.

I've used them heavily for synthetic primary keys in database tables.

If there's interest, I could repost the class.

-SMD
- Original Message -
From: Phil Steitz [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 7:11 PM
Subject: RE: UUID Reuse proposal


 Having looked now at both implementations (assuming the axis impl is
what's
 in CVS at

http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis/component
s/uuid/),
 I agree that the tyrex implementation is better for two reasons:

 1. It appears to be threadsafe.

 2. It allows the node ID to be read from a properties file (getting around
 the inaccessability of the MAC address in Java).

 The axis implementation uses random bits from a SecureRandom initialized
in
 a static initialization block for the node ID. I don't see the big value
in
 a UUID implementation that uses random bits for the node ID.  While you
can
 get very low probability of collision like this, it is no longer
 guaranteed, so why not just use a purely random string (which lang already
 has in RandomStringUtils)?  The only value that remains in the UUID
 algorithm when you remove the U is that it is a standard and you can
 decompose it into the time bits and the node bits.

 I do like the idea of lang providing a home for IdentifierUtils suitably
 named and packaged.  There are really multiple types here:

  * UUID (pseudo) standard, non-random, non-secure
  * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
  * Random, secure, not guaranteed unique (e.g. Tomcat session IDs)
  * Part random, secure, guaranteed unique (what Tomcat really needs ;-)
  * Bounded sequential(e.g. Betwixt's io identifiers)
  * Cyclic

 I am still +1 for including a good implementation of the UUID pseudo-spec.
 Starting with the tyrex base would probably be easier; but we could
 certainly just add the necessary features to the axis impl.

 Phil


 --- Tim Anderson [EMAIL PROTECTED] wrote:
  Tyrex also provides support for UUID generation, and
  should perform better than the Axis impl.
 
  See
 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
  rvices/UUID.java?rev=1.6
 
  -Tim
 
   -Original Message-
   From: Tim Reilly [mailto:[EMAIL PROTECTED]
   Sent: Friday, 15 August 2003 11:32 AM
   To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
   Subject: UUID Reuse proposal
  
  
   I'd like to ask the axis developers to donate the java package
   org.apache.axis.components.uuid to the Jakarta commons.
  
   I'm cross-posting this message on both jakarta commons-dev list
   and axis-dev
   list as commons could adopt this package and place somewhere
   sensible to the
   commons. My suggestion would be as an addition to
  org.apache.commons.lang
   since the UUID is a special/complex type (aren't all classes, but
   hopefully
   you know what I'm saying.)
   I know not to cross-post but given the request it only makes sense. I
   realize the package has some basis on the similar package in the BSD
   licensed http://sourceforge.net/projects/juddi/ project. It doesn't
  make
   sense to include the UUIDGenFactory, which would remain in place
  (unless
   anyone has good ideas on making it more generic?)
  
   The reason for this request is that the package is nicely written
   (kudos to
   the author(s)), and very useful in a number of applications. The
  Jetspeed
   developers can use this package; however it does not necessarily
   make sense
   for Jetspeed to create a dependency on the axis jar, solely to use
this
   package. There are numerous other applications of UUID's that make it
  an
   ideal candidate for the Jakarta-commons, and I feel that
  donating/adopting
   this package within the commons fits nicely with the vision of
   the commons.
   Other uses abound, for example struts could use the classes to
  guarantee a
   form is submitted only once. A search of theserverside.com brings
   back some
   patterns that use guid/uuid.
  
   I'd be willing to send the patches to the Axis team if the commons
   committers are willing to adopt the package and Axis wishes the same.
   Basically this would be to depreciate
   org.apache.axis.components.uuid.SimpleUUID and make SimpleUUID extend
   org.apache.commons.lang.UUID.SimpleUUID (tentative). Then replace the
   org.apache.axis.components.uuid.SimpleUUID strings within the CVS.
Or
  if
   there is a better way.. I'd be will to do whatever is agreed upon.
  
   Please consider this request; I'll keep an eye on each list and if
both
   projects agree that 

Re: UUID Reuse proposal

[Steve Downey]

Apologies for the triple post, but power just glitched here again, and my
mail hiccuped.

-SMD
- Original Message -
From: Steve Downey [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, August 15, 2003 10:25 PM
Subject: Re: UUID Reuse proposal


 I've posted a version of a UUID class previously that meets the random
 number version of the leech spec.

 Getting MAC addresses portably is mildly difficult, and requires root
access
 on most systems. Using a cryptographically good random number generator is
a
 reasonably good alternative, and if done right, won't collide with the
UUIDs
 generated using MAC addresses.

 I've used them heavily for synthetic primary keys in database tables.

 If there's interest, I could repost the class.

 -SMD
 - Original Message -
 From: Phil Steitz [EMAIL PROTECTED]
 To: Jakarta Commons Developers List [EMAIL PROTECTED];
 [EMAIL PROTECTED]
 Sent: Friday, August 15, 2003 7:11 PM
 Subject: RE: UUID Reuse proposal


  Having looked now at both implementations (assuming the axis impl is
 what's
  in CVS at
 

http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis/component
 s/uuid/),
  I agree that the tyrex implementation is better for two reasons:
 
  1. It appears to be threadsafe.
 
  2. It allows the node ID to be read from a properties file (getting
around
  the inaccessability of the MAC address in Java).
 
  The axis implementation uses random bits from a SecureRandom initialized
 in
  a static initialization block for the node ID. I don't see the big value
 in
  a UUID implementation that uses random bits for the node ID.  While you
 can
  get very low probability of collision like this, it is no longer
  guaranteed, so why not just use a purely random string (which lang
already
  has in RandomStringUtils)?  The only value that remains in the UUID
  algorithm when you remove the U is that it is a standard and you can
  decompose it into the time bits and the node bits.
 
  I do like the idea of lang providing a home for IdentifierUtils
suitably
  named and packaged.  There are really multiple types here:
 
   * UUID (pseudo) standard, non-random, non-secure
   * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
   * Random, secure, not guaranteed unique (e.g. Tomcat session IDs)
   * Part random, secure, guaranteed unique (what Tomcat really needs
;-)
   * Bounded sequential(e.g. Betwixt's io identifiers)
   * Cyclic
 
  I am still +1 for including a good implementation of the UUID
pseudo-spec.
  Starting with the tyrex base would probably be easier; but we could
  certainly just add the necessary features to the axis impl.
 
  Phil
 
 
  --- Tim Anderson [EMAIL PROTECTED] wrote:
   Tyrex also provides support for UUID generation, and
   should perform better than the Axis impl.
  
   See
  
 

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se
   rvices/UUID.java?rev=1.6
  
   -Tim
  
-Original Message-
From: Tim Reilly [mailto:[EMAIL PROTECTED]
Sent: Friday, 15 August 2003 11:32 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: UUID Reuse proposal
   
   
I'd like to ask the axis developers to donate the java package
org.apache.axis.components.uuid to the Jakarta commons.
   
I'm cross-posting this message on both jakarta commons-dev list
and axis-dev
list as commons could adopt this package and place somewhere
sensible to the
commons. My suggestion would be as an addition to
   org.apache.commons.lang
since the UUID is a special/complex type (aren't all classes, but
hopefully
you know what I'm saying.)
I know not to cross-post but given the request it only makes sense.
I
realize the package has some basis on the similar package in the BSD
licensed http://sourceforge.net/projects/juddi/ project. It doesn't
   make
sense to include the UUIDGenFactory, which would remain in place
   (unless
anyone has good ideas on making it more generic?)
   
The reason for this request is that the package is nicely written
(kudos to
the author(s)), and very useful in a number of applications. The
   Jetspeed
developers can use this package; however it does not necessarily
make sense
for Jetspeed to create a dependency on the axis jar, solely to use
 this
package. There are numerous other applications of UUID's that make
it
   an
ideal candidate for the Jakarta-commons, and I feel that
   donating/adopting
this package within the commons fits nicely with the vision of
the commons.
Other uses abound, for example struts could use the classes to
   guarantee a
form is submitted only once. A search of theserverside.com brings
back some
patterns that use guid/uuid.
   
I'd be willing to send the patches to the Axis team if the commons
committers are willing to adopt the package and Axis wishes the
same.
Basically this would 

cvs commit: jakarta-commons/lang RELEASE-NOTES.txt

[bayard]

bayard  2003/08/15 19:31:36

  Modified:lang RELEASE-NOTES.txt
  Log:
  Added latest bugs to the bugfix list.
  
  Revision  ChangesPath
  1.19  +9 -1  jakarta-commons/lang/RELEASE-NOTES.txt
  
  Index: RELEASE-NOTES.txt
  ===
  RCS file: /home/cvs/jakarta-commons/lang/RELEASE-NOTES.txt,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- RELEASE-NOTES.txt 2 Aug 2003 18:28:19 -   1.18
  +++ RELEASE-NOTES.txt 16 Aug 2003 02:31:36 -  1.19
  @@ -167,6 +167,14 @@
   21809  [lang] maven-beta10 checkstyle problem
   21904  NumberUtils.createBigDecimal() NPE in Sun 1.3.1_08
   21952  [lang] Improved tests, javadoc for CharSetUtils, StringEscapeUtils
  +22091  Adding tolerance to double[] search methods in ArrayUtils
  +22094  A small, but important javadoc fix for Fraction proper whole/numerator
  +22095  [lang] Javadoc, tests improvements for CharSet, CharSetUtils
  +22098  [lang] Improve util.Validate tests
  +22245  [lang] test.time fails in Japanese (non-us) locale.
  +22286  [lang] Missing @since tags
  +22367  Typo in documentation
  +22386  [lang] Improve javadoc and overflow behavior of Fraction
   
   
   DEPRECATIONS:
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/native help.c

[remm]

remm2003/08/15 19:33:36

  Modified:daemon/src/native/unix/native help.c
  Log:
  - Add -user to the usage information.
  
  Revision  ChangesPath
  1.6   +4 -1  jakarta-commons-sandbox/daemon/src/native/unix/native/help.c
  
  Index: help.c
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/daemon/src/native/unix/native/help.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- help.c21 Jun 2003 07:10:59 -  1.5
  +++ help.c16 Aug 2003 02:33:36 -  1.6
  @@ -95,6 +95,9 @@
   printf(-check\n);
   printf(only check service (implies -nodetach)\n);

  +printf(-user\n);
  +printf(user used to run the daemon (defaults to current user)\n);
  + 
   printf(-verbose[:class|gc|jni]\n);
   printf(enable verbose output\n);

  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: UUID Reuse proposal

[Tim Anderson]

The Tyrex implementation doesn't attempt to get the
MAC address from the system, but loads it from a configuration
file.
If the address isn't configured, it falls back to using
a random no. for the MAC address.

-Tim

 -Original Message-
 From: Steve Downey [mailto:[EMAIL PROTECTED]
 Sent: Saturday, 16 August 2003 12:26 PM
 To: Jakarta Commons Developers List
 Subject: Re: UUID Reuse proposal


 I've posted a version of a UUID class previously that meets the random
 number version of the leech spec.

 Getting MAC addresses portably is mildly difficult, and requires
 root access
 on most systems. Using a cryptographically good random number
 generator is a
 reasonably good alternative, and if done right, won't collide
 with the UUIDs
 generated using MAC addresses.

 I've used them heavily for synthetic primary keys in database tables.

 If there's interest, I could repost the class.

 -SMD
 - Original Message -
 From: Phil Steitz [EMAIL PROTECTED]
 To: Jakarta Commons Developers List [EMAIL PROTECTED];
 [EMAIL PROTECTED]
 Sent: Friday, August 15, 2003 7:11 PM
 Subject: RE: UUID Reuse proposal


  Having looked now at both implementations (assuming the axis impl is
 what's
  in CVS at
 
 http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis
 /component
 s/uuid/),
  I agree that the tyrex implementation is better for two reasons:
 
  1. It appears to be threadsafe.
 
  2. It allows the node ID to be read from a properties file
 (getting around
  the inaccessability of the MAC address in Java).
 
  The axis implementation uses random bits from a SecureRandom initialized
 in
  a static initialization block for the node ID. I don't see the big value
 in
  a UUID implementation that uses random bits for the node ID.  While you
 can
  get very low probability of collision like this, it is no longer
  guaranteed, so why not just use a purely random string (which
 lang already
  has in RandomStringUtils)?  The only value that remains in the UUID
  algorithm when you remove the U is that it is a standard and you can
  decompose it into the time bits and the node bits.
 
  I do like the idea of lang providing a home for
 IdentifierUtils suitably
  named and packaged.  There are really multiple types here:
 
   * UUID (pseudo) standard, non-random, non-secure
   * Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
   * Random, secure, not guaranteed unique (e.g. Tomcat session IDs)
   * Part random, secure, guaranteed unique (what Tomcat really
 needs ;-)
   * Bounded sequential(e.g. Betwixt's io identifiers)
   * Cyclic
 
  I am still +1 for including a good implementation of the UUID
 pseudo-spec.
  Starting with the tyrex base would probably be easier; but we could
  certainly just add the necessary features to the axis impl.
 
  Phil
 
 
  --- Tim Anderson [EMAIL PROTECTED] wrote:
   Tyrex also provides support for UUID generation, and
   should perform better than the Axis impl.
  
   See
  
 
 http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/mai
 n/tyrex/se
   rvices/UUID.java?rev=1.6
  
   -Tim
  
-Original Message-
From: Tim Reilly [mailto:[EMAIL PROTECTED]
Sent: Friday, 15 August 2003 11:32 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: UUID Reuse proposal
   
   
I'd like to ask the axis developers to donate the java package
org.apache.axis.components.uuid to the Jakarta commons.
   
I'm cross-posting this message on both jakarta commons-dev list
and axis-dev
list as commons could adopt this package and place somewhere
sensible to the
commons. My suggestion would be as an addition to
   org.apache.commons.lang
since the UUID is a special/complex type (aren't all classes, but
hopefully
you know what I'm saying.)
I know not to cross-post but given the request it only
 makes sense. I
realize the package has some basis on the similar package in the BSD
licensed http://sourceforge.net/projects/juddi/ project. It doesn't
   make
sense to include the UUIDGenFactory, which would remain in place
   (unless
anyone has good ideas on making it more generic?)
   
The reason for this request is that the package is nicely written
(kudos to
the author(s)), and very useful in a number of applications. The
   Jetspeed
developers can use this package; however it does not necessarily
make sense
for Jetspeed to create a dependency on the axis jar, solely to use
 this
package. There are numerous other applications of UUID's
 that make it
   an
ideal candidate for the Jakarta-commons, and I feel that
   donating/adopting
this package within the commons fits nicely with the vision of
the commons.
Other uses abound, for example struts could use the classes to
   guarantee a
form is submitted only once. A search of theserverside.com brings
back some
patterns that use guid/uuid.
   
I'd be willing to send the patches to 

cvs commit: jakarta-commons/lang RELEASE-NOTES.txt

[bayard]

bayard  2003/08/15 19:41:18

  Modified:lang RELEASE-NOTES.txt
  Log:
  Updated the jardiff alias at the end.
  
  Revision  ChangesPath
  1.20  +147 -50   jakarta-commons/lang/RELEASE-NOTES.txt
  
  Index: RELEASE-NOTES.txt
  ===
  RCS file: /home/cvs/jakarta-commons/lang/RELEASE-NOTES.txt,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- RELEASE-NOTES.txt 16 Aug 2003 02:31:36 -  1.19
  +++ RELEASE-NOTES.txt 16 Aug 2003 02:41:18 -  1.20
  @@ -235,15 +235,11 @@
org.apache.commons.lang.util.IdentifierFactory
org.apache.commons.lang.util.BitField
org.apache.commons.lang.Entities
  - org.apache.commons.lang.reflect.MethodUtils
  - org.apache.commons.lang.reflect.ReflectionException
  - org.apache.commons.lang.reflect.ConstructorUtils
  - org.apache.commons.lang.reflect.ReflectionUtils
  - org.apache.commons.lang.reflect.FieldUtils
org.apache.commons.lang.Entities$LookupEntityMap
org.apache.commons.lang.NotImplementedException
org.apache.commons.lang.NullArgumentException
org.apache.commons.lang.ObjectUtils$1
  +---
org.apache.commons.lang.StringPrintWriter
org.apache.commons.lang.UnhandledException
org.apache.commons.lang.Entities$HashEntityMap
  @@ -273,51 +269,121 @@
public abstract class org.apache.commons.lang.enum.EnumUtils extends 
java.lang.Object implements java.lang.Comparable, java.io.Serializable {
   ---
public class org.apache.commons.lang.enum.EnumUtils extends java.lang.Object {
  + public org.apache.commons.lang.enum.EnumUtils();
   
  +org.apache.commons.lang.enum.Enum$Entry
  +
  + final java.util.Map unmodifiableMap;
  + final java.util.List unmodifiableList;
   
   org.apache.commons.lang.enum.Enum
   
  + protected transient java.lang.String iToString;
static java.lang.Class class$org$apache$commons$lang$enum$ValuedEnum;
  - protected static java.lang.Class getEnumClass(java.lang.Class);
  + public java.lang.Class getEnumClass();
  +
  +org.apache.commons.lang.enum.ValuedEnum
  +
  + static {};
   
   org.apache.commons.lang.StringUtils
   
  + public static final java.lang.String EMPTY;
  + public static boolean isEmpty(java.lang.String);
  + public static boolean isNotEmpty(java.lang.String);
  + public static boolean isBlank(java.lang.String);
  + public static boolean isNotBlank(java.lang.String);
  + public static java.lang.String deleteSpaces(java.lang.String);
  + public static java.lang.String deleteWhitespace(java.lang.String);
  + public static boolean isNotEmpty(java.lang.String);
  + public static boolean isEmpty(java.lang.String);
  +---
public static java.lang.String trimToNull(java.lang.String);
public static java.lang.String trimToEmpty(java.lang.String);
  - public static boolean isEmptyOrNull(java.lang.String);
  - public static boolean isNotEmptyOrNull(java.lang.String);
  - public static boolean isEmptyTrimmed(java.lang.String);
  - public static boolean isNotEmptyTrimmed(java.lang.String);
  - public static boolean isEmptyTrimmedOrNull(java.lang.String);
  - public static boolean isNotEmptyTrimmedOrNull(java.lang.String);
  + public static java.lang.String strip(java.lang.String);
  + public static java.lang.String stripToNull(java.lang.String);
  + public static java.lang.String stripToEmpty(java.lang.String);
  + public static java.lang.String strip(java.lang.String, java.lang.String);
  + public static java.lang.String stripStart(java.lang.String, java.lang.String);
  + public static java.lang.String stripEnd(java.lang.String, java.lang.String);
  + public static java.lang.String stripAll(java.lang.String[])[];
  + public static java.lang.String stripAll(java.lang.String[], 
java.lang.String)[];
  + public static int indexOf(java.lang.String, char);
  + public static int indexOf(java.lang.String, char, int);
  + public static int indexOf(java.lang.String, java.lang.String);
  + public static int indexOf(java.lang.String, java.lang.String, int);
  + public static int lastIndexOf(java.lang.String, char);
  + public static int lastIndexOf(java.lang.String, char, int);
  + public static int lastIndexOf(java.lang.String, java.lang.String);
  + public static int lastIndexOf(java.lang.String, java.lang.String, int);
  + public static boolean contains(java.lang.String, char);
  + public static boolean contains(java.lang.String, java.lang.String);
  + public static int indexOfAny(java.lang.String, char[]);
  + public static int indexOfAny(java.lang.String, java.lang.String);
  + public static int indexOfAnyBut(java.lang.String, char[]);
  + public static int indexOfAnyBut(java.lang.String, java.lang.String);
  + 

cvs commit: jakarta-commons/lang build.xml

[bayard]

bayard  2003/08/15 19:43:29

  Modified:lang build.xml
  Log:
  Commiting build with the test for reflection removed.
  
  Revision  ChangesPath
  1.18  +1 -2  jakarta-commons/lang/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-commons/lang/build.xml,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- build.xml 30 Jul 2003 01:32:09 -  1.17
  +++ build.xml 16 Aug 2003 02:43:29 -  1.18
  @@ -111,7 +111,6 @@
   test.enum,
   test.exception,
   test.math,
  -test.reflect,
   test.time,
   test.util description=Run all unit test cases
   echo message=Running tests .../
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[lang] Commons Lang 2.0 RC2 cut

[Henri Yandell]

I've cut a release of Commons Lang 2.0 RC2 and placed it in:

http://www.apache.org/~bayard/commons-lang-2.0-rc2/

There's a JDiff in there [Commons-Lang-1.0.1-to-2.0] and Javadoc API
[docs/api], plus the distributable source and binary tar.gz's/zips.

This build was built on Linux with JDK 1.4.0_01, but the distribution
builds fine with JDK-1.2.2_016. I plan to do the real build with the
latter instead of JDK 1.4 for the release.

It's been a long day [nice 13.5 hour shift at work :)] so I've probably
screwed something up. Please have a look and see if there's any stupidity.

Steps at a high level to go:

Confirm RC2 is good  [2 days? Monday evening?]
Call a Commons vote  [3 days. 3 +1's needed, hopefully from other commiters]
Inform the PMC of our desire to release [1 day]
Build release for mirroring [1 day? same day as PMC]
Update website, announce, vacation.

Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: UUID Reuse proposal

[Steve Downey]

That's not good, since your fake MAC address could conflict with someone
else's real MAC address. If you're going to use random numbers for UUIDs,
you need to change the version field, also.

-SMD
- Original Message -
From: Tim Anderson [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, August 15, 2003 10:37 PM
Subject: RE: UUID Reuse proposal


 The Tyrex implementation doesn't attempt to get the
 MAC address from the system, but loads it from a configuration
 file.
 If the address isn't configured, it falls back to using
 a random no. for the MAC address.

 -Tim

  -Original Message-
  From: Steve Downey [mailto:[EMAIL PROTECTED]
  Sent: Saturday, 16 August 2003 12:26 PM
  To: Jakarta Commons Developers List
  Subject: Re: UUID Reuse proposal
 
 
  I've posted a version of a UUID class previously that meets the random
  number version of the leech spec.
 
  Getting MAC addresses portably is mildly difficult, and requires
  root access
  on most systems. Using a cryptographically good random number
  generator is a
  reasonably good alternative, and if done right, won't collide
  with the UUIDs
  generated using MAC addresses.
 
  I've used them heavily for synthetic primary keys in database tables.
 
  If there's interest, I could repost the class.
 
  -SMD
  - Original Message -
  From: Phil Steitz [EMAIL PROTECTED]
  To: Jakarta Commons Developers List [EMAIL PROTECTED];
  [EMAIL PROTECTED]
  Sent: Friday, August 15, 2003 7:11 PM
  Subject: RE: UUID Reuse proposal
 
 
   Having looked now at both implementations (assuming the axis impl is
  what's
   in CVS at
  
  http://cvs.apache.org/viewcvs.cgi/xmlaxis/java/src/org/apache/axis
  /component
  s/uuid/),
   I agree that the tyrex implementation is better for two reasons:
  
   1. It appears to be threadsafe.
  
   2. It allows the node ID to be read from a properties file
  (getting around
   the inaccessability of the MAC address in Java).
  
   The axis implementation uses random bits from a SecureRandom
initialized
  in
   a static initialization block for the node ID. I don't see the big
value
  in
   a UUID implementation that uses random bits for the node ID.  While
you
  can
   get very low probability of collision like this, it is no longer
   guaranteed, so why not just use a purely random string (which
  lang already
   has in RandomStringUtils)?  The only value that remains in the UUID
   algorithm when you remove the U is that it is a standard and you can
   decompose it into the time bits and the node bits.
  
   I do like the idea of lang providing a home for
  IdentifierUtils suitably
   named and packaged.  There are really multiple types here:
  
* UUID (pseudo) standard, non-random, non-secure
* Random, non-secure, not guaranteed unique (e.g. RandomStringUtils)
* Random, secure, not guaranteed unique (e.g. Tomcat session IDs)
* Part random, secure, guaranteed unique (what Tomcat really
  needs ;-)
* Bounded sequential(e.g. Betwixt's io identifiers)
* Cyclic
  
   I am still +1 for including a good implementation of the UUID
  pseudo-spec.
   Starting with the tyrex base would probably be easier; but we could
   certainly just add the necessary features to the axis impl.
  
   Phil
  
  
   --- Tim Anderson [EMAIL PROTECTED] wrote:
Tyrex also provides support for UUID generation, and
should perform better than the Axis impl.
   
See
   
  
  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tyrex/tyrex/src/mai
  n/tyrex/se
rvices/UUID.java?rev=1.6
   
-Tim
   
 -Original Message-
 From: Tim Reilly [mailto:[EMAIL PROTECTED]
 Sent: Friday, 15 August 2003 11:32 AM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: UUID Reuse proposal


 I'd like to ask the axis developers to donate the java package
 org.apache.axis.components.uuid to the Jakarta commons.

 I'm cross-posting this message on both jakarta commons-dev list
 and axis-dev
 list as commons could adopt this package and place somewhere
 sensible to the
 commons. My suggestion would be as an addition to
org.apache.commons.lang
 since the UUID is a special/complex type (aren't all classes, but
 hopefully
 you know what I'm saying.)
 I know not to cross-post but given the request it only
  makes sense. I
 realize the package has some basis on the similar package in the
BSD
 licensed http://sourceforge.net/projects/juddi/ project. It
doesn't
make
 sense to include the UUIDGenFactory, which would remain in place
(unless
 anyone has good ideas on making it more generic?)

 The reason for this request is that the package is nicely written
 (kudos to
 the author(s)), and very useful in a number of applications. The
Jetspeed
 developers can use this package; however it does not necessarily
 make sense
 for Jetspeed to create a dependency 

DO NOT REPLY [Bug 22480] - [lang] Patch for javadocs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22480.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22480

[lang] Patch for javadocs





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 05:29 ---
Created an attachment (id=7847)
Javadoc patch for lang

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22480] - [lang] Patch for javadocs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22480.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22480

[lang] Patch for javadocs





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 05:30 ---
Created an attachment (id=7848)
Fix typos patch

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22424] - NTLM class registers Sun JCE implementation by default

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22424.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22424

NTLM class registers Sun JCE implementation by default





--- Additional Comments From [EMAIL PROTECTED]  2003-08-15 07:00 ---
Created an attachment (id=7829)
Patch take 2. This time with docs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22424] - NTLM class registers Sun JCE implementation by default

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22424.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22424

NTLM class registers Sun JCE implementation by default





--- Additional Comments From [EMAIL PROTECTED]  2003-08-15 07:02 ---
The latest patch includes the removal of the auto-JCE configuration stuff, the
docs for that and the javadoc clean up of the NTLM classes.  If I don't hear any
objections I'll commit it since there hasn't been any substantial change since
the other patches there were okay'd.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Performance HTTPClient vs. ab

[Ortwin Glück]

Wolfgang Hoschek - DSD Staff wrote:
- disabling stale connections with 
connectionMgr.setConnectionStaleCheckingEnabled(false)
improves performance by a factor of 50 (note: factor, not percent).


This is because stale connection checking adds a constant penalty time, 
which for very quick requests may be larger than the actual request 
time. So the stale connection check does not scale. Therefore it was 
made optional.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: HTTPClient PostMethod - postinf form data

[Ortwin Glück]

Anu,

you should use authpost.addParameters(new NameValuePair[] {action, url})

and not setRequestBody.

HTH

Odi

 
  NameValuePair action   = new NameValuePair(url, Books);
  NameValuePair url  = new NameValuePair(field-keywords, java);
  authpost.setRequestBody(new NameValuePair[] {action, url});


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: HTTPClient PostMethod - postinf form data

[Michael Becke]

Odi,

Either should work.  The only difference is one adds and one overwrites.

Mike

On Friday, August 15, 2003, at 03:13 AM, Ortwin Glück wrote:

Anu,

you should use authpost.addParameters(new NameValuePair[] {action, 
url})

and not setRequestBody.

HTH

Odi

   NameValuePair action   = new NameValuePair(url, Books);
  NameValuePair url  = new NameValuePair(field-keywords, 
java);
  authpost.setRequestBody(new NameValuePair[] {action, url});


-
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: HTTPClient PostMethod - postinf form data

[Michael Becke]

Anu,

The problem seems to be the lack of the content type header when 
setting the request body manually.  This value is set when using the 
NameValuePairs since the method knows how the value are encoded.  
Either use setRequestBody(NameValuePair[]) or add the following line 
when setting the body as a string:

PostMethod.setRequestHeader(Content-Type, 
application/x-www-form-urlencoded);

Mike

On Thursday, August 14, 2003, at 10:42 AM, Anu Kulatunga wrote:

Please copy my address ( [EMAIL PROTECTED]) in your response as I am 
not a sunbbscriber to this list yet.

I an trying to invoke a HTTP POST to amazon.com.

The form has 2 parameters, url=Books and field-keywords.

If I use the following the call works fine :

  NameValuePair action   = new NameValuePair(url, Books);
  NameValuePair url  = new NameValuePair(field-keywords, java);
  authpost.setRequestBody(new NameValuePair[] {action, url});
If I use the setRequestBody that takes in a String the website reports 
that no data was found.

In other words the follwoing does not work :
  authpost.setRequestBody(url=Booksfield-keywords=java);
And neither does this  (I looked that the source code for the 
PostMethod).
  authpost.setRequestBody(EncodingUtil.formUrlEncode((new 
NameValuePair[] {action, url}), authpost.getRequestCharSet()));

Please help me understand why I cannot pass a string like 
url=Booksfield-keywords=java to the PostMethod sucessfully.

My class is attached herewith:

import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.cookie.CookiePolicy;
import org.apache.commons.httpclient.cookie.CookieSpec;
import org.apache.commons.httpclient.methods.*;
import org.apache.commons.httpclient.util.EncodingUtil;
import java.io.*;
public class AkshayDemo2
{
static final String LOGON_SITE =  www.amazon.com;
static final intLOGON_PORT = 80;
public AkshayDemo2() {
super();
}
public static void main(String[] args) throws Exception {

HttpClient client = new HttpClient();
client.getHostConfiguration().setHost(LOGON_SITE, LOGON_PORT, 
http);
PostMethod authpost = new 
PostMethod(/exec/obidos/search-handle-form/002-6745494-8676845);

  /*
  // This block works fine
  NameValuePair action   = new NameValuePair(url, Books);
  NameValuePair url  = new NameValuePair(field-keywords, java);
authpost.setRequestBody(new NameValuePair[] {action, url});
  */
  // None of these work 
  //authpost.setRequestBody(url=Booksfield-keywords=java);
  authpost.setRequestBody(EncodingUtil.formUrlEncode((new 
NameValuePair[] {action, url}), authpost.getRequestCharSet()));

  System.out.println(Request 
--+authpost.getRequestBodyAsString()+-- );
  System.out.println(Headers -- BEGIN );
Header[] requestHeaders = authpost.getRequestHeaders();
for (int i=0; irequestHeaders.length; i++){
System.out.print(requestHeaders[i]);
}
  System.out.println(Headers -- END );

client.executeMethod(authpost);
System.out.println(Login form post:  + 
authpost.getStatusLine().toString());
// release any connection resources used by the method
int statuscode = authpost.getStatusCode();
System.out.println(Status code = +statuscode);
if (statuscode==200) showResponse(authpost);
authpost.releaseConnection();
}

 private static void showResponse(HttpMethodBase method){
  System.out.println(Response Body  BEGIN);
  System.out.println(method.getResponseBodyAsString());
  System.out.println(Response Body  END);
 }
private static void displayHTML(String html){}
}


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22073] - Javadocs clean-up

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22073.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22073

Javadocs clean-up





--- Additional Comments From [EMAIL PROTECTED]  2003-08-16 00:44 ---
NTLM javadoc update committed to 2.0 and HEAD.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]