Re: xdocs/ missing?

2004-03-24 Thread robert burrell donkin
On 24 Mar 2004, at 00:10, Noel J. Bergman wrote:

snip

As a general rule, people shouldn't be manipulating /home/cvs 
directly.  As
soon as we migrate to Subversion the problems will go away.
+1

it's important that the ASF has a complete, unadulterated record of how 
each artifact has been created. so, directories and files which are no 
longer used should be removed using cvs (rather than being deleted from 
the server).

AIUI the infrastructure policy is that committers should not be 
directly modifying the structure of our repositories. (this extends 
even to deleting old lock files.) the right way is to ask 
infrastructure to perform the operation. there is now a system of 
rotating administrators so these requests should be serviced much more 
promptly than in the past.

- robert

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


[jelly] jaxme tag library xml version woes

2004-03-24 Thread robert burrell donkin
the required jaxme jars are now in the maven repository. (the mess 
hasn't been cleared up but i think that the repo team are looking to 
establish better procedures for the future rather than fix past 
mistakes.) so i've been taking a look at adding the jaxme tag library 
into jelly-tags and i've run into a bit of a problem.

the tag library builds fine without dependencies but once the 
project.xml extends tag-project.xml, the tests fail. the issue is that 
the DOM libraries which ships with xerces 2.2.1 are incompatible with 
the ones used by jaxme. (if i comment out the parser dependencies in 
the project.xml, it works fine.) what makes solving this one tougher is 
that really the generator needs to use the parser from the base 
classloader (and so must have no xml parser dependencies in the the 
POM).

any ideas?

(i may - for the moment - remove the generation test since this is the 
only one that fails and it isn't a particularly good test in any case.)

- robert

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


Please Help me !! listFiles() return null

2004-03-24 Thread Fabio Cuomo
Sorry i forget somethink of important.
Hi at all
I'm developing an application that support file transfer using ftp  
particularly it is possible to send and receive file more list all 
information files or directory. To do this i use listFiles() method of class 
FTPClass, as follow:

   FTPClient ftp = new FTPClient();
   ftp.connect(host);
   ftp.login(dbuser, pwd);
   FTPFile[] filelist = ftp.listFiles();
   for (int i = 0; i  filelist.length; ++i)
   System.out.println(filelist[i]);
   ftp.disconnect();
... but on FTPFile[] filelist = ftp.listFiles();
i get a null pointer...java.lang.NullPointerException...listFiles() return 
null pointer while if i use
ftp.listNames() i get right result, but it is not most significant because i 
got a array of String that doesn't contain much information.

Please, can somebody tell me if this is a recognized bug or if i wrong in 
something ?? Please help me i'm in trouble..Any kind of help is granted.

Thanx in advance.
regards mulp
_
Personalizza MSN Messenger con sfondi e fotografie! 
http://www.ilovemessenger.msn.it/

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


RE: Enhance performance by generating jar file with -0 option

2004-03-24 Thread Janek Bogucki
On Mon, 2004-03-22 at 18:02, Gary Gregory wrote:
 I cannot say that I am in favor of this change for several reasons.
 
 (1) No performance benchmarks. This sounds like a thought
 optimization.
 
 (2) If the classes do take some amount of time T longer load, so what?
 Context is what matters, for instance, for the example I know best, my
 company's app server, if the server takes 20 seconds or 20+T (=?)
 seconds to start, no one cares. Our customers leave the server running
 for days or have policies whereby servers are rebooted every night.
 Oddly enough though, some folks look at our lib directory and count
 bytes and say things like this is so big and there are so may jars,
 blah blah. So doubling the size of all commons jar files is not going
 to win us any fans. But that's just my case.
 
 Gary

I agree with Gary. Burdening users with uncompressed jars is the wrong
side of 80/20, in fact it's probably the wrong side of 99/1.

For the record I tested the time it takes to load every class in
collections-3.1-dev with and without compression of the the jar. The
test class is attached.

Jar sizes:

 525987 commons-collections-3.1-dev.jar
1097220 commons-collections-3.1-dev-no-compress.jar

Millis to load all classes (5 runs)

compressed  uncompressed

797 669
802 680
796 668
799 675
798 675

There is no case for distributing uncompressed jars when the target
application is server side java.

-Janek

import org.apache.commons.lang.time.StopWatch;

class ClassesLoader {

public static void main(String[] args) throws ClassNotFoundException {

	StopWatch sw = new StopWatch();
	sw.start();
	for(int i = 0 ; i  classes.length ; i++ ) {
	Class clazz = Class.forName( classes [ i ] ) ;
	} 
sw.stop();
	System.out.println(millis:  + sw.getTime());
}

static String [] classes = {
org.apache.commons.collections.bag.AbstractBagDecorator,
org.apache.commons.collections.bag.AbstractMapBag,
org.apache.commons.collections.bag.AbstractSortedBagDecorator,
org.apache.commons.collections.bag.HashBag,
org.apache.commons.collections.bag.PredicatedBag,
org.apache.commons.collections.bag.PredicatedSortedBag,
org.apache.commons.collections.bag.SynchronizedBag,
org.apache.commons.collections.bag.SynchronizedSortedBag,
org.apache.commons.collections.bag.TransformedBag,
org.apache.commons.collections.bag.TransformedSortedBag,
org.apache.commons.collections.bag.TreeBag,
org.apache.commons.collections.bag.TypedBag,
org.apache.commons.collections.bag.TypedSortedBag,
org.apache.commons.collections.bag.UnmodifiableBag,
org.apache.commons.collections.bag.UnmodifiableSortedBag,
org.apache.commons.collections.list.AbstractLinkedList,
org.apache.commons.collections.list.AbstractListDecorator,
org.apache.commons.collections.list.CursorableLinkedList,
org.apache.commons.collections.list.FixedSizeList,
org.apache.commons.collections.list.LazyList,
org.apache.commons.collections.list.NodeCachingLinkedList,
org.apache.commons.collections.list.PredicatedList,
org.apache.commons.collections.list.SetUniqueList,
org.apache.commons.collections.list.SynchronizedList,
org.apache.commons.collections.list.TransformedList,
org.apache.commons.collections.list.TypedList,
org.apache.commons.collections.list.UnmodifiableList,
org.apache.commons.collections.ArrayStack,
org.apache.commons.collections.Bag,
org.apache.commons.collections.BagUtils,
org.apache.commons.collections.BeanMap,
org.apache.commons.collections.BidiMap,
org.apache.commons.collections.BinaryHeap,
org.apache.commons.collections.BoundedCollection,
org.apache.commons.collections.BoundedFifoBuffer,
org.apache.commons.collections.BoundedMap,
org.apache.commons.collections.Buffer,
org.apache.commons.collections.BufferOverflowException,
org.apache.commons.collections.BufferUnderflowException,
org.apache.commons.collections.BufferUtils,
org.apache.commons.collections.Closure,
org.apache.commons.collections.ClosureUtils,
org.apache.commons.collections.CollectionUtils,
org.apache.commons.collections.ComparatorUtils,
org.apache.commons.collections.CursorableLinkedList,
org.apache.commons.collections.DefaultMapBag,
org.apache.commons.collections.DefaultMapEntry,
org.apache.commons.collections.DoubleOrderedMap,
org.apache.commons.collections.EnumerationUtils,
org.apache.commons.collections.ExtendedProperties,
org.apache.commons.collections.Factory,
org.apache.commons.collections.FactoryUtils,
org.apache.commons.collections.FastArrayList,
org.apache.commons.collections.FastHashMap,
org.apache.commons.collections.FastTreeMap,
org.apache.commons.collections.FunctorException,
org.apache.commons.collections.HashBag,
org.apache.commons.collections.IterableMap,
org.apache.commons.collections.IteratorUtils,
org.apache.commons.collections.KeyValue,
org.apache.commons.collections.LRUMap,
org.apache.commons.collections.ListUtils,

DO NOT REPLY [Bug 27899] New: - Javascript validation doesn't work if a form field is called name

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=27899

Javascript validation doesn't work if a form field is called name

   Summary: Javascript validation doesn't work if a form field is
called name
   Product: Commons
   Version: Nightly Builds
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Validator
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The last commit of the javascript code allows multiple forms on the same page 
by generating a unique variable name based on form name, adding this line

oMinLength = eval('new ' + form.name + '_minlength()');

But if any field of the form is called name javascript validation doesn't 
work as form.name is an object, not a String

For example html:text property=name/ makes client side validation stop 
working

Affected files:
Jakarta-commons/validator/src/javascript/org/apache/commons/validator/javasc
ript/*.js

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



[NET] Re: Please Help me !! listFiles() return null

2004-03-24 Thread Mario Ivankovits
Fabio Cuomo wrote:

i get a null pointer...java.lang.NullPointerException...listFiles() 
return null pointer while if i use
It would be great if you could post the stacktrace to see where it is 
thrown.
Is it really listFiles() which throws the excpetion?

On what operating system do the ftp-server run?
I have tried your example and it worked fine with my linux host.
If one of the FTPFile Entries are null and this cause your 
NullPointerException, than this is due to a bug in UnixFtpEntryParser.
Currently files with permissions other than rwx cause the FTPClient to 
return null values.

I already filed a bug about this 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=27858)

As a workaround you could copy UnixFtpEntryParser and change the regexp
+ (((r|-)(w|-)(x|-))((r|-)(w|-)(x|-))((r|-)(w|-)(x|-)))\\s+
to
+ 
(((r|-)(w|-)(x|X|s|S|t|-))((r|-)(w|-)(x|X|s|S|t|-))((r|-)(w|-)(x|X|s|S|t|-)))\\s+

You have to pass this parser to listFiles then.

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


Please Help me !! listFiles() return null

2004-03-24 Thread Fabio Cuomo
i use FTP connection under WinXP, using default windows FTP server..for 
now..after it will work under linux system...i've done some debug on code, 
and when i execute

   FTPFile[] filelist = ftp.listFiles();

i get a null pointer exception..Stack trace inform me only of null pointer 
exception, other lines tell me where error happens, however i attach it :
java.lang.NullPointerException
	at test.ftp.MainClass.check(MainClass.java:241)
	at test.ftp.MainClass.init(MainClass.java:158)
	at test.ftp.MainClass.main(MainClass.java:816)

This is my scenario: i have an application that check into database for a 
value. After this check i establish an FTP connection to localhost FTP after 
the connection and login i get follow reply message :
  Reply is : 230 User mulp logged in.

As already said i use listNames() function, but it is a bit useful , however 
reply code after listNames() is :
  Reply is : 226 Transfer complete
after i get list of names in ftp root.

When i execute FTPFile[] filelist = ftp.listFiles(); i get as reply message 
:

  Reply is : 226 Transfer complete.

it seems all ok but return value is null and then i get a null pointer 
exception while i want to extract information about files.
listFiles() return value is null and not a single entry of FTPFile[].

Please help me i'm in trouble..Any kind of help is granted.

Thanx in advance.
regards mulp
_
Filtri antispamming e antivirus per la tua casella di posta 
http://www.msn.it/msn/hotmail

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


RE: [NET] Re: Please Help me !! listFiles() return null

2004-03-24 Thread Fabio Cuomo
Hi at all
i've tried to run this code
ftp.connect(host);
ftp.login(dbuser, pwd);
FTPFile[] filelist = ftp.listFiles();
for (int i = 0; i  filelist.length; ++i)
System.out.println(filelist[i]);   
 ftp.disconnect();
under a linux system using proftp FTP server and it works well!!! maybe 
windows ftp server give some problem i don't know why but it is...i can use 
the other ftp server, but if some one knows cause of this strange behaviour 
please post it..

Thanks at all for help.
regards,
mulp.
_
MSN Extra Storage elimina i virus dalla tua posta! Provalo! 
http://join.msn.com/?pgmarket=it-itpage=hotmail/es

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


RE: [NET] Re: Please Help me !! listFiles() return null

2004-03-24 Thread Fabio Cuomo
Ok ...i found problem
default Directory display Style property on WinXP Ftp server is set to 
MS-DOS...it's sufficent change this property to UNIX and listFiles() works.

thanks at all.
regards,
mulp
_
Filtri antispamming e antivirus per la tua casella di posta 
http://www.msn.it/msn/hotmail

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


Re: [NET] Re: Please Help me !! listFiles() return null

2004-03-24 Thread Steve Cohen
I've looked at bug 27858 and agree that it is a problem.  I will comment in 
more detail on bugzilla.

However, I don't think this could be responsible for Mr. Cuomo's 
NullPointerException problem.  In the latest code base check out
FtpFileEntryParserImpl.preParse() which weeds out any entries the parser 
failed to parse.  While that is probably not the version used by Mr. Cuomo, 
I'm fairly certain that the release version also removed unparseable entries 
although in a different way.  (In the most recent released version, the 
preParse() method did not exist).

In fact, a later Email from Mr. Cuomo mentions that by changing the NT file 
entry parser to use a unix-style display the problem goes away.  This leads 
me to think he was trying to use the default Unix parser on an NT system when 
he should have been using the NT parser.



On Wednesday 24 March 2004 4:14 am, Mario Ivankovits wrote:
 Fabio Cuomo wrote:
  i get a null pointer...java.lang.NullPointerException...listFiles()
  return null pointer while if i use

 It would be great if you could post the stacktrace to see where it is
 thrown.
 Is it really listFiles() which throws the excpetion?

 On what operating system do the ftp-server run?
 I have tried your example and it worked fine with my linux host.

 If one of the FTPFile Entries are null and this cause your
 NullPointerException, than this is due to a bug in UnixFtpEntryParser.
 Currently files with permissions other than rwx cause the FTPClient to
 return null values.

 I already filed a bug about this
 (http://issues.apache.org/bugzilla/show_bug.cgi?id=27858)

 As a workaround you could copy UnixFtpEntryParser and change the regexp
 + (((r|-)(w|-)(x|-))((r|-)(w|-)(x|-))((r|-)(w|-)(x|-)))\\s+
 to
 +
 (((r|-)(w|-)(x|X|s|S|t|-))((r|-)(w|-)(x|X|s|S|t|-))((r|-)(w|-)(x|X|s|S|t|-
)))\\s+

 You have to pass this parser to listFiles then.

 Ciao,
 Mario


 -
 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]



DO NOT REPLY [Bug 27858] - UnixFTPEntryParser failed if permissions are other than rwx

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=27858

UnixFTPEntryParser failed if permissions are other than rwx





--- Additional Comments From [EMAIL PROTECTED]  2004-03-24 13:00 ---
Good catch, Mr.  Ivankovits! 
 
   for (int access = 0; access  3; access++, g += 4) 
{ 
// Use != '-' to avoid having to check for suid and sticky bits 
file.setPermission(access, FTPFile.READ_PERMISSION, 
   (!group(g).equals(-))); 
file.setPermission(access, FTPFile.WRITE_PERMISSION, 
   (!group(g + 1).equals(-))); 
file.setPermission(access, FTPFile.EXECUTE_PERMISSION, 
   (!group(g + 2).equals(-))); 
} 
 
As you can see by the above code snippet from UnixFTPEntryParser the ignoring of suid 
and 
sticky bits is by design.  However, you are correct that the regex must handle these 
or the 
entry will fail to parse.  While this will not cause a NullPointerException, the 
parsing engine will 
remove the unparsed entry from the listing and that's not good.  Fixing the regex will 
prevent 
this from happening.  And since the current code checks for inequality to - no 
special 
mappings are needed. 
 
So I would say the patch should be the following: 
1) fix the regex as you have indicated 
2) add lines to the JUnit test for this class testing the new functionality.

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



DO NOT REPLY [Bug 27753] - OS400FTPEntryParser

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=27753

OS400FTPEntryParser





--- Additional Comments From [EMAIL PROTECTED]  2004-03-24 13:05 ---
Please remove the irrelevant fix for bug 27756 from your patch.  Your change to 27756 
has 
already been committed separately.  It's always a bad idea to combine bug fixes in a 
single 
patch. 
 
Also, please include in your patch a JUnit test class for your new parser.  It should 
be 
relatively easy to mimic the JUnit tests for another parser.  I am reluctant to commit 
a new 
parser without any tests to back it up.

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



RE: thoughts on subversion (was - Re: xdocs/ missing?)

2004-03-24 Thread Alex Karasulu
 -Original Message-
 From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
 
 Branches and tags are lightweight copies.  Alex Karasulu has been using
 branches for scratch areas, and enjoying it quite a bit.
 

Sorry I'm rushing out the door but the branching is cake.  It was 
much more intuitive copying over the trunk for a branch and then 
merging it back in than dealing with sticky tags in CVS.

On a more general note, I can't deal with CVS any more.  As I've told 
Noel and others its like going back to dial up when you've already 
tasted the speed and freedom of high speed.  That's perhaps the best 
way I can look at it.  

Again sorry about the general and brief response - there are other 
great aspects I wanted to mention as well and others seem to be hitting 
those points.

Hope we decide to make the move soon.  

Alex




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



Re: thoughts on subversion (was - Re: xdocs/ missing?)

2004-03-24 Thread David Graham

--- Simon Kitching [EMAIL PROTECTED] wrote:

snip

 (c) it may be worth waiting until svn client apps are available
 pre-built for most os versions. Page
 http://subversion.tigris.org/project_packages.html has a list of
 packages for various OSes, but the following aren't listed:
  gentoo
  mandrake
  aix
  hpux
  solaris
 I don't know the state of prebuilt client apps for these.
 
 (d) Support for svn in tools like eclipse is also only partial at the
 moment. I don't know if Ant has an svn task. etc.

IMO, this is the main blocker.  The eclipse plugin only works on windows
because they use JNI for some reason and have to compile against specific
svn versions.  Until I can mindlessly select menu items from an IDE to
manipulate the repository I'm against leaving cvs.  I agree there are
benefits to switching but they just don't outweigh the pain of poor tool
integration.  IMHO, waiting for svn and the surrounding tools to mature a
bit more is a good idea.

David

 
 Otherwise I agree it is very smooth, comfortingly similar in feel to
 CVS, and best of all: *maintained* and *secure* (unlike CVS).
 
 
 Cheers,
 
 Simon
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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



RE: [HiveMind] Force loading of Services

2004-03-24 Thread Craig R. McClanahan
Quoting Howard M. Lewis Ship [EMAIL PROTECTED]:

 I'm unconvinced this is necessary. I would tend to think that it is
 counter-productive. With late
 building of services (behind proxies), you will see error messages related to
 the construction of a
 service just where methods are first invoked on it. With the discussion of
 forced loading of
 services, you will see all errors for all services in one ungainly clump.
 

Which is exactly what is being requested, and I agree that it would be helpful
to have this option.  If I've mis-typed a class name or two in my configuration
file, I'd want to be able to find out when my app first loads, instead of
having to wait until the first attempt to materialize an instance of that
particular service.  In a webapp environment, for example, I'd want to do this
in the contextInitialized() method of a ServletContextListener, and never put
the app into service if it has configuration problems.

 Howard M. Lewis Ship

Craig McClanahan


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



Re: Tim Reilly for Committer

2004-03-24 Thread Craig R. McClanahan
Quoting Noel J. Bergman [EMAIL PROTECTED]:

 Tim Reilly has been participating with some regularity since December, as
 shown by:
 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
 pache.orgfrom=81234to=81234count=40by=authorpaged=false.  Tim has
 expressed interest in becoming a Committer, so that he can participate more
 directly, rather than requiring people to do commits for him.
 
  [X] +1
  [ ]  0
  [ ] -1
 

Craig McClanahan


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



[EL] Unit tests?

2004-03-24 Thread John Casey
Does EL have any unit tests defined for it? I'm very interested in using
it for an upcoming project, but I would require unit tests to prove its
functionality first. I'm willing to contribute unit tests if none are in
existence, but I wanted to check here first.

Also: is there any example code for using EL, or some way I can find the
entry point to the API from outside?

TIA,
john


-- 
John Casey
[EMAIL PROTECTED]
CommonJava Open Components Project
http://www.commonjava.org


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



cvs commit: jakarta-commons/codec/src/test/org/apache/commons/codec/binary Base64Test.java

2004-03-24 Thread ggregory
ggregory2004/03/24 10:37:25

  Modified:codec/src/java/org/apache/commons/codec/binary Base64.java
   codec/src/test/org/apache/commons/codec/binary
Base64Test.java
  Log:
  Bugzilla Bug 27781

Base64 chunked encoding not compliant with RFC 2045 section 2.1 CRLF
  
  Revision  ChangesPath
  1.19  +11 -9 
jakarta-commons/codec/src/java/org/apache/commons/codec/binary/Base64.java
  
  Index: Base64.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/Base64.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- Base64.java   18 Mar 2004 17:34:56 -  1.18
  +++ Base64.java   24 Mar 2004 18:37:25 -  1.19
  @@ -36,20 +36,21 @@
   public class Base64 implements BinaryEncoder, BinaryDecoder {
   
   /**
  - * Chunk size according to RFC 2045.
  + * Chunk size per RFC 2045 section 6.8.
* 
* pThe [EMAIL PROTECTED] character limit does not count the trailing CRLF, 
but counts 
* all other characters, including any equal signs./p
* 
  - * @see a href=http://www.ietf.org/rfc/rfc2045.txt;RFC 2045 section 2.1/a
  + * @see a href=http://www.ietf.org/rfc/rfc2045.txt;RFC 2045 section 6.8/a
*/
   static final int CHUNK_SIZE = 76;
   
   /**
  - * Chunk separator, we use a newline to separate chunks
  - * of encoded data (if you ask for it to be chunked).
  + * Chunk separator per RFC 2045 section 2.1.
  + * 
  + * @see a href=http://www.ietf.org/rfc/rfc2045.txt;RFC 2045 section 2.1/a
*/
  -static final byte[] CHUNK_SEPARATOR = \n.getBytes();
  +static final byte[] CHUNK_SEPARATOR = \r\n.getBytes();
   
   /**
* The base length.
  @@ -167,8 +168,8 @@
   }
   
   /**
  - * Encodes binary data using the base64 algorithm (this
  - * does not chunk the output).
  + * Encodes binary data using the base64 algorithm but
  + * does not chunk the output.
*
* @param binaryData binary data to encode
* @return Base64 characters
  @@ -227,7 +228,8 @@
   }
   
   /**
  - * Encodes hex octects into Base64.
  + * Encodes binary data using the base64 algorithm, optionally
  + * chunking the output into 76 character blocks.
*
* @param binaryData Array containing binary data to encode.
* @param isChunked if isChunked is true this encoder will chunk
  
  
  
  1.14  +197 -3
jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java
  
  Index: Base64Test.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- Base64Test.java   17 Mar 2004 19:28:37 -  1.13
  +++ Base64Test.java   24 Mar 2004 18:37:25 -  1.14
  @@ -68,6 +68,11 @@
   assertEquals(, new String(Base64.decodeBase64(.getBytes(;
   }
   
  +public void testDecodePadOnlyChunked() {
  +assertTrue(Base64.decodeBase64(\n.getBytes()).length == 0);
  +assertEquals(, new String(Base64.decodeBase64(\n.getBytes(;
  +}
  +
   // encode/decode random arrays from size 0 to size 11
   public void testEncodeDecodeSmall() {
   for(int i=0;i12;i++) {
  @@ -92,6 +97,20 @@
   }
   }
   
  +/**
  + * Tests RFC 2045 section 2.1 CRLF definition.
  + */
  +public void testRfc2045Section2Dot1CrLfDefinition() {
  +assertTrue(Arrays.equals(new byte[] {13, 10}, Base64.CHUNK_SEPARATOR));
  +}
  +
  +/**
  + * Tests RFC 2045 section 6.8 chuck size definition.
  + */
  +public void testRfc2045Section6Dot8ChunkSizeDefinition() {
  +assertEquals(76, Base64.CHUNK_SIZE);
  +}
  +
   public void testSingletons() {
   assertEquals(AA==,new String(Base64.encodeBase64(new byte[] { (byte)0 
})));
   assertEquals(AQ==,new String(Base64.encodeBase64(new byte[] { (byte)1 
})));
  @@ -200,6 +219,114 @@
   assertEquals(aA==,new String(Base64.encodeBase64(new byte[] { (byte)104 
})));
   }
   
  +public void testSingletonsChunked() {
  +assertEquals(AA==\r\n,new String(Base64.encodeBase64Chunked(new byte[] { 
(byte)0 })));
  +assertEquals(AQ==\r\n,new String(Base64.encodeBase64Chunked(new byte[] { 
(byte)1 })));
  +assertEquals(Ag==\r\n,new String(Base64.encodeBase64Chunked(new byte[] { 
(byte)2 })));
  +assertEquals(Aw==\r\n,new String(Base64.encodeBase64Chunked(new byte[] { 
(byte)3 })));
  +assertEquals(BA==\r\n,new String(Base64.encodeBase64Chunked(new byte[] { 
(byte)4 })));
  +assertEquals(BQ==\r\n,new 

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

2004-03-24 Thread ggregory
ggregory2004/03/24 10:39:25

  Modified:codecRELEASE-NOTES.txt
  Log:
  Bugzilla Bug 27781

Base64 chunked encoding not compliant with RFC 2045 section 2.1 CRLF
  
  Revision  ChangesPath
  1.19  +9 -4  jakarta-commons/codec/RELEASE-NOTES.txt
  
  Index: RELEASE-NOTES.txt
  ===
  RCS file: /home/cvs/jakarta-commons/codec/RELEASE-NOTES.txt,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- RELEASE-NOTES.txt 23 Mar 2004 19:26:50 -  1.18
  +++ RELEASE-NOTES.txt 24 Mar 2004 18:39:25 -  1.19
  @@ -28,9 +28,14 @@
   
   BUG FIXES:
   
  -* Fix for Bug 25995: [Codec] Default URL encoding logic broken.
  -http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25995
  +* Fixed Bug 25995
  + Default URL encoding logic broken.
  + http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25995
   
  +* Fixed Bug 27781
  + Base64 chunked encoding not compliant with RFC 2045 section 2.1 CRLF
  + http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27781
  + 
   * Added missing tags in Javadoc comments.  
   
   * General Javadoc improvements.
  
  
  

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



DO NOT REPLY [Bug 27781] - Base64 chunked encoding not compliant with RFC 2045 section 2.1 CRLF

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=27781

Base64 chunked encoding not compliant with RFC 2045 section 2.1 CRLF

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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



Re: [jelly] jaxme tag library xml version woes

2004-03-24 Thread robert burrell donkin
On 24 Mar 2004, at 15:50, Paul Libbrecht wrote:

On 24-Mar-04, at 09:57 Uhr, robert burrell donkin wrote:
the tag library builds fine without dependencies but once the 
project.xml extends tag-project.xml, the tests fail. the issue is 
that the DOM libraries which ships with xerces 2.2.1 are incompatible 
with the ones used by jaxme. (if i comment out the parser 
dependencies in the project.xml, it works fine.) what makes solving 
this one tougher is that really the generator needs to use the parser 
from the base classloader (and so must have no xml parser 
dependencies in the the POM).

any ideas?
So upgrading the Xerces dependency wouldn't solve anything, correct ?
not sure but i'll give it a try. it's hard to know which jars come with 
which xerces implementation...

Kind of dark.
You should test it but I don't think there's any reliance on that 
particular Xerces version (there shouldn't really).
(i'm not sure but) i seem to remember some issue about problems with 
backwards compatibility between different versions of w3c DOM. i think 
that the issue is that different versions of xerces ship with 
incompatible DOM implementations.

Would the other way be to run the test in a forked VM ?
i'll look into this but i suspect the that maven will provide the 
incompatible inherited xerces dependency in the forked VM (which will 
cause the test to fail).

- robert

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


Re: Tim Reilly for Committer

2004-03-24 Thread Phil Steitz

--- Noel J. Bergman [EMAIL PROTECTED] wrote:
 Tim Reilly has been participating with some regularity since December, as
 shown by:

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
 pache.orgfrom=81234to=81234count=40by=authorpaged=false.  Tim has
 expressed interest in becoming a Committer, so that he can participate
 more
 directly, rather than requiring people to do commits for him.
 
  [X] +1
  [ ]  0
  [ ] -1
 
 

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


__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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



Re: [VFS] test server (Success)

2004-03-24 Thread Mario Ivankovits
Hello!

Now nearly all tests runs successfully. Only the Sftp wont work due to 
an ArrayOutOfBounceException

java.lang.ArrayIndexOutOfBoundsException: 1575945941
   at com.jcraft.jsch.jce.SignatureDSA.verify(SignatureDSA.java:115)
   at com.jcraft.jsch.jce.DHG1.next(DHG1.java:244)
   at com.jcraft.jsch.Session.connect(Session.java:253)
   at 
org.apache.commons.vfs.provider.sftp.SftpFileSystem.getChannel(SftpFileSystem.java:83)

I already posted a request to the jsch mailing-list, but maybe one of 
you have an idea?

During testing i found a bug in UnixFTPEntryParser [NET] and fixed the 
SmbProvider to handle directories correctly.
Smb test with jcifs-0.8.2.jar failed due to missing trailing / on 
directories.

However, i am pretty close to have a stable UML and would like to know 
what to do next?
If it is possible to install this on an GUMP Server as Noel J. Bergman 
wrote, what person should i contact to discuss this?

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


[codec][lang] Can't build with Maven 1.0-rc2

2004-03-24 Thread Gary Gregory
Hello,

I've installed Maven 1.0-rc2 (I had Maven 1.0-rc1) and I am getting
errors in lang and codec. This all used to work in rc1 of course.

First I tried to run site:generate over and over until maven downloaded
all the jar files it thought it needed but things blew up in a
plugin.jelly file I think. 

I then nuked everything in my user .maven/plugins and .maven/repository.
Then I ran clean site:generate which downloaded a ton of jars but I got
the same errors in maven-checkstyle-plugin-2.3.

Any clues?

For lang:

maven clean site:generate
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0-rc2

Attempting to download vdoclet-20020711.jar.

.
Attempting to download qdox-current.jar.
..
.
Attempting to download logkit-1.0.1.jar.

.
build:start:

clean:clean:

clean:

site:
xdoc:register-reports:
maven-checkstyle-plugin:register:

maven-javadoc-plugin:register:

maven-junit-report-plugin:register:

maven-jxr-plugin:register:

maven-license-plugin:register:

maven-tasklist-plugin:register:


site:run-reports:
[echo] Generating the Checkstyle...
checkstyle:init:

checkstyle:report:
checkstyle:run:
[mkdir] Created dir:
C:\cvs-store\apache.org\jakarta\commons\lang\target
[echo] Using checkstyle.xml for checkstyle ...

BUILD FAILED
File.. file:/C:/Documents and
Settings/ggregory/.maven/plugins/maven-checkstyle-plugin-2.3/plugin.jell
y
Element... ant:checkstyle
Line.. 133
Column 63
Unable to create a Checker: Cannot set property 'basedir' in module
Checker to '.': . is not an absolute path
Total time: 10 seconds
Finished at: Wed Mar 24 11:28:22 PST 2004


For codec:

maven clean site:generate
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0-rc2

build:start:

clean:clean:
[delete] Deleting directory
C:\cvs-store\apache.org\jakarta\commons\codec\target
[delete] Deleting:
C:\cvs-store\apache.org\jakarta\commons\codec\velocity.log

clean:

site:
xdoc:register-reports:
maven-changelog-plugin:register:

maven-checkstyle-plugin:register:

maven-clover-plugin:register:

maven-developer-activity-plugin:register:

maven-file-activity-plugin:register:

maven-javadoc-plugin:register:

maven-junit-report-plugin:register:

maven-jxr-plugin:register:

maven-license-plugin:register:


site:run-reports:
[echo] Generating the Change Log...
maven-changelog-plugin:report:
[echo] Generating the changelog report
ChangeLog found: 9 entries
[mkdir] Created dir:
C:\cvs-store\apache.org\jakarta\commons\codec\target\generated-xdocs

[echo] Generating the Checkstyle...
checkstyle:init:

checkstyle:report:
checkstyle:run:
[echo] Using
C:\cvs-store\apache.org\jakarta\commons\codec/checkstyle.xml for
checkstyle ...

BUILD FAILED
File.. file:/C:/Documents and
Settings/ggregory/.maven/plugins/maven-checkstyle-plugin-2.3/plugin.jell
y
Element... ant:checkstyle
Line.. 133
Column 63
Unable to create a Checker: Cannot set property 'basedir' in module
Checker to 'src/checkstyle': src\checkstyle is not an absolute path
Total time: 1 minutes 18 seconds
Finished at: Wed Mar 24 12:39:41 PST 2004

Gary


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



cvs commit: jakarta-commons/codec project.properties

2004-03-24 Thread ggregory
ggregory2004/03/24 12:48:48

  Modified:codecproject.properties
  Log:
  # The Sun Javadoc for versions prior to 1.3 are off-line.
  
  Revision  ChangesPath
  1.14  +2 -1  jakarta-commons/codec/project.properties
  
  Index: project.properties
  ===
  RCS file: /home/cvs/jakarta-commons/codec/project.properties,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- project.properties23 Feb 2004 07:32:49 -  1.13
  +++ project.properties24 Mar 2004 20:48:47 -  1.14
  @@ -31,6 +31,7 @@
   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
   maven.xdoc.poweredby.image=maven-feather.png
   
  +# The Sun Javadoc for versions prior to 1.3 are off-line.
   maven.javadoc.links=http://java.sun.com/j2se/1.3/docs/api/
   maven.javadoc.overview=${basedir}/src/java/org/apache/commons/codec/overview.html
   maven.javadoc.package=true
  
  
  

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



cvs commit: jakarta-commons/lang project.properties

2004-03-24 Thread ggregory
ggregory2004/03/24 12:49:12

  Modified:lang project.properties
  Log:
  # The Sun Javadoc for versions prior to 1.3 are off-line.
  
  Revision  ChangesPath
  1.11  +2 -2  jakarta-commons/lang/project.properties
  
  Index: project.properties
  ===
  RCS file: /home/cvs/jakarta-commons/lang/project.properties,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- project.properties18 Feb 2004 23:13:37 -  1.10
  +++ project.properties24 Mar 2004 20:49:12 -  1.11
  @@ -25,5 +25,5 @@
   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
   maven.xdoc.poweredby.image=maven-feather.png
   
  -# Point Javadoc to the Sun 1.3 API doc since 1.2 is no longer on-line.
  +# The Sun Javadoc for versions prior to 1.3 are off-line.
   maven.javadoc.links=http://java.sun.com/j2se/1.3/docs/api/
  
  
  

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



Re: [HiveMind] Force loading of Services

2004-03-24 Thread John Rubier
On Wednesday March 24th 2004, Craigmcc wrote:

 Quoting Howard M. Lewis Ship [EMAIL PROTECTED]:
  I'm unconvinced this is necessary. I would tend to think that it is
  counter-productive. With late
  building of services (behind proxies), you will see error messages related to
  the construction of a
  service just where methods are first invoked on it. With the discussion of
  forced loading of
  services, you will see all errors for all services in one ungainly clump.
 
 Which is exactly what is being requested, and I agree that it would be helpful
 to have this option.  If I've mis-typed a class name or two in my configuration
 file, I'd want to be able to find out when my app first loads, instead of
 having to wait until the first attempt to materialize an instance of that
 particular service.  In a webapp environment, for example, I'd want to do this
 in the contextInitialized() method of a ServletContextListener, and never put
 the app into service if it has configuration problems.
  Howard M. Lewis Ship
 Craig McClanahan
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Perhaps for testing purposes a property like the tapestry disable-caching property 
could be available (i.e. org.apache.hivemind.disable-proxies).
Otherwise I'd be inclines to agree with Howard in the even if your service managed to 
initialize, it may fail unexpectedly when you go to use it anyway. Since you have to 
handle that situation as well,  you would actually end up having less code. i.e. in 
the contextInitialize, you don't have to handle any service failures since you're 
getting proxies and you will be handing them when you actually use them in the app.

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



Re: [collections] ReferenceMap changed for WeakIdentityMap but now broken

2004-03-24 Thread Janek Bogucki
On Tue, 2004-03-23 at 23:01, Stephen Colebourne wrote:
  I can't spot the problem, so I'm posting it in case someone else wants to
 take a look and tell me my stupid mistake ;-)
 
 Stephen

The error message from the batch test was unhelpful. This is what I get
with this task added before the batch test

  junit haltonerror=true haltonfailure=true printsummary=no 
  classpath
pathelement location=${build.classes}/
pathelement location=${build.tests}/
pathelement location=${junit.jar}/
  /classpath
formatter type=plain usefile=false/
test name=org.apache.commons.collections.map.TestReferenceMap/
  /junit
 
At the end there is this which you did not mention in your original post
so it might be new information

[junit] Testcase: testPurgeValues took 4.903 sec
[junit] Caused an ERROR
[junit] null
[junit] java.lang.OutOfMemoryError
[junit] no stack trace available

[junit] Testcase: testPurgeValues

Full dump
-
test:
[junit] Testsuite:
org.apache.commons.collections.map.TestReferenceMap
[junit] Tests run: 115, Failures: 0, Errors: 1, Time elapsed: 5.373
sec

[junit] Testcase: testObjectEqualsSelf took 0.027 sec
[junit] Testcase: testEqualsNull took 0.001 sec
[junit] Testcase: testObjectHashCodeEqualsSelfHashCode took 0.003
sec
[junit] Testcase: testObjectHashCodeEqualsContract took 0.02 sec
[junit] Testcase: testSerializeDeserializeThenCompare took 0 sec
[junit] Testcase: testSimpleSerialization took 0 sec
[junit] Testcase: testCanonicalEmptyCollectionExists took 0.001 sec
[junit] Testcase: testCanonicalFullCollectionExists took 0 sec
[junit] Testcase: testSampleMappings took 0.001 sec
[junit] Testcase: testMakeMap took 0.004 sec
[junit] Testcase: testMapIsEmpty took 0.014 sec
[junit] Testcase: testMapSize took 0.006 sec
[junit] Testcase: testMapClear took 0.001 sec
[junit] Testcase: testMapContainsKey took 0.01 sec
[junit] Testcase: testMapContainsValue took 0.006 sec
[junit] Testcase: testMapEquals took 0.009 sec
[junit] Testcase: testMapGet took 0 sec
[junit] Testcase: testMapHashCode took 0.003 sec
[junit] Testcase: testMapToString took 0.002 sec
[junit] Testcase: testEmptyMapCompatibility took 0.001 sec
[junit] Testcase: testFullMapCompatibility took 0 sec
[junit] Testcase: testMapPut took 0.05 sec
[junit] Testcase: testMapPutAll took 0.004 sec
[junit] Testcase: testMapRemove took 0.021 sec
[junit] Testcase: testValuesClearChangesMap took 0 sec
[junit] Testcase: testKeySetClearChangesMap took 0.002 sec
[junit] Testcase: testEntrySetClearChangesMap took 0.001 sec
[junit] Testcase: testValuesRemoveChangesMap took 0.001 sec
[junit] Testcase: testKeySetRemoveChangesMap took 0 sec
[junit] Testcase: testObjectEqualsSelf took 0.001 sec
[junit] Testcase: testEqualsNull took 0 sec
[junit] Testcase: testObjectHashCodeEqualsSelfHashCode took 0 sec
[junit] Testcase: testObjectHashCodeEqualsContract took 0 sec
[junit] Testcase: testSerializeDeserializeThenCompare took 0 sec
[junit] Testcase: testSimpleSerialization took 0 sec
[junit] Testcase: testCanonicalEmptyCollectionExists took 0 sec
[junit] Testcase: testCanonicalFullCollectionExists took 0.001 sec
[junit] Testcase: testCollectionAdd took 0 sec
[junit] Testcase: testCollectionAddAll took 0 sec
[junit] Testcase: testUnsupportedAdd took 0.009 sec
[junit] Testcase: testCollectionClear took 0.001 sec
[junit] Testcase: testCollectionContains took 0.002 sec
[junit] Testcase: testCollectionContainsAll took 0.009 sec
[junit] Testcase: testCollectionIsEmpty took 0.003 sec
[junit] Testcase: testCollectionIterator took 0.006 sec
[junit] Testcase: testCollectionIteratorRemove took 0.019 sec
[junit] Testcase: testCollectionRemove took 0.061 sec
[junit] Testcase: testCollectionRemoveAll took 0.007 sec
[junit] Testcase: testCollectionRetainAll took 0.006 sec
[junit] Testcase: testCollectionSize took 0.002 sec
[junit] Testcase: testCollectionToArray took 0.006 sec
[junit] Testcase: testCollectionToArray2 took 0.006 sec
[junit] Testcase: testCollectionToString took 0 sec
[junit] Testcase: testUnsupportedRemove took 0 sec
[junit] Testcase: testCollectionIteratorFailFast took 0 sec
[junit] Testcase: testSetEquals took 0.004 sec
[junit] Testcase: testSetHashCode took 0 sec
[junit] Testcase: testMapEntrySetIteratorEntry took 0.001 sec
[junit] Testcase: testMapEntrySetIteratorEntrySetValue took 0.003
sec
[junit] Testcase: testMapEntrySetRemoveNonMapEntry took 0.001 sec
[junit] Testcase: testObjectEqualsSelf took 0 sec
[junit] Testcase: testEqualsNull took 0 sec
[junit] Testcase: testObjectHashCodeEqualsSelfHashCode took 0 sec
[junit] Testcase: testObjectHashCodeEqualsContract took 0.001 sec
[junit] Testcase: 

Re: [collections] ReferenceMap changed for WeakIdentityMap but now broken

2004-03-24 Thread Janek Bogucki
On Wed, 2004-03-24 at 21:57, Janek Bogucki wrote:
 At the end there is this which you did not mention in your original post
 so it might be new information
 
 [junit] Testcase: testPurgeValues took 4.903 sec
 [junit] Caused an ERROR
 [junit] null
 [junit] java.lang.OutOfMemoryError
 [junit] no stack trace available
 
 [junit] Testcase: testPurgeValues
 

I now realize that this is actually how the test is intended to work.
Sorry for the noise.

-Janek

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



[PATCH] CLI NumberValidatorTest

2004-03-24 Thread Simon Raess
hi

I've downloaded the latest sources from commons-cli from the branch 
RESEARCH_CLI_2_ROXSPRING and tried to run the tests with maven. The 
following tests failed:

org.apache.commons.cli2.NumberValidatorTest
 - testValidate_Number
 - testValidate_Percent
The attached patch fixes the 'bugs' in the tests. The problem was 
caused by some 'locale-specific' behavior.

org.apache.commons.cli2.jdepend.JDependTest
 - testAcceptableDistance
The distance for package org.apache.commons.cli2.commandline was 0.25 
(according to the test, it must be  0.2).

Hope this helps
Simon

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

RE: [HiveMind] Force loading of Services

2004-03-24 Thread Howard M. Lewis Ship

 particular service.  In a webapp environment, for example, 
 I'd want to do this
 in the contextInitialized() method of a 
 ServletContextListener, and never put
 the app into service if it has configuration problems.
 

My approach has been to allow services to initialize as-needed, to copiously output 
errors during
initialization, but then let the services stumble along afterwards in the wake of any 
initialization
errors. So you might see a BuilderFactory error about invalid values or attributes, 
then later see a
NPE because a service implementation instance variable is not initialized (due to the 
invalid
value).

The underlying belief behind your statement is that you can't determine if your 
hivemodule.xml is
valid until deployment time, therefore you want to do a lot of checking at deployment 
time.

The intent with HiveMind is that you should be able to do much of the testing inside a 
unit test
suite, rather than only at deployment time. What I would rather see is a set of best 
practices and
the evolution of the framework to ensure that this is the case.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components 
http://howardlewisship.com


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



cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt XMLUtils.java

2004-03-24 Thread rdonkin
rdonkin 2004/03/24 14:46:15

  Modified:betwixt/src/test/org/apache/commons/betwixt
TestXMLUtils.java
   betwixt/src/java/org/apache/commons/betwixt XMLUtils.java
  Log:
  Added new methods which escape CDATA sections to XMLUtils
  
  Revision  ChangesPath
  1.6   +24 -1 
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestXMLUtils.java
  
  Index: TestXMLUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestXMLUtils.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- TestXMLUtils.java 28 Feb 2004 13:38:34 -  1.5
  +++ TestXMLUtils.java 24 Mar 2004 22:46:15 -  1.6
  @@ -88,5 +88,28 @@
   XMLUtils.escapeAttributeValue(ab''c\ef'g));
   
   }
  +
  +/** 
  + * Test CDATA escaping 
  + * Within a CDATA section, only the CDEnd
  + * string ']]' is recognized as markup.
  + * Angle brackets and amphersands may occur in their literal form.
  + */
  +public void testCDATAEscaping() {
  +assertEquals(Escaping: , , XMLUtils.escapeCDATAContent());
  +assertEquals(Escaping: , , XMLUtils.escapeCDATAContent());
  +assertEquals(Escaping: ', ', XMLUtils.escapeCDATAContent('));
  +assertEquals(Escaping: \, \, XMLUtils.escapeCDATAContent(\));
  +assertEquals(Escaping: , , XMLUtils.escapeCDATAContent());
  +assertEquals(Escaping: ]], ]], XMLUtils.escapeCDATAContent(]]));
  +assertEquals(Escaping: ], ], XMLUtils.escapeCDATAContent(]));
  +assertEquals(Escaping: ]], ]]gt;, XMLUtils.escapeCDATAContent(]]));
  +assertEquals(Escaping: , ]]gt;]]gt;, 
XMLUtils.escapeCDATAContent());
  +assertEquals(Escaping: ]]], ]]]gt;, 
XMLUtils.escapeCDATAContent(]]]));
  +assertEquals(Escaping: ], ]]gt;]]]gt;, 
XMLUtils.escapeCDATAContent(]));
  +assertEquals(Escaping: , , XMLUtils.escapeCDATAContent()); 
  +}
  +
  +
   }
   
  
  
  
  1.9   +44 -1 
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/XMLUtils.java
  
  Index: XMLUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/XMLUtils.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- XMLUtils.java 28 Feb 2004 13:38:32 -  1.8
  +++ XMLUtils.java 24 Mar 2004 22:46:15 -  1.9
  @@ -329,6 +329,49 @@
   return buffer.toString();
   }
   
  +
  +/**
  + * Escapes the given content suitable for insertion within a
  + * codeCDATA/code sequence.
  + * Within a codeCDATA/code section, only the codeCDEnd/code
  + * string ']]' is recognized as markup.
  + * @param content the body content whose character data should 
  + * be escaped in a way appropriate for use within a codeCDATA/code
  + * section of xml.
  + * @return escaped character data, not null
  + */
  +public static final String escapeCDATAContent(String content) {
  +StringBuffer buffer = new StringBuffer(content);
  +escapeCDATAContent(buffer);
  +return buffer.toString();
  +}
  + 
  +/**
  + * Escapes the given content suitable for insertion within a
  + * codeCDATA/code sequence.
  + * Within a codeCDATA/code section, only the codeCDEnd/code
  + * string ']]' is recognized as markup.
  + * @param bufferedContent the body content within a buffer 
  + * whose character data should 
  + * be escaped in a way appropriate for use within a codeCDATA/code
  + * section of xml.
  + * @return escaped character data, not null
  + */
  +public static final void escapeCDATAContent(StringBuffer bufferedContent) {
  +for (int i=2, size = bufferedContent.length(); isize; i++) {
  +char at = bufferedContent.charAt(i);
  +if ( at == '' 
  + bufferedContent.charAt(i-1) == ']' 
  + bufferedContent.charAt(i-2) == ']') {
  +
  +bufferedContent.replace(i, i+1, GREATER_THAN_ENTITY);
  +size += 3;
  +i+=3;
  +}
  +}
  +}
  + 
  +
   /**
* pIs this string a well formed xml name?/p
*
  
  
  

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



cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io AbstractBeanWriter.java

2004-03-24 Thread rdonkin
rdonkin 2004/03/24 14:49:22

  Modified:betwixt/src/java/org/apache/commons/betwixt/io
AbstractBeanWriter.java
  Log:
  Added a way for the subclass writers to discover what the current element is. I'm 
not very happy with this design, I think that probably it would be better to alter the 
SAX inspirected API so that a context is passed through but more time is needed to 
consider this change and I'd like to add support for CDATA encoding today (since there 
are users waiting).
  
  Revision  ChangesPath
  1.24  +4 -2  
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java
  
  Index: AbstractBeanWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/AbstractBeanWriter.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- AbstractBeanWriter.java   28 Feb 2004 13:38:33 -  1.23
  +++ AbstractBeanWriter.java   24 Mar 2004 22:49:22 -  1.24
  @@ -70,6 +70,8 @@
   private boolean writeEmptyElements = true;
   /** Dynamic binding configuration settings */
   private BindingConfiguration bindingConfiguration = new BindingConfiguration();
  +// TODO: consider whether this should be replaced by a passed through context 
  +protected ElementDescriptor currentDescriptor;
   
   /**
* Marks the start of the bean writing.
  @@ -664,7 +666,7 @@
   IOException, 
   SAXException,
   IntrospectionException { 
  -
  +currentDescriptor = elementDescriptor;   
   Descriptor[] childDescriptors = elementDescriptor.getContentDescriptors();
   if ( childDescriptors != null  childDescriptors.length  0 ) {
   // process child elements
  
  
  

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



cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy MixedContentEncodingStrategy.java

2004-03-24 Thread rdonkin
rdonkin 2004/03/24 14:51:21

  Added:   betwixt/src/java/org/apache/commons/betwixt/strategy
MixedContentEncodingStrategy.java
  Log:
  Strategy interface for mixed content encoding.
  
  Revision  ChangesPath
  1.1  
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy/MixedContentEncodingStrategy.java
  
  Index: MixedContentEncodingStrategy.java
  ===
  /*
   * Copyright 2004 The Apache Software Foundation.
   * 
   * Licensed under the Apache License, Version 2.0 (the License);
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   * 
   *  http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an AS IS BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */
  
  package org.apache.commons.betwixt.strategy;
  
  import org.apache.commons.betwixt.ElementDescriptor;
  
  /**
   * pEncodes body content.
   * /pp
   * strongUsage:/strong 
   * Used by [EMAIL PROTECTED] BeanWriter} to encode body content before it is written
   * into the textual output.
   * This gives flexibility in this stage allowing (for example)
   * some properties to use character escaping whilst others 
   * use codeCDATA/code wrapping.
   * /p
   * pstrongNote:/strong the word codeencoding/code here is used 
   * in the sense of escaping a sequence of character data.
   * /p
   * @author a href='http://jakarta.apache.org/'Jakarta Commons Team/a
   * @version $Revision: 1.1 $
   */
  public abstract class MixedContentEncodingStrategy {
  
  /**
   * The default implementation used by Betwixt.
   * This always encodes by escaping character data.
   * This is a singleton.
   */
  public static final MixedContentEncodingStrategy DEFAULT 
  = new BaseMixedContentEncodingStrategy() {
  /**
   * Always encode by escaping character data.
   */
  protected boolean encodeAsCDATA(ElementDescriptor element) {
  return false;   
  }
  };
  
  /**
   * Encodes the body content into a form suitable for output as 
   * (textual) xml.
   * @param bodyContent the raw (unescaped) character data, not null
   * @param element the codeElementDescriptor/code describing the element
   * whose content is being encoded.
   * @return the encoded (escaped) character data, not null
   */
  public abstract String encode(String bodyContent, ElementDescriptor element);
  }
  
  
  

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



DO NOT REPLY [Bug 24306] - Fileupload fails for forms with a large number of inputs

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=24306

Fileupload fails for forms with a large number of inputs





--- Additional Comments From [EMAIL PROTECTED]  2004-03-24 22:52 ---
Perhaps, if it was just that one class. However, two classes from FileUpload 
have moved (well, there are copies for now) to IO, and another class has been 
added to IO that needs to be picked up and used in FileUpload, so there are 4 
classes in IO that FileUpload wants. I think at that point that a dependency is 
warranted.

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



cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy BaseMixedContentEncodingStrategy.java

2004-03-24 Thread rdonkin
rdonkin 2004/03/24 14:52:14

  Added:   betwixt/src/java/org/apache/commons/betwixt/strategy
BaseMixedContentEncodingStrategy.java
  Log:
  Basic implementation for mxied content encoding strategy.
  
  Revision  ChangesPath
  1.1  
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/strategy/BaseMixedContentEncodingStrategy.java
  
  Index: BaseMixedContentEncodingStrategy.java
  ===
  /*
   * Copyright 2004 The Apache Software Foundation.
   * 
   * Licensed under the Apache License, Version 2.0 (the License);
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   * 
   *  http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an AS IS BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */
  
  package org.apache.commons.betwixt.strategy;
  
  import org.apache.commons.betwixt.ElementDescriptor;
  import org.apache.commons.betwixt.XMLUtils;
  
  /**
   * pBasic implementation for [EMAIL PROTECTED] MixedContentEncodingStrategy} 
   * supports variations of most common use case.
   * /p
   * pThis supports subclasses that choose to encode body content
   * either as a codeCDATA/code section or by escaping the characters.
   * Implementations should override [EMAIL PROTECTED] #encodeAsCDATA}
   * with an appropriate decision algorithm.
   * /p
   * @author a href='http://jakarta.apache.org/'Jakarta Commons Team/a
   * @version $Revision: 1.1 $
   */
  public abstract class BaseMixedContentEncodingStrategy
  extends MixedContentEncodingStrategy {
  
  /**
   * Escapes a sequence of body content.
   * @param bodyContent the content whose character data should be escaped, 
   * not null
   * @return the escaped character data, not null
   */
  protected String escapeCharacters(String bodyContent) {
  return XMLUtils.escapeBodyValue(bodyContent);
  }
  
  /**
   * Wraps the given content into a CDATA section.
   * @param bodyContent the content to be encoded into a CDATA
   * section
   * @return the content wrapped inside a CDATA section, not null
   */
  protected String encodeInCDATA(String bodyContent) {
  StringBuffer buffer = new StringBuffer(bodyContent);
  buffer.ensureCapacity(12);
  XMLUtils.escapeCDATAContent(buffer);
  return buffer.insert(0, ![CDATA[).append(]]).toString();
  }
  
  /**
   * Encodes the given body content by either escaping the character data
   * or by encoding within a codeCDATA/code section.
   * The algorithm used to decide whether a particular element's mixed 
   * should be escaped is delegated to the concrete subclass through
   * [EMAIL PROTECTED] #encodeAsCDATA}
   * @see 
org.apache.commons.betwixt.strategy.MixedContentEncodingStrategy#encode(java.lang.String,
 org.apache.commons.betwixt.ElementDescriptor)
   */
  public String encode(String bodyContent, ElementDescriptor element) {
  if (encodeAsCDATA(element)) {
  return encodeInCDATA(bodyContent);
  }
   
  return escapeCharacters(bodyContent);
  }
  
  /**
   * pShould the element described by the given 
   * codeElementDescriptor/code be encoded as a codeCDATA/code
   * section?
   * /p
   * pstrongUsage:/strong subclasses should provide a strategy
   * to determine whether an element should be encoded using a 
   * codeCDATA/code section.
   * /p
   * 
   * @param element codeElementDescriptor/code, not null
   * @return true if the element should be encoded 
   * as a codeCDATA/code section
   */
  protected abstract boolean encodeAsCDATA(ElementDescriptor element);
  
  }
  
  
  

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



Re: [collections] ReferenceMap changed for WeakIdentityMap but now broken

2004-03-24 Thread Janek Bogucki
On Tue, 2004-03-23 at 23:01, Stephen Colebourne wrote:
  I can't spot the problem, so I'm posting it in case someone else wants to
 take a look and tell me my stupid mistake ;-)

Sorry this isn't expressed as unit test but just in case this is enough
to go on I've posted it. I added a System.out.println to
testPurgeValues() just before the invocation of isEmpty()

  System.out.println(testPurgeValues: before isEmpty:  + iterations );
  testMap.isEmpty();

then two more in purge(Reference) to get this output

[junit] testPurgeValues: before isEmpty: 1
[junit] purge()
[junit] purge(Reference)
[junit] purge(Reference): entry: null
[junit] testPurgeValues: before isEmpty: 2
[junit] purge()
[junit] testPurgeValues: before isEmpty: 3
[junit] purge()
[junit] testPurgeValues: before isEmpty: 4
[junit] purge()
[junit] testPurgeValues: before isEmpty: 5


So purge correctly invokes purge(Reference) but purge(Reference) gets
null for entry and never enters the while block.

private void purge(Reference ref) {
System.out.println(purge(Reference));
// The hashCode of the reference is the hashCode of the
// mapping key, even if the reference refers to the 
// mapping value...
int hash = hash(ref);
int index = hashIndex(hash, data.length);
HashEntry previous = null;
HashEntry entry = data[index];

System.out.println(purge(Reference): entry:  + entry);
while (entry != null) {
if (((ReferenceEntry) entry).purge(ref)) {
if (previous == null) {
data[index] = entry.next;
} else {
previous.next = entry.next;
}
this.size--;
return;
}
previous = entry;
entry = entry.next;
}

}

-Janek

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



cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/strategy TestMixedContentEncoding.java

2004-03-24 Thread rdonkin
rdonkin 2004/03/24 14:52:59

  Added:   betwixt/src/test/org/apache/commons/betwixt/strategy
TestMixedContentEncoding.java
  Log:
  Tests for mixed content encoding strategy
  
  Revision  ChangesPath
  1.1  
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/strategy/TestMixedContentEncoding.java
  
  Index: TestMixedContentEncoding.java
  ===
  /*
   * Copyright 2004 The Apache Software Foundation.
   * 
   * Licensed under the Apache License, Version 2.0 (the License);
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   * 
   *  http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an AS IS BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */
   
  package org.apache.commons.betwixt.strategy;
  
  
  import java.io.StringWriter;
  
  import org.apache.commons.betwixt.AbstractTestCase;
  import org.apache.commons.betwixt.ElementDescriptor;
  import org.apache.commons.betwixt.io.BeanWriter;
  
  
  /**
   * Tests for mixed content encoding.
   * Mixed content encoding is the process by which body content
   * is written out (in an escaped form) into a textual output stream. 
   * @author a href='http://jakarta.apache.org/'Jakarta Commons Team/a
   * @version $Revision: 1.1 $
   */
  public class TestMixedContentEncoding extends AbstractTestCase {
  
  /** Concrete subclass used for testing */
  static class TestBaseMixedContentEncoding extends 
BaseMixedContentEncodingStrategy {
  boolean encode = false;
  ElementDescriptor element = null;
  
  TestBaseMixedContentEncoding(boolean encode) {
  this.encode = encode;
  }
  
  protected boolean encodeAsCDATA(ElementDescriptor element) {
  this.element = element;
  return encode;
  }
  }
  
  public TestMixedContentEncoding(String testName) {
  super(testName);
  }
  
  public void testBaseMixedEscapeCharacters() {
  BaseMixedContentEncodingStrategy mceStrategy = new 
TestBaseMixedContentEncoding(false);
  assertEquals(Check basic escaping, ablt;gt;amp;ba, 
mceStrategy.escapeCharacters(abba));
  }
  
  public void testBaseMixedCDATAEncoding() {
  BaseMixedContentEncodingStrategy mceStrategy = new 
TestBaseMixedContentEncoding(false);
  assertEquals(Check basic escaping, 
![CDATA[greetingab]]gt;ba/greeting]], 
mceStrategy.encodeInCDATA(greetingab]]ba/greeting));
  }
  
  public void testBaseMixedEncode() {
  ElementDescriptor descriptor = new ElementDescriptor();
  TestBaseMixedContentEncoding mceStrategy = new 
TestBaseMixedContentEncoding(false);
  assertEquals(
  Using character escaping, 
  lt;exclaimgt;hello, mumlt;/exclaimgt;, 
  mceStrategy.encode(exclaimhello, mum/exclaim, 
descriptor));
  
  assertEquals(Descriptor set, descriptor, mceStrategy.element);
  mceStrategy = new TestBaseMixedContentEncoding(true);
  assertEquals(
  Using CDATA encoding, 
  ![CDATA[exclaimhello, mum/exclaim]], 
  mceStrategy.encode(exclaimhello, mum/exclaim, 
descriptor));
  
  assertEquals(Descriptor set, descriptor, mceStrategy.element);
  }
  
  public void testDefaultImplementation() {
  ElementDescriptor descriptor = new ElementDescriptor();
  assertEquals(
  Default implementation uses character escaping,
  lt;proclaimgt;The King Is Dead, Long Live The Kinglt;/proclaimgt;,
  MixedContentEncodingStrategy.DEFAULT.encode(proclaimThe King Is Dead, 
Long Live The King/proclaim, descriptor));
  }
  
  public void testdefaultOutput() throws Exception {
  Element element = new Element();
  element.setValue(greetingWhat Ho Jeeves!/greeting);
  
  StringWriter out = new StringWriter();
  out.write(?xml version='1.0'?);
  BeanWriter writer = new BeanWriter(out);
  writer.getXMLIntrospector().setAttributesForPrimitives(false);
  writer.write(element);
  
  String expected = ?xml 
version='1.0'?Element\nvaluelt;greetinggt;What Ho 
Jeeves!lt;/greetinggt;/value\n/Element\n;
  String xml = out.getBuffer().toString();
   
  assertEquals(expected,xml); 
  
  }
  
  public void testEscapedOutput() throws Exception 

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io BeanWriter.java

2004-03-24 Thread rdonkin
rdonkin 2004/03/24 14:50:02

  Modified:betwixt/src/java/org/apache/commons/betwixt/io
BeanWriter.java
  Log:
  Added support for flexible encoding strategies for mixed content to BeanWriter
  
  Revision  ChangesPath
  1.22  +30 -2 
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanWriter.java
  
  Index: BeanWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/BeanWriter.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- BeanWriter.java   28 Feb 2004 13:38:33 -  1.21
  +++ BeanWriter.java   24 Mar 2004 22:50:02 -  1.22
  @@ -29,6 +29,7 @@
   import org.xml.sax.Attributes;
   
   import org.apache.commons.betwixt.XMLUtils;
  +import org.apache.commons.betwixt.strategy.MixedContentEncodingStrategy;
   
   /** pcodeBeanWriter/code outputs beans as XML to an io stream./p
 *
  @@ -100,6 +101,9 @@
   private boolean closedStartTag = true;
   /** Current level of indentation (starts at 1 with the first element) */
   private int indentLevel;
  +/** USed to determine how body content should be encoded before being output*/
  +private MixedContentEncodingStrategy mixedContentEncodingStrategy 
  += MixedContentEncodingStrategy.DEFAULT;
   
   /**
* p Constructor uses codeSystem.out/code for output./p
  @@ -262,6 +266,28 @@
   this.log = log;
   }
   
  +/**
  + * Gets the encoding strategy for mixed content.
  + * This is used to process body content 
  + * before it is written to the textual output.
  + * @return the codeMixedContentEncodingStrategy/code, not null
  + */
  +public MixedContentEncodingStrategy getMixedContentEncodingStrategy() {
  +return mixedContentEncodingStrategy;
  +}
  +
  +/**
  + * Sets the encoding strategy for mixed content.
  + * This is used to process body content 
  + * before it is written to the textual output.
  + * @param strategy the codeMixedContentEncodingStrategy/code
  + * used to process body content, not null
  + */
  +public void setMixedContentEncodingStrategy(MixedContentEncodingStrategy 
strategy) {
  +mixedContentEncodingStrategy = strategy;
  +}
  +
  +
   // New API
   //--
   
  @@ -364,7 +390,7 @@
   writer.write( '' );
   closedStartTag = true;
   }
  -writer.write( XMLUtils.escapeBodyValue(text) );
  +writer.write( mixedContentEncodingStrategy.encode(text, 
currentDescriptor) );
   currentElementIsEmpty = false;
   currentElementHasBodyText = true;
   }
  @@ -556,4 +582,6 @@
   writer.write( XMLUtils.escapeAttributeValue(value) );
   writer.write( '\' );
   }
  +
  +
   }
  
  
  

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



RE: [digester] mixed content update

2004-03-24 Thread Simon Kitching
On Thu, 2004-03-25 at 04:36, Edelson, Justin wrote:
 Since coding these changes, I've rethought whether or not this needs to
 be a subclass - since @text() can't be a legal XML element, existing
 code shouldn't be affected. After starting to duplicate all of the
 existing Digester test cases to run against my new subclass, I realized
 this was more copy and paste then I really wanted to do and modified the
 current Digester.java from CVS and all of the test cases passed.
 
 I'd like to go ahead and submit the patches  test cases into bugzilla,
 but would like to get a reading on whether or not my original assumption
 was correct - is a new subclass (MixedContentDigester) more or less
 likely to get submitted to CVS then a patch to Digester - all other
 things (documentation, unit tests, the code itself)?

Why not submit whichever is the least work for you? That way you can get
some feedback without spending too much effort up front. It's not likely
that a significant patch like this will be committed in its first
version anyway [none of mine have...].

If the patch has a significant performance hit on Digester, then it
would need to be either a subclass or require explicit enabling. And if
it is large and complex then I think a subclass would probably be
better. A simple and efficient extension to digester is probably best
integrated directly into the Digester class. But as mentioned above,
it's probably best to just get the discussion started by providing a
patch in either format (whichever is easiest), and get agreement later
on which is best.

I'll definitely have a look at your proposed patch, but at the moment
I'm not wildly keen on the idea. Of course I'm just one contributor -
and I reserve the right to change my opinion if the patch is blindingly
brilliant :-).

My initial feeling is that tacking @text on to the end of a pattern is
not elegant. It is neither consistent with the Digester's current style,
nor with xpath.

And I'm not sure there is any great demand for this feature from the
general target user group of digester. Which doesn't mean that such a
feature won't be accepted; however it does mean that it has a much
greater chance if it is a small and elegant solution. Or if it puts in
place a framework that can be built on to add other features to
digester.

If your @text pattern proposal is consistent with some standard, or
with the way some other app does things, then please mention this as
this would be a big point in favour of the design.

And if you think there are other features that could be added to
digester using @-style patterns then that would also be good to
mention.

And if you could provide some use-cases showing what kinds of problems
people can solve with this feature, that would be good.

Please don't think I'm trying to discourage you submitting the patch. 
The suggestions above are intended to increase the chances of a patch
being accepted..

Here's a suggestion for an alternative implementation. I haven't thought
this through deeply, so it may be broken. But it would avoid having
special pattern strings. This suggestion is just intended to stir the
pot of potential solutions :-)

  Define an interface called MixedContentRule or similar which rule
  classes can implement. 

  In Digester's startElement method:
if bodytext not null:
  for each rule matched by the last call to startElement:
if rule implements MixedContentRule
  call that rule's content(bodytext) method

The effect should be that any rule which implements the MixedContentRule
interface (and therefore has an extra content(String) method) gets its
content method called whever there is a piece of text followed by a
nested element.

Regards,

Simon


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



Question about ToStringStyle.appendInternal() method

2004-03-24 Thread Roy_Lu
Hi,

I was trying to figure out an infinate loop problem when I am printing out 
an object. I have an object 'a' of class 'A' which has a collection of 
object 'b' of class 'B', and 'B' has a reference back to 'A'. The 
toString() method of both 'A' and 'B' contains each other. When I tried to 
print 'a' out, I got into an infinate loop.

From looking at the source code of ToStringStyle.java, it appears to me 
that its appendInternal() method never registers the object to be printed 
to the registry. Therefore, the if check on the first line of this method 
if (ReflectionToStringBuilder.isRegistered(value) always returns false, 
and thus result in an infinate loop.

Please let me know if this is the case. Thanks.

Roy


Re: [PATCH] CLI NumberValidatorTest

2004-03-24 Thread John Keyes
Hi Simon,

Can you inline the patch, the attachment doesn't appear to have made it 
through.

Thanks for the help,
-John K
Simon Raess wrote:

hi

I've downloaded the latest sources from commons-cli from the branch 
RESEARCH_CLI_2_ROXSPRING and tried to run the tests with maven. The 
following tests failed:

org.apache.commons.cli2.NumberValidatorTest
 - testValidate_Number
 - testValidate_Percent
The attached patch fixes the 'bugs' in the tests. The problem was caused 
by some 'locale-specific' behavior.

org.apache.commons.cli2.jdepend.JDependTest
 - testAcceptableDistance
The distance for package org.apache.commons.cli2.commandline was 0.25 
(according to the test, it must be  0.2).

Hope this helps
Simon




-
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: Question about ToStringStyle.appendInternal() method

2004-03-24 Thread Gary Gregory
Roy,

Could you please create a Bugzilla ticket and attach a test case? That
would make it much easier for one of us to reproduce and deal with.

Thank you,
Gary

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 24, 2004 16:25
 To: [EMAIL PROTECTED]
 Subject: Question about ToStringStyle.appendInternal() method
 
 Hi,
 
 I was trying to figure out an infinate loop problem when I am printing
out
 an object. I have an object 'a' of class 'A' which has a collection of
 object 'b' of class 'B', and 'B' has a reference back to 'A'. The
 toString() method of both 'A' and 'B' contains each other. When I
tried to
 print 'a' out, I got into an infinate loop.
 
 From looking at the source code of ToStringStyle.java, it appears to
me
 that its appendInternal() method never registers the object to be
printed
 to the registry. Therefore, the if check on the first line of this
method
 if (ReflectionToStringBuilder.isRegistered(value) always returns
false,
 and thus result in an infinate loop.
 
 Please let me know if this is the case. Thanks.
 
 Roy



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



DO NOT REPLY [Bug 27899] - Javascript validation doesn't work if a form field is called name

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=27899

Javascript validation doesn't work if a form field is called name





--- Additional Comments From [EMAIL PROTECTED]  2004-03-25 03:41 ---
This following snippet will fix the bug,I tested it on IE  Mozilla, 

Instead of:
   oRequired = eval('new ' + form.name + '_required()');
Use:
   var formName = null;
   for (var attribIndex = 0; (attribIndex  form.attributes.length)   
(formName == null); attribIndex++) {
   if (form.attributes[attribIndex].name == name) {
formName = form.attributes[attribIndex].value;
 }
}
oRequired = eval('new ' + formName + '_required()');

However, it points out a weakness in Validators handling of javaScript in that
the snippet of code needs to be in a callable function. I could stick it in
one of the .js files like validateRequired.js but we need a better solution.

I am crunched at work until Mid April, and if someone wants to just srick this 
snippet in one of the .js files as a function thats ok by me.

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



cvs commit: jakarta-commons/jxpath/src/test/org/apache/commons/jxpath/ri/axes SimplePathInterpreterTest.java

2004-03-24 Thread dmitri
dmitri  2004/03/24 19:49:51

  Modified:jxpath/src/java/org/apache/commons/jxpath/ri/axes
SimplePathInterpreter.java ParentContext.java
AncestorContext.java
PrecedingOrFollowingContext.java ChildContext.java
   jxpath/src/java/org/apache/commons/jxpath/ri/model
NodePointer.java
   jxpath/src/java/org/apache/commons/jxpath/ri/model/beans
CollectionPointer.java NullElementPointer.java
NullPropertyPointer.java PropertyPointer.java
PropertyIterator.java
   jxpath/src/java/org/apache/commons/jxpath/ri
JXPathContextReferenceImpl.java
   jxpath/src/java/org/apache/commons/jxpath/ri/model/dynamic
DynamicPropertyPointer.java
   jxpath/src/test/org/apache/commons/jxpath/ri/axes
SimplePathInterpreterTest.java
  Log:
  getParent() will now return the actual parent NodePointer, 

  not some intermediate helper NodePointer
  
  Revision  ChangesPath
  1.15  +1 -1  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/SimplePathInterpreter.java
  
  Index: SimplePathInterpreter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/SimplePathInterpreter.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- SimplePathInterpreter.java29 Feb 2004 14:17:38 -  1.14
  +++ SimplePathInterpreter.java25 Mar 2004 03:49:50 -  1.15
  @@ -694,7 +694,7 @@
   int quality = PERFECT_MATCH;
   while (pointer != null  !pointer.isActual()) {
   quality--;
  -pointer = pointer.getParent();
  +pointer = pointer.getImmediateParentPointer();
   }
   return quality;
   }
  
  
  
  1.15  +3 -3  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/ParentContext.java
  
  Index: ParentContext.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/ParentContext.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- ParentContext.java29 Feb 2004 14:17:37 -  1.14
  +++ ParentContext.java25 Mar 2004 03:49:50 -  1.15
  @@ -64,10 +64,10 @@
   }
   setStarted = true;
   NodePointer thisLocation = parentContext.getCurrentNodePointer();
  -currentNodePointer = thisLocation.getParent();
  +currentNodePointer = thisLocation.getImmediateParentPointer();
   while (currentNodePointer != null
currentNodePointer.isContainer()) {
  -currentNodePointer = currentNodePointer.getParent();
  +currentNodePointer = currentNodePointer.getImmediateParentPointer();
   }
   if (currentNodePointer != null
currentNodePointer.testNode(nodeTest)) {
  
  
  
  1.15  +2 -2  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/AncestorContext.java
  
  Index: AncestorContext.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/AncestorContext.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- AncestorContext.java  29 Feb 2004 14:17:37 -  1.14
  +++ AncestorContext.java  25 Mar 2004 03:49:50 -  1.15
  @@ -86,7 +86,7 @@
   }
   
   while (true) {
  -currentNodePointer = currentNodePointer.getParent();
  +currentNodePointer = currentNodePointer.getImmediateParentPointer();
   
   if (currentNodePointer == null) {
   return false;
  
  
  
  1.15  +4 -18 
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/PrecedingOrFollowingContext.java
  
  Index: PrecedingOrFollowingContext.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/PrecedingOrFollowingContext.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- PrecedingOrFollowingContext.java  29 Feb 2004 14:17:38 -  1.14
  +++ PrecedingOrFollowingContext.java  25 Mar 2004 03:49:50 -  1.15
  @@ -80,8 +80,7 @@
   if (!setStarted) {
   setStarted = true;
   currentRootLocation = parentContext.getCurrentNodePointer();
  -NodePointer parent =
  -getMaterialPointer(currentRootLocation.getParent());
  +NodePointer parent = 

cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateUtilities.js validateByte.js validateCreditCard.js validateDate.js validateEmail.js validateFloat.js validateFloatRange.js validateIntRange.js validateInteger.js validateMask.js validateMaxLength.js validateMinLength.js validateRequired.js validateShort.js

2004-03-24 Thread rleland
rleland 2004/03/24 20:56:12

  Modified:validator/src/javascript/org/apache/commons/validator/javascript
validateByte.js validateCreditCard.js
validateDate.js validateEmail.js validateFloat.js
validateFloatRange.js validateIntRange.js
validateInteger.js validateMask.js
validateMaxLength.js validateMinLength.js
validateRequired.js validateShort.js
  Added:   validator/src/javascript/org/apache/commons/validator/javascript
validateUtilities.js
  Log:
  Bug#: 27899
  Add function to get an objects attribute if hidden by
  an html element, in this case the forms name attrubute.
  Have validator bring in Utility functions.
  
  Revision  ChangesPath
  1.8   +4 -2  
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.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- validateByte.js   8 Mar 2004 23:24:25 -   1.7
  +++ validateByte.js   25 Mar 2004 04:56:11 -  1.8
  @@ -11,7 +11,9 @@
   var focusField = null;
   var i = 0;
   var fields = new Array();
  -oByte = eval('new ' + form.name + '_ByteValidations()');
  +var formName = getAttribute(form,name);
  +
  +oByte = eval('new ' + formName.value + '_ByteValidations()');
   
   for (x in oByte) {
   var field = form[oByte[x][0]];
  
  
  
  1.7   +4 -2  
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.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- validateCreditCard.js 8 Mar 2004 23:24:25 -   1.6
  +++ validateCreditCard.js 25 Mar 2004 04:56:11 -  1.7
  @@ -11,7 +11,9 @@
   var focusField = null;
   var i = 0;
   var fields = new Array();
  -oCreditCard = eval('new ' + form.name + '_creditCard()');
  +var formName = getAttribute(form,name);
  +
  +oCreditCard = eval('new ' + formName.value + '_creditCard()');
   
   for (x in oCreditCard) {
   if ((form[oCreditCard[x][0]].type == 'text' ||
  
  
  
  1.9   +4 -2  
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.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- validateDate.js   8 Mar 2004 23:24:25 -   1.8
  +++ validateDate.js   25 Mar 2004 04:56:11 -  1.9
  @@ -11,7 +11,9 @@
  var focusField = null;
  var i = 0;
  var fields = new Array();
  -   oDate = eval('new ' + form.name + '_DateValidations()');
  +   var formName = getAttribute(form,name);
  +
  +   oDate = eval('new ' + formName.value + '_DateValidations()');
   
  for (x in oDate) {
  var field = form[oDate[x][0]];
  
  
  
  1.8   +4 -2  
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.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- validateEmail.js  8 Mar 2004 23:24:25 -   1.7
  +++ validateEmail.js  25 Mar 2004 04:56:11 -  1.8
  @@ -11,7 +11,9 @@
   var focusField = null;
   var i = 0;
   var fields = new Array();
  -oEmail = eval('new ' + form.name + '_email()');
  +var formName = getAttribute(form,name);
  +
  +oEmail = eval('new ' + formName.value + '_email()');
   
   for (x in oEmail) {
   var field = form[oEmail[x][0]];
  
  
  
  1.10  +4 -2  
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.9
  retrieving revision 

DO NOT REPLY [Bug 27899] - Javascript validation doesn't work if a form field is called name

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=27899

Javascript validation doesn't work if a form field is called name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-25 04:59 ---
Ok, This should be fixed in the Nightly build of Struts
given Craig rebuilds commons-validator tonight,
*** AND ***
You make sure to use the new validator-rules.xml file.

I have only tested this last patch against Mozilla,
reopen the bug report if there is a problem with IE etc...

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



cvs commit: jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom JDOMNodePointer.java

2004-03-24 Thread dmitri
dmitri  2004/03/24 21:41:29

  Modified:jxpath/src/java/org/apache/commons/jxpath/ri/model/dom
DOMNodePointer.java
   jxpath/src/java/org/apache/commons/jxpath/ri/compiler
NodeNameTest.java Path.java
   jxpath/src/java/org/apache/commons/jxpath/ri/model
NodePointer.java
   jxpath/src/java/org/apache/commons/jxpath/ri/model/beans
PropertyOwnerPointer.java
   jxpath/src/java/org/apache/commons/jxpath/ri/model/jdom
JDOMNodePointer.java
  Log:
  Introduced NodeNameTest.isWildcard()
  
  Revision  ChangesPath
  1.22  +6 -5  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/dom/DOMNodePointer.java
  
  Index: DOMNodePointer.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/dom/DOMNodePointer.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- DOMNodePointer.java   29 Feb 2004 14:17:44 -  1.21
  +++ DOMNodePointer.java   25 Mar 2004 05:41:29 -  1.22
  @@ -90,16 +90,17 @@
   return false;
   }
   
  -QName testName = ((NodeNameTest) test).getNodeName();
  -String testLocalName = testName.getName();
  -boolean wildcard = testLocalName.equals(*);
  +NodeNameTest nodeNameTest = (NodeNameTest) test;
  +QName testName = nodeNameTest.getNodeName();
  +boolean wildcard = nodeNameTest.isWildcard();
   String testPrefix = testName.getPrefix();
   if (wildcard  testPrefix == null) {
   return true;
   }
   
   if (wildcard
  -|| testLocalName.equals(DOMNodePointer.getLocalName(node))) {
  +|| testName.getName()
  +.equals(DOMNodePointer.getLocalName(node))) {
   String nodePrefix = DOMNodePointer.getPrefix(node);
   if (equalStrings(testPrefix, nodePrefix)) {
   return true;
  
  
  
  1.10  +5 -1  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/compiler/NodeNameTest.java
  
  Index: NodeNameTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/compiler/NodeNameTest.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- NodeNameTest.java 29 Feb 2004 14:17:38 -  1.9
  +++ NodeNameTest.java 25 Mar 2004 05:41:29 -  1.10
  @@ -31,6 +31,10 @@
   public QName getNodeName() {
   return qname;
   }
  +
  +public boolean isWildcard() {
  +return qname.getName().equals(*);
  +}
   
   public String toString() {
   return qname.toString();
  
  
  
  1.13  +2 -3  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/compiler/Path.java
  
  Index: Path.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/compiler/Path.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Path.java 29 Feb 2004 14:17:39 -  1.12
  +++ Path.java 25 Mar 2004 05:41:29 -  1.13
  @@ -105,8 +105,7 @@
   return false;
   }
   
  -String name = ((NodeNameTest) nodeTest).getNodeName().getName();
  -if (name.equals(*)) {
  +if (((NodeNameTest) nodeTest).isWildcard()) {
   return false;
   }
   return areBasicPredicates(step.getPredicates());
  
  
  
  1.24  +5 -5  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/NodePointer.java
  
  Index: NodePointer.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/model/NodePointer.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- NodePointer.java  25 Mar 2004 03:49:50 -  1.23
  +++ NodePointer.java  25 Mar 2004 05:41:29 -  1.24
  @@ -332,7 +332,8 @@
   if (isContainer()) {
   return false;
   }
  -QName testName = ((NodeNameTest) test).getNodeName();
  +NodeNameTest nodeNameTest = (NodeNameTest) test;
  +QName testName = nodeNameTest.getNodeName();
   QName nodeName = getName();
   if (nodeName == null) {
   return false;
  @@ -347,11 +348,10 @@
   return false;
   }
   }
  -String testLocalName = 

cvs commit: jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/compiler ExtensionFunction.java

2004-03-24 Thread dmitri
dmitri  2004/03/24 21:42:01

  Modified:jxpath/src/java/org/apache/commons/jxpath/util
BasicTypeConverter.java
   jxpath/src/test/org/apache/commons/jxpath/ri/compiler
TestFunctions.java ExtensionFunctionTest.java
   jxpath/src/java/org/apache/commons/jxpath/ri/axes
InitialContext.java RootContext.java
NamespaceContext.java
   jxpath/src/java/org/apache/commons/jxpath
PackageFunctions.java
   jxpath/src/java/org/apache/commons/jxpath/ri
EvalContext.java
   jxpath/src/java/org/apache/commons/jxpath/ri/compiler
ExtensionFunction.java
  Log:
  Improved type conversion for extenstion functions
  
  Revision  ChangesPath
  1.13  +7 -1  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/util/BasicTypeConverter.java
  
  Index: BasicTypeConverter.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/util/BasicTypeConverter.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- BasicTypeConverter.java   29 Feb 2004 14:17:43 -  1.12
  +++ BasicTypeConverter.java   25 Mar 2004 05:42:01 -  1.13
  @@ -177,6 +177,12 @@
   }
   
   if (toType == Object.class) {
  +if (object instanceof NodeSet) {
  +return convert(((NodeSet) object).getValues(), toType);
  +}
  +else if (object instanceof Pointer) {
  +return convert(((Pointer) object).getValue(), toType);
  +}
   return object;
   }
   
  
  
  
  1.10  +6 -1  
jakarta-commons/jxpath/src/test/org/apache/commons/jxpath/ri/compiler/TestFunctions.java
  
  Index: TestFunctions.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/test/org/apache/commons/jxpath/ri/compiler/TestFunctions.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- TestFunctions.java29 Feb 2004 14:17:42 -  1.9
  +++ TestFunctions.java25 Mar 2004 05:42:01 -  1.10
  @@ -49,6 +49,11 @@
   ((Number) context.getContextNodePointer().getValue()).intValue();
   this.bar = bar;
   }
  +
  +public TestFunctions(int foo, Object object, boolean another) {
  +this.foo = foo;
  +bar = String.valueOf(object);
  +}
   
   public int getFoo() {
   return foo;
  
  
  
  1.15  +9 -11 
jakarta-commons/jxpath/src/test/org/apache/commons/jxpath/ri/compiler/ExtensionFunctionTest.java
  
  Index: ExtensionFunctionTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/test/org/apache/commons/jxpath/ri/compiler/ExtensionFunctionTest.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- ExtensionFunctionTest.java29 Feb 2004 14:17:42 -  1.14
  +++ ExtensionFunctionTest.java25 Mar 2004 05:42:01 -  1.15
  @@ -170,6 +170,12 @@
   
   // Allocate new object using a custom constructor - type conversion
   assertXPathValue(context, string(test:new('3', 4)), foo=3; bar=4.0);
  +
  +context.getVariables().declareVariable(A, baz);
  +assertXPathValue(
  +context,
  +string(test:new(2, $A, false)),
  +foo=2; bar=baz);
   }
   
   public void testMethodCall() {
  @@ -210,16 +216,8 @@
   size(beans), 
   new Integer(2));
   
  -boolean exception = false;
  -try {
  -assertXPathValue(context, add($myList, 'hello'), Boolean.TRUE);
  -}
  -catch (Exception ex) {
  -exception = true;
  -}
  -assertTrue(
  -Exception trying to add to an unmodifiable list,
  -exception);
  +context.getValue(add($myList, 'hello'));
  +assertEquals(After adding an element, 2, list.size());
   }
   
   public void testStaticMethodCall() {
  
  
  
  1.14  +6 -2  
jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/InitialContext.java
  
  Index: InitialContext.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/ri/axes/InitialContext.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- InitialContext.java   29 Feb 2004 14:17:37 -  1.13
  +++ InitialContext.java   25 Mar 2004 05:42:01 -  1.14
  @@ -50,7 +50,11 @@
   public NodePointer 

RE: [codec] StatefulDecoders

2004-03-24 Thread Brett Henderson
Alex,

I haven't had a chance to respond to your email yet.  I'll try to do so
tonight.

I'll knock up a couple of quick interfaces for comparison at the same time.

Cheers,
Brett


 -Original Message-
 From: Alex Karasulu [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, 24 March 2004 12:23 PM
 To: 'Jakarta Commons Developers List'
 Subject: RE: [codec] StatefulDecoders
 
 
 Brett,
 
 
 
 Ok let's take a breath and dive into this email :-).
 
 
 


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



Re: [PATCH] CLI NumberValidatorTest

2004-03-24 Thread Simon Raess
hmm, your right. no problem.

-- snip --
Index:  
src/test/org/apache/commons/cli2/validation/NumberValidatorTest.java
===
RCS file:  
/home/cvspublic/jakarta-commons/cli/src/test/org/apache/commons/cli2/ 
validation/Attic/NumberValidatorTest.java,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 NumberValidatorTest.java
---  
src/test/org/apache/commons/cli2/validation/NumberValidatorTest.java	8  
Feb 2004 13:09:00 -	1.1.2.5
+++  
src/test/org/apache/commons/cli2/validation/NumberValidatorTest.java	24  
Mar 2004 22:17:05 -
@@ -24,7 +24,12 @@

 public class NumberValidatorTest extends TestCase {
 public void testValidate_Number() throws InvalidArgumentException {
-final Object[] array = new Object[] { 1, 1.07, -.45 };
+	NumberFormat format = NumberFormat.getNumberInstance();
+final Object[] array =
+new Object[] {
+format.format(1d),
+format.format(1.07d),
+format.format(-.45d)};
 final List list = Arrays.asList(array);
 final Validator validator =  
NumberValidator.getNumberInstance();

@@ -57,7 +62,13 @@
 }
 public void testValidate_Percent() throws InvalidArgumentException  
{
-final Object[] array = new Object[] { 1%, 107%, -45%,  
0.001% };
+NumberFormat format = NumberFormat.getPercentInstance();
+final Object[] array =
+new Object[] {
+format.format(.01),
+format.format(1.07),
+format.format(-.45),
+format.format(.1)};
 final List list = Arrays.asList(array);
 final Validator validator =  
NumberValidator.getPercentInstance();

Am 25.03.2004 um 01:30 schrieb John Keyes:

Hi Simon,

Can you inline the patch, the attachment doesn't appear to have made  
it through.

Thanks for the help,
-John K
Simon Raess wrote:

hi
I've downloaded the latest sources from commons-cli from the branch  
RESEARCH_CLI_2_ROXSPRING and tried to run the tests with maven. The  
following tests failed:
org.apache.commons.cli2.NumberValidatorTest
 - testValidate_Number
 - testValidate_Percent
The attached patch fixes the 'bugs' in the tests. The problem was  
caused by some 'locale-specific' behavior.
org.apache.commons.cli2.jdepend.JDependTest
 - testAcceptableDistance
The distance for package org.apache.commons.cli2.commandline was 0.25  
(according to the test, it must be  0.2).
Hope this helps
Simon
-- 
--
-
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: [codec][lang] Can't build with Maven 1.0-rc2

2004-03-24 Thread dion
How did you do the install?
--
dIon Gillard, Multitask Consulting



Gary Gregory [EMAIL PROTECTED] wrote on 25/03/2004 07:41:03 AM:

 Hello,
 
 I've installed Maven 1.0-rc2 (I had Maven 1.0-rc1) and I am getting
 errors in lang and codec. This all used to work in rc1 of course.
 
 First I tried to run site:generate over and over until maven downloaded
 all the jar files it thought it needed but things blew up in a
 plugin.jelly file I think. 
 
 I then nuked everything in my user .maven/plugins and .maven/repository.
 Then I ran clean site:generate which downloaded a ton of jars but I got
 the same errors in maven-checkstyle-plugin-2.3.
 
 Any clues?
 
 For lang:
 
 maven clean site:generate
  __  __
 |  \/  |__ _Apache__ ___
 | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
 |_|  |_\__,_|\_/\___|_||_|  v. 1.0-rc2
 
 Attempting to download vdoclet-20020711.jar.
 
 .
 Attempting to download qdox-current.jar.
 ..
 .
 Attempting to download logkit-1.0.1.jar.
 
 .
 build:start:
 
 clean:clean:
 
 clean:
 
 site:
 xdoc:register-reports:
 maven-checkstyle-plugin:register:
 
 maven-javadoc-plugin:register:
 
 maven-junit-report-plugin:register:
 
 maven-jxr-plugin:register:
 
 maven-license-plugin:register:
 
 maven-tasklist-plugin:register:
 
 
 site:run-reports:
 [echo] Generating the Checkstyle...
 checkstyle:init:
 
 checkstyle:report:
 checkstyle:run:
 [mkdir] Created dir:
 C:\cvs-store\apache.org\jakarta\commons\lang\target
 [echo] Using checkstyle.xml for checkstyle ...
 
 BUILD FAILED
 File.. file:/C:/Documents and
 Settings/ggregory/.maven/plugins/maven-checkstyle-plugin-2.3/plugin.jell
 y
 Element... ant:checkstyle
 Line.. 133
 Column 63
 Unable to create a Checker: Cannot set property 'basedir' in module
 Checker to '.': . is not an absolute path
 Total time: 10 seconds
 Finished at: Wed Mar 24 11:28:22 PST 2004
 
 
 For codec:
 
 maven clean site:generate
  __  __
 |  \/  |__ _Apache__ ___
 | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
 |_|  |_\__,_|\_/\___|_||_|  v. 1.0-rc2
 
 build:start:
 
 clean:clean:
 [delete] Deleting directory
 C:\cvs-store\apache.org\jakarta\commons\codec\target
 [delete] Deleting:
 C:\cvs-store\apache.org\jakarta\commons\codec\velocity.log
 
 clean:
 
 site:
 xdoc:register-reports:
 maven-changelog-plugin:register:
 
 maven-checkstyle-plugin:register:
 
 maven-clover-plugin:register:
 
 maven-developer-activity-plugin:register:
 
 maven-file-activity-plugin:register:
 
 maven-javadoc-plugin:register:
 
 maven-junit-report-plugin:register:
 
 maven-jxr-plugin:register:
 
 maven-license-plugin:register:
 
 
 site:run-reports:
 [echo] Generating the Change Log...
 maven-changelog-plugin:report:
 [echo] Generating the changelog report
 ChangeLog found: 9 entries
 [mkdir] Created dir:
 C:\cvs-store\apache.org\jakarta\commons\codec\target\generated-xdocs
 
 [echo] Generating the Checkstyle...
 checkstyle:init:
 
 checkstyle:report:
 checkstyle:run:
 [echo] Using
 C:\cvs-store\apache.org\jakarta\commons\codec/checkstyle.xml for
 checkstyle ...
 
 BUILD FAILED
 File.. file:/C:/Documents and
 Settings/ggregory/.maven/plugins/maven-checkstyle-plugin-2.3/plugin.jell
 y
 Element... ant:checkstyle
 Line.. 133
 Column 63
 Unable to create a Checker: Cannot set property 'basedir' in module
 Checker to 'src/checkstyle': src\checkstyle is not an absolute path
 Total time: 1 minutes 18 seconds
 Finished at: Wed Mar 24 12:39:41 PST 2004
 
 Gary
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


Re: xdocs/ missing?

2004-03-24 Thread dion
Is SVN access to Apache documented at the moment?
--
dIon Gillard, Multitask Consulting



robert burrell donkin [EMAIL PROTECTED] wrote on 
24/03/2004 07:04:02 PM:

 On 24 Mar 2004, at 00:10, Noel J. Bergman wrote:
 
 snip
 
  As a general rule, people shouldn't be manipulating /home/cvs 
  directly.  As
  soon as we migrate to Subversion the problems will go away.
 
 +1
 
 it's important that the ASF has a complete, unadulterated record of how 
 each artifact has been created. so, directories and files which are no 
 longer used should be removed using cvs (rather than being deleted from 
 the server).
 
 AIUI the infrastructure policy is that committers should not be 
 directly modifying the structure of our repositories. (this extends 
 even to deleting old lock files.) the right way is to ask 
 infrastructure to perform the operation. there is now a system of 
 rotating administrators so these requests should be serviced much more 
 promptly than in the past.
 
 - robert
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


DO NOT REPLY [Bug 27589] - MultiThreadedConnectionManager should provide a shutdown

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=27589

MultiThreadedConnectionManager should provide a shutdown





--- Additional Comments From [EMAIL PROTECTED]  2004-03-24 10:55 ---
I believe this behavior is justified (after all, shutting down connection
manager is all about closing connections it manages, imo) as long as this fact
is reflected in the javadocs and documentation.

Oleg

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



Httpclient + HTTPS + Proxy + BASIC Authentication

2004-03-24 Thread John Melody

Hi,

I have read the notes on the bug in Httpclient V2.0 to do with
using Basic Authentication with a HTTPS Url through a proxy.

One workaround proposed is to use preemptive authentication.

Are the credentials i.e. username, password sent unencrypted to the
target server when Preemptive Authentication is used even through the URL is
a https URL.

There are some notes about a PATCH being available for this problem.
If so, how do I get it - I am currently using HttpCLient V2.0. Can
this version be patched to fix the problem or must I move to a newer
version of httpclient to avail of the patch.

thanks for any help,
John.

regards,
John.
John Melody
SyberNet Ltd.
Galway Business Park,
Dangan,
Galway.
Tel. No. +353 91 514400
Fax. NO. +353 91 514409
Mobile - 087-2345847


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



Re: [VOTE][PROPOSAL] Promote HttpClient to Jakarta Level

2004-03-24 Thread Michael Becke
+1

On Mar 24, 2004, at 2:24 AM, Adrian Sutton wrote:

Hi all,
Continuing to push this forward, I propose that we adopt the proposal 
below
as our formal proposal to the Jakarta PMC to promote HttpClient to a 
Jakarta
level project.

Please vote as follows:

-
 Vote:  Promote HttpClient to Jakarta level
 [ ] +1 I am in favor of the proposal, and will help support it.
 [ ] +0 I am in favor of the proposal, but am unable to help support 
it.
 [ ] -0 I am not in favor of the proposal.
 [ ] -1 I am against this proposal (must include a reason).

-

Regards,

Adrian Sutton.



(0) RATIONALE
HTTP is the main protocol used today on the internet.  Although the JDK
includes basic support for building HTTP-aware client applications, it
doesn't provide the flexibility or ease of use needed for many 
projects.

The current package in Jakarta-Commons is a widely used implementation 
with
a strong community behind it.  The size of it's community and it's 
project
has significantly outgrown the commons project and a move to a Jakarta 
level
project would provide better support for that community and for the on 
going
development of HttpClient.

(1) SCOPE
The project shall create and maintain a Java library implementing the 
client
side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC 
2616 and
RFC 2617.

HttpClient also supports the following RFCs.

* RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade 
to RFC
2965 is planned for a future version of HttpClient

* RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax

* RFC 1867 Form-based File Upload in HTML

The package should:

* Have an API which should be as simple to use as possible
* Be as easy to extend as possible
* Provide unconditional support for HTTP/1.1
The package is quite different from the HTTP client provided as part 
of the
JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods 
being
sent (instead of making that transparent to the user), and generally 
allows
more interaction with the lower level connection.  The JDK client is 
also
not very intuitive to use.

The package is used by a wide range of projects both within the ASF 
and from
third parties.  These include:

* Jakarta Slide
* Jakarta Commons Latka
* Nortel Networks
* HtmlUnit
* Jakarta Cactus
* JSR 147
* NOSE Applied Intelligence ag
* MindIQ's Design-a-Course
* ContactOffice
* Newknow
* de4d2c
* Furies
* Term Highlighting for Verity Ultraseek search results
* Mule - Universal Message Objects
* many more.
(1.5) Interaction With Other Packages

HttpClient relies on:

* Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
* Jakarta commons-logging (Version 1.0 or later)
* Jakarta commons-codec (Version 1.2 or later)
(2) INITIAL SOURCE OF THE PACKAGE

The initial codebase exists as a sub-project of Jakarta-Commons, in the
httpclient subdirectory of the jakarta-commons cvs tree.
The proposed package name for the new sub-project is 
org.apache.httpclient.

(3) REQUIRED JAKARTA RESOURCES

* CVS Repository - New module, jakarta-httpclient in the CVS 
repository.

* Initial Committers - The list is provided below.  All of the proposed
committers are currently jakarta-commons committers.
* Mailing List - Two new mailing lists will be required:
[EMAIL PROTECTED] and 
[EMAIL PROTECTED]
These will be used for developer discussions and user discussions
respectively.  CVS commit messages will be sent to the httpclient-dev 
list.

* Bugzilla - New product category HttpClient, with appropriate 
version
identifiers as needed.  Existing bugs in the HttpClient component 
under the
Commons product category will need to be migrated.

(4) INITIAL COMMITTERS
The initial committers on the HttpClient component shall be:
* Michael Becke
* Jeff Dever
* dIon Gillard
* Ortwin Glück
* Oleg Kalnichevski
* Adrian Sutton
-
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: [PATCH] Yet another refactoring of authentication logic Oops Idid it again

2004-03-24 Thread Michael Becke
Hi Oleg,

Sorry, I completely forgot about this one. Could you send the patch  
again, or add it to a bug?

Mike

On Mar 24, 2004, at 5:55 AM, Kalnichevski, Oleg wrote:

Any objections to committing this patch?

Oleg

-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 18, 2004 22:54
To: Jakarta Commons HttpClient mailing list; Vincent Massol
Subject: [PATCH] Yet another refactoring of authentication logic Oops
Idid it again
Folks,

I believe that most of you have already been suspecting that tinkering
with the authentication framework is a sort of Russian traditional
sport. Well, almost ;-)
Prompted by the 2.0 incompatibility discovered by Vincent Massol
vmassol at pivolis.com (Specials thanks go to Gump and all the Gump
Meisters) I went over the authentication code one more time and made  
yet
another series of changes

* I factored out the authentication challenge processing logic from the
HttpMethodDirector to a class of its own. Thanks to that authentication
challenge processing can now be tested separately. Test cases provided.
* HttpMethodDirector no longer intervenes if Authorization 
Proxy-Authorization are set manually by the user. Custom authorization
headers are never overwritten
* Introduced a new class called AuthState that represents the
authentication process state that contains all the authentication
details. Basically it is just a convenience wrapper around the
authentication scheme interface.
* Proxy and host authentication state objects moved to the HTTP method
level, so that they can be queried by the user to find out the details
about authentication that has been performed by the HttpMethodDirector.
With the current implementation all the details of proxy and host
authentication are contained within the HttpMethodDirector instance,
which exists only within the lifetime of HttpClient#executeMethod()
execution. As soon as the method returns, the respective
HttpMethodDirector instance gets GCed along with the authentication
details
* More test cases

Let me know what you think

Oleg

PS: I hope this is going to be the last round of changes in the
authentication logic. I can live with it now (until 4.0, of course)
*** 

The information in this email is confidential and may be legally  
privileged.  Access to this email by anyone other than the intended  
addressee is unauthorized.  If you are not the intended recipient of  
this message, any review, disclosure, copying, distribution,  
retention, or any action taken or omitted to be taken in reliance on  
it is prohibited and may be unlawful.  If you are not the intended  
recipient, please reply to or forward a copy of this message to the  
sender and delete the message, any attachments, and any copies thereof  
from your system.
*** 


-
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]


DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25529

Redesign of HTTP authentication framework

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2004-03-24 13:30 ---
Prompted by the 2.0 incompatibility discovered by Vincent Massol
vmassol at pivolis.com (Specials thanks go to Gump and all the Gump
Meisters) I went over the authentication code one more time and made yet
another series of changes 

* I factored out the authentication challenge processing logic from the
HttpMethodDirector to a class of its own. Thanks to that authentication
challenge processing can now be tested separately. Test cases provided.

* HttpMethodDirector no longer intervenes if Authorization 
Proxy-Authorization are set manually by the user. Custom authorization
headers are never overwritten

* Introduced a new class called AuthState that represents the
authentication process state that contains all the authentication
details. Basically it is just a convenience wrapper around the
authentication scheme interface.

* Proxy and host authentication state objects moved to the HTTP method
level, so that they can be queried by the user to find out the details
about authentication that has been performed by the HttpMethodDirector.
With the current implementation all the details of proxy and host
authentication are contained within the HttpMethodDirector instance,
which exists only within the lifetime of HttpClient#executeMethod()
execution. As soon as the method returns, the respective
HttpMethodDirector instance gets GCed along with the authentication
details

* More test cases

Oleg

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



DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-03-24 13:31 ---
Created an attachment (id=10949)
Follow-up patch (take 1)

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



RE: Httpclient + HTTPS + Proxy + BASIC Authentication

2004-03-24 Thread Kalnichevski, Oleg

John,
HttpClient will not/cannot attempt to authenticate with the target server until the 
transport layer (SSL tunnel) is up and running. It does not matter if pre-emptive 
authentication is used or not, SSL takes care of the transport security between the 
client and the target server. Only when authenticating against a proxy using Basic 
scheme, the proxy credentials are sent in clear

Oleg

-Original Message-
From: John Melody [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 13:58
To: Commons HttpClient Project
Subject: RE: Httpclient + HTTPS + Proxy + BASIC Authentication


Hi Oleg,

Thanks for your quick response.

Just to clarify one point - I am not concerned about authenticating
with the proxy - rather I need to do BASIC Authentication with the target
server and I am wondering if I use pre-emptive authentication is the
username
and password creditentials sent to the target server in clear text - before
the full SSL connection is in place.

So when I make the request to the URL i.e.
https://www.targetserver.com/document
via the proxy, the target server is going to come back looking for
username/password credentials becuase the document resource will require
this.
Httpclient will allow me to configure it so that it takes care of this
authentication request from the target server using

post.setDoAuthentication( true );

However, if I am using pre-emptive authentication, has the username and
password gone to the target server unsecured.

thanks for your help,

John


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: 24 March 2004 13:26
To: Commons HttpClient Project
Subject: RE: Httpclient + HTTPS + Proxy + BASIC Authentication



John,

The connection between the client (the agent) and the proxy is always
unencrypted
regardless of the transport mechanism used to access the target server
(plain
or SSL). Therefore, when the Basic authentication scheme is used to
authenticate
with the proxy, the credentials are transmitted in clear case. To my
knowledge
none of the mainstream proxy servers currently implements transport security
between the client (the agent) and the proxy.

The HTTPS + Proxy + BASIC Authentication bug has been fixed in the
3.0-prealpha-nightly
version of HttpClient. Please note that this is unstable development version
and it is incompatible with 2.0 API. If things progress well, we may have
the first official alpha out by the of May for the public review of the new
3.0 API.

http://jakarta.apache.org/commons/httpclient/downloads.html

Cheers,

Oleg

-Original Message-
From: John Melody [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 13:36
To: [EMAIL PROTECTED]
Subject: Httpclient + HTTPS + Proxy + BASIC Authentication


Hi,

I have read the notes on the bug in Httpclient V2.0 to do with
using Basic Authentication with a HTTPS Url through a proxy.

One workaround proposed is to use preemptive authentication.

Are the credentials i.e. username, password sent unencrypted to the
target server when Preemptive Authentication is used even through the URL is
a https URL.

There are some notes about a PATCH being available for this problem.
If so, how do I get it - I am currently using HttpCLient V2.0. Can
this version be patched to fix the problem or must I move to a newer
version of httpclient to avail of the patch.

thanks for any help,
John.

regards,
John.
John Melody
SyberNet Ltd.
Galway Business Park,
Dangan,
Galway.
Tel. No. +353 91 514400
Fax. NO. +353 91 514409
Mobile - 087-2345847


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



***
The information in this email is confidential and may be legally privileged.
Access to this email by anyone other than the intended addressee is
unauthorized.  If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful.  If
you are not the intended recipient, please reply to or forward a copy of
this message to the sender and delete the message, any attachments, and any
copies thereof from your system.

***

-
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]


***
The information in this email is confidential and may be legally privileged.  Access 
to 

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25529

Redesign of HTTP authentication framework





--- Additional Comments From [EMAIL PROTECTED]  2004-03-25 03:15 ---
Looks good to me.  I like it.

Mike

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



Re: [VOTE][PROPOSAL] Promote HttpClient to Jakarta Level

2004-03-24 Thread dion
Michael Becke [EMAIL PROTECTED] wrote on 25/03/2004 12:23:46 AM:



 Please vote as follows:

 -
  Vote:  Promote HttpClient to Jakarta level
  [X] +1 I am in favor of the proposal, and will help support it.
  [ ] +0 I am in favor of the proposal, but am unable to help support 
 it.
  [ ] -0 I am not in favor of the proposal.
  [ ] -1 I am against this proposal (must include a reason).

 -
--
dIon Gillard, Multitask Consulting


Re: question re: cookies

2004-03-24 Thread Roland Weber
Hello Gil,

two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?

Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.

You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.

cheers,
  Roland





Alvarez, Gil [EMAIL PROTECTED]
25.03.2004 07:37
Please respond to Commons HttpClient Project
 
To: [EMAIL PROTECTED]
cc: 
Subject:question re: cookies


Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.

 

We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.

 

I obfuscated the url's and data, but the gist of it is that we hit the
url:

 

2004/03/24 19:06:25:295 PST [DEBUG] wire - - GET /a/b/c/aol
HTTP/1.1[\r][\n]

 

We get back a Set-Cookie:

 

2004/03/24 19:06:25:535 PST [DEBUG] wire - - Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]

 

I then see this:

 

2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
$Version=0

; badsc=cookie-value; $Path=/X/b/c. Illegal path attribute /X/b/c.
Path of origin: /a/b/c/aol

 

and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:

 

if (!path.startsWith(cookie.getPath())) {

throw new MalformedCookieException(

Illegal path attribute \ + cookie.getPath()

+ \. Path of origin: \ + path + \);

}

 

So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.

 

Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??

 

Thanks.




RE: question re: cookies

2004-03-24 Thread Alvarez, Gil
Thanks, yes, the old code pulled it out of the header directly, but the
rest of the story is that I save that cookie for later submittal in a
url request. I tried using addRequestHeader(Cookie, ...) and that
didn't work. I surmised that it was because httpclient liked to operate
with higher-level abstractions, so I switched to using real Cookie
objects. I'd much rather do a getHeader()/setHeader() operation or
getCookie()/setCookie()operation; I don't want to mix the semantics
(such as getHeader()/setCookie()). Sounds like the cookie policy is the
way to go.

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 24, 2004 10:51 PM
To: Commons HttpClient Project
Subject: Re: question re: cookies

Hello Gil,

two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?

Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.

You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.

cheers,
  Roland





Alvarez, Gil [EMAIL PROTECTED]
25.03.2004 07:37
Please respond to Commons HttpClient Project
 
To: [EMAIL PROTECTED]
cc: 
Subject:question re: cookies


Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.

 

We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.

 

I obfuscated the url's and data, but the gist of it is that we hit the
url:

 

2004/03/24 19:06:25:295 PST [DEBUG] wire - - GET /a/b/c/aol
HTTP/1.1[\r][\n]

 

We get back a Set-Cookie:

 

2004/03/24 19:06:25:535 PST [DEBUG] wire - - Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]

 

I then see this:

 

2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
$Version=0

; badsc=cookie-value; $Path=/X/b/c. Illegal path attribute /X/b/c.
Path of origin: /a/b/c/aol

 

and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:

 

if (!path.startsWith(cookie.getPath())) {

throw new MalformedCookieException(

Illegal path attribute \ + cookie.getPath()

+ \. Path of origin: \ + path + \);

}

 

So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.

 

Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??

 

Thanks.



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



RE: question re: cookies

2004-03-24 Thread Roland Weber
Ah yes, cookie headers that were manually set used
to get overridden. As far as I remember, that changed
a while back. Though I cannot tell whether the change
went into 2.0 or only into the development branch.

cheers,
  Roland






Alvarez, Gil [EMAIL PROTECTED]
25.03.2004 08:04
Please respond to Commons HttpClient Project
 
To: Commons HttpClient Project 
[EMAIL PROTECTED]
cc: 
Subject:RE: question re: cookies


Thanks, yes, the old code pulled it out of the header directly, but the
rest of the story is that I save that cookie for later submittal in a
url request. I tried using addRequestHeader(Cookie, ...) and that
didn't work. I surmised that it was because httpclient liked to operate
with higher-level abstractions, so I switched to using real Cookie
objects. I'd much rather do a getHeader()/setHeader() operation or
getCookie()/setCookie()operation; I don't want to mix the semantics
(such as getHeader()/setCookie()). Sounds like the cookie policy is the
way to go.

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 24, 2004 10:51 PM
To: Commons HttpClient Project
Subject: Re: question re: cookies

Hello Gil,

two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?

Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.

You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.

cheers,
  Roland