[cli] library change suggestion
Forwarding to the list
- Original Message -
From: Mike McLean [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I started using the CLI library and found it really nice. One thing I
though might be missing for my needs was a way to validate the arguments
given to a parameter. In other words, if my args[0] looks like -w
Monday, I want to be sure that Monday is a valid value for the w Option.
So I figured I'd give it a shot. I downloaded the source code and have
made the modifications to suit my needs. I've done limited testing, but
it works for my needs. I figured I'd send you guys the small changes I
made in case you find the idea ok.
Here are the changes that were made:
- OptionBuilder:
Added the validArguments String array memeber along with the
withValidArguments method. Changed the reset method to reset
validArguments.
- Option:
Added the validArguments member along with the accessor methods. Also
changed the clone method to clone the new field.
- Parser:
I added a checkArgValidity method. The method throws a
InvalidArgumentException. The reason I didn't want to throw just a
ParseException is that I didn't find the message usefull. If the
argument isn't valid, then I throw that exception. The call to
checkArgValidity is made from the processArgs method.
- InvalidArgumentException:
As I mentionned, this is a new class that extends ParseException so no
change in code to throw new exception types.
Here's how I use it:
String[] valueWeekdays = {Monday,Tuesday,Wednesday,Thursday};
Option weekday = OptionBuilder.withArgName( Weekday )
.withLongOpt( weekday )
.withDescription( Weekday to generate.
Monday to Thursday or Auto )
.hasArg()
.hasArgs(1)
.isRequired()
.withValidArguments(valueWeekdays)
.create(w);
If my w param is Monday (or monday), then no problem. If it's Friday,
then it throws an exception.
As I've mentionned, the testing I've done is limited. I figured that you
guys are probably setup with Junit and have all your tests setup.
If you like the idea and intend to use it, let me know and I'll try to
whip up a regexp version of it where (well you guessed it), the argument
could be validated against a regular expression.
Mike.
cli.zip
Description: Zip compressed data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly project.xml
jstrachan2002/12/10 00:58:43 Modified:jellyproject.xml Log: Patched to use Ant 1.5.1 for Peter Lynch's maven issues Revision ChangesPath 1.98 +1 -1 jakarta-commons-sandbox/jelly/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/project.xml,v retrieving revision 1.97 retrieving revision 1.98 diff -u -r1.97 -r1.98 --- project.xml 9 Dec 2002 15:18:26 - 1.97 +++ project.xml 10 Dec 2002 08:58:43 - 1.98 @@ -220,7 +220,7 @@ dependencies dependency idant/id - version1.5/version + version1.5.1/version /dependency dependency -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[jelly] switch/case
I think most folks tend to use 'break' with their switch/case statements, and probably have been bitten in the ass a lot due to a missing break. I'd vote for defaultly not falling through, but if you wanted to, add an explicit fall-through/ tag that'd set a fall-through flag to true and execute the following case and reset it back to false. Else, maybe a global attr on the switch fall-through=true or similar? -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14170] - ConvertUtils.convert(Object) doesn't use registered convertor
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14170 ConvertUtils.convert(Object) doesn't use registered convertor --- Additional Comments From [EMAIL PROTECTED] 2002-12-10 17:58 --- bit more to this than first met my eye... the basic idea is that ConvertUtils would perform conversions when getting properties as well as setting them. this would mean that the getXXXProperty methods in the BeanUtils class would allow custom conversions rather than the simple toString() call used at the moment. the existing convertor interface can be reused public object convert(java.lang.class type, java.lang.Object value) by passing in type String.class. whether existing convertor classes could be used for this all depends on how they were written. it seems likely that many won't work very well - and some, not at all. we can convert the ones in beanutils but not those created by users. at the moment, ConvertUtils only needs one register for convertors since it only converts property setters. if ConvertUtils is going to convert getters as well, the question arises whether two separate registers are needed, one for setters and one for getters. one register should be easier to use and should make a little more sense from a user perspective. without losing too much flexibility (so long as the convertors are well written). having only one register might cause problems with existing code. if the registered convertors don't behaviour reasonably when called to convert objects to string, then the existing code would break. anyone else have any thoughts...? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [general] documentation
why not ask on the user list as well? - robert On Tuesday, December 10, 2002, at 05:32 AM, Henri Yandell wrote: Anyone got any views on: http://www.flamefew.net/~hen/jakarta-tutorial.html A month back or so I got on a kick to write out the first chapter. [The others I put in as vague ideas for further information]. Last week I did a bit of reallocation and adding in new content, but it's now reached the point of show-n-tell. Do I want to bother etc. So any views? Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]. org For additional commands, e-mail: mailto:[EMAIL PROTECTED]. org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[collections] [patch] changes for ArrayListIterator was: Re: [collections] private member access in o.a.c.collections.iterators
The attached zip includes the following new classes:
- UnmodifiableArrayListIterator: provides a ListIterator impl over an
array. Does not support ListIterator#set, #add, or #remove. Extends
ArrayIterator (which does not support #add or #remove either).
- ArrayListIterator.java : Extends UnmodifiableArrayListIterator, and
supports #set.
- TestArrayListIterator.java : test cases, extends TestArrayIterator.
- TestArrayListIterator2.java : test cases, extends TestArrayIterator2.
And the following patches:
- ArrayIterator.patch : changes member access from private to
protected, and allows iteration over zero-length array sections.
- TestArrayIterator2.patch : replaces use of the ArrayIterator
constructor with a factory method, to allow subclassing by
TestArrayListIterator2. Also tests that zero-length iteration is
permitted (was prohibited).
- IteratorUtils.patch : added arrayListIterator(...) methods. Actually
they were already present but commented out, so it wasn't that much
work ;)
- TestAll.patch : included TestArrayListIterator and
TestArrayListIterator2 in test suite.
Enjoy ;)
- Neil
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
Go for it ;-)
Stephen
- Original Message -
From: Neil O'Toole [EMAIL PROTECTED]
To: Jakarta Commons Developers List
[EMAIL PROTECTED]
Sent: Friday, December 06, 2002 9:51 PM
Subject: Re: [collections] private member access in
o.a.c.collections.iterators
I've prepared a patch for ArrayIterator, and the ArrayListIterator
class is ready to go, with associated test cases. However, there is
another issue with ArrayIterator. The ArrayIterator(Object array,
int
start, int end) constructor has the following test:
if(end = start) {
throw new IllegalArgumentException(
My understanding is that this should really be changed to:
if(end start) {
The current behaviour prohibits the creation of an iterator over a
zero-length section of array, even though this is a valid thing to
do.
Unless there are objections, I will also include this change in the
patch. This will also require changes to TestArrayList, so I guess
I
can create a patch for this as well.
Any comments?
- Neil
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
Perhaps you would like to send a patch for ArrayIterator.
http://jakarta.apache.org/site/source.html#Patches
Also, an ArrayListIterator would be very welcome for the
iterators
package.
If you are writing it, perhaps you would consider submitting it
together
with the associated patch to IteratorUtils?
Thanks
Stephen
- Original Message -
From: Neil O'Toole [EMAIL PROTECTED]
I've been using the o.a.c.collections packages for a few
months,
and I
want to applaud you guys for some fantastic work.
I do have a question: forgive me if this has been discussed
before
(though I couldn't find it in the mail archive), but is there a
particular reason why the member variables in the
o.a.c.collections.iterators classes are private instead of
being
protected? In general, why would you want to do this, as it
prevents
subclassing? A particular case: I wanted to created an
ArrayListIterator that subclasses ArrayIterator and implements
the
ListIterator interface. With protected member access it is a
simple
and
elegant implementation to subclass ArrayIterator.
Thoughts on the matter?
- Neil O'Toole
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
commons-collections_patch_20021209.zip
Description: commons-collections_patch_20021209.zip
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
commons-fileupload
Dear commmons developers, Can someone in this mailing list tell me the expected release date for commons-fileupload 1.0? If this is not the right mailing list or address to send these kind of questions, which email addresses will be proper? Thanks Nan Xiong -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [modeler] removing deps ?
On Monday, December 9, 2002, at 10:38 PM, Costin Manolache wrote: robert burrell donkin wrote: snip the reflection code - on the other hand - has proved buggy and unstable. (the problem is that the reflection code in java 1.3 doesn't work very well.) I'm not sure what exactly you have in mind ( as problems with reflection ). getMethod (for example) doesn't work properly in java 1.3 JVMs (and possible others). this is (said to be) pretty much fixed in java 1.4. I'm familiar with the code in ant and tomcat - and I don't remeber any serious problem that would affect modeler. I plan to use one of those 2 - and most of the leg work is already done. the problems seem to arise when people start wanting to do slightly unusual things which are ok in compiled code. for example, public methods in a public subclass of a default access superclass can't be accessed when found by getMethod. (i can probably look up some more examples, if you like.) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/reflect MethodUtilsTestCase.java
rdonkin 2002/12/10 11:06:49
Modified:lang/src/java/org/apache/commons/lang/reflect
MethodUtils.java
lang/src/test/org/apache/commons/lang/reflect
MethodUtilsTestCase.java
Log:
Consolidated methods.
Revision ChangesPath
1.9 +111 -152
jakarta-commons/lang/src/java/org/apache/commons/lang/reflect/MethodUtils.java
Index: MethodUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/reflect/MethodUtils.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- MethodUtils.java 21 Nov 2002 19:38:51 - 1.8
+++ MethodUtils.java 10 Dec 2002 19:06:49 - 1.9
@@ -66,6 +66,7 @@
import org.apache.commons.lang.ArrayUtils;
import org.apache.commons.lang.StringUtils;
+
/**
* codeMethodUtils/code contains utility methods for working for
* methods by reflection.
@@ -126,6 +127,21 @@
* @throws IllegalArgumentException if the class or method name is null
* @throws ReflectionException if an error occurs during reflection
*/
+public static Method getMethod(Class cls, String methodName, Class paramType) {
+Class[] paramTypes = {paramType};
+return getMethod(cls, methodName, paramTypes);
+}
+
+/**
+ * Gets a Method by name. The method must be public.
+ * Superclasses will be considered.
+ *
+ * @param cls the class to reflect, must not be null
+ * @param methodName the field name to obtain
+ * @return the Method object
+ * @throws IllegalArgumentException if the class or method name is null
+ * @throws ReflectionException if an error occurs during reflection
+ */
public static Method getMethod(Class cls, String methodName, Class[]
paramTypes) {
return getMethod(cls, methodName, paramTypes, false);
}
@@ -173,7 +189,24 @@
}
throw new NoSuchMethodException(The method ' + methodName + '
could not be found);
} else {
-return cls.getMethod(methodName, paramTypes);
+// apply workarounds
+Method method = null;
+try {
+
+method = cls.getMethod(methodName, paramTypes);
+
+} catch(NoSuchMethodException e) {
+// swallow
+}
+
+if (method == null) {
+// use the same as beanutils for the moment
+Method[] compatibles = getCompatibleMethods(cls, methodName,
paramTypes);
+if (compatibles.length 0) {
+method = compatibles[0];
+}
+}
+return getMethod(method);
}
} catch (ReflectionException ex) {
@@ -186,6 +219,50 @@
ex, getting method, cls.getName(), null, methodName), ex);
}
}
+
+/**
+ * pReturn an accessible method (that is, one that can be invoked via
+ * reflection) that implements the specified Method. If no such method
+ * can be found, return codenull/code./p
+ *
+ * @param method The method that we wish to call
+ */
+public static Method getMethod(Method method) {
+
+Method accessibleMethod = getAccessibleMethod(method);
+if (accessibleMethod == null) {
+try {
+//
+// XXX Default access superclass workaround
+//
+// When a public class has a default access superclass
+// with public methods, these methods are accessible.
+// Calling them from compiled code works fine.
+//
+// Unfortunately, using reflection to invoke these methods
+// seems to (wrongly) to prevent access even when the method
+// modifer is public.
+//
+// The following workaround solves the problem but will only
+// work from sufficiently privilages code.
+//
+// Better workarounds would be greatfully accepted.
+//
+if (ReflectionUtils.isPublicScope(method)) {
+method.setAccessible(true);
+accessibleMethod = method;
+}
+
+} catch (SecurityException se) {
+// log but continue just in case the method.invoke works anyway
+log(
+Cannot setAccessible on method. Therefore cannot use jvm access
bug workaround.,
+
Re: [collections] [patch] changes for ArrayListIterator was: Re: [collections] private member access in o.a.c.collections.iterators
Also, I am very uncomfortable with ArrayListIterator being a subclass of UnmodifiableArrayListIterator. There is no 'is a' relationship here, and worse, if I declared a method to take in an UnmodifiableArrayListIterator it would accept a modifiable one which would probably not be what I want. I have seen this sort of thing done before. For example, in the JODA Time library, ReadableWritableInstant (mutable) extends ReadableInstant (immutable). :-) However, I agree with you in this case. Using the word unmodifiable implies that subclasses will be immutable, whereas readable only suggests that subclasses will be able to read its value. Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
Hi, here is a suggested addition to the collections component. This is a trivial FilterIterator which only returns objects of a given class. I attached the class with its associated test case. Hi Emmanuel Thanks for the contribution. If I've got this right, ClassFilterIterator alters the behaviour of FilterIterator to filter its objects by their class. In this case it feels to me that using a subclass might be a bit too heavy since ClassFilterIterator isn't really altering FilterIterator's behaviour, it is just supplying a default value for its predicate. In other words, instead of Iterator classFilterIterator = new ClassFilterIterator(iterator, String.class); why not Iterator classFilterIterator = new FilterIterator(iterator, new ClassPredicate(String.class)); To me, the second example seems like the easiest and most transparent way to filter classes by their class. Perhaps you could extract the inner class and submit that separately? (Although I'm not sure where you submit it: collections, lang or functors?) Actually, I've got one more comment. Not a biggie, but since I'm already here. :-) The constructor of ClassPredicate interprets a null value as equivalent to Object.class. It might be a good idea to shy away from default behaviour, and instead throw a NullPointerException. My rationale is this: if a developer wanted to get all classes they should use Object.class or an always-true Predicate or not filter the values at all. To me, all these approaches seem a lot clearer. Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] NodeCachingLinkedList serialization / license issues?
Also, I have some concerns about the code for NodeCachingLinkedList. It looks like a lot of the code has been copied from Sun's LinkedList implementation. If I understand correctly, this makes the code unsuitable for inclusion in an Apache project. I didn't know about these sorts of restrictions. I've looked around the Apache site and can't find any information on this-- you should've posted a link to whatever you were referring. Now, I have to say that Sun doesn't have a patent on the linked-list data structure, which is probably going to be implemented the same way over and over again if it adheres to the List interface. If I were to rewrite LinkedList, I would include an inner ListIterator class, etc. I would track modifications with a number variable at the class level. Would it make you feel better if I renamed variables? The point is that Java doesn't have a patent on the workings of any data structures in the Java language (and I've never seen a patent for a data structure anyway, although it would be possible to get one). They have copyrights on everything they release. Maybe we should investigate ASF's liability with regards to all code implementing interfaces or extending classes in the Java API. Maybe it would be good enough document things like this: /** implements the LinkedList(c) interface from Sun Microsystems, Inc. */ By the way, your trie implementation is sucky and guaranteed to be slow. Have a nice day. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Morpher] status of the project
Hi, I started to look at Morpher codebase in Jakarta CVS because it looks like something I'm currently looking for. First I'd like to ask, if there's any work on this (it looks like CVS is untouched since some months)? I also want to ask if anybody knows about 'morphers' outisde main Morpher CVS tree (maybe for text/xml+svs - image/* using Batik Transcoder API? Regards Tomek Pik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] NodeCachingLinkedList license issues?
Also, I have some concerns about the code for NodeCachingLinkedList. It looks like a lot of the code has been copied from Sun's LinkedList implementation. If I understand correctly, this makes the code unsuitable for inclusion in an Apache project. I didn't know about these sorts of restrictions. I've looked around the Apache site and can't find any information on this-- you should've posted a link to whatever you were referring. Now, I have to say that Sun doesn't have a patent on the linked-list data structure, which is probably going to be implemented the same way over and over again if it adheres to the List interface. If I were to rewrite LinkedList, I would include an inner ListIterator class, etc. I would track modifications with a number variable at the class level. Would it make you feel better if I renamed variables? The point is that Java doesn't have a patent on the workings of any data structures in the Java language (and I've never seen a patent for a data structure anyway, although it would be possible to get one). They have copyrights on everything they release. Maybe we should investigate ASF's liability with regards to all code implementing interfaces or extending classes in the Java API. Maybe it would be good enough document things like this: /** implements the LinkedList(c) interface from Sun Microsystems, Inc. */ By the way, your trie implementation is sucky and guaranteed to be slow. Have a nice day. Please don't take my comment as a personal attack--your implementation is good and I'm not sure if there is a legal problem here. I was just checking it past the list. My (layperson) understanding says that we should check it out carefully. Despite the fact that a linked list is a common data structure and despite the fact that we've got a license to use the API, I don't think we're allowed to redistribute the source code. Hopefully someone familiar with licensing issues can tell us whether there is anything to worry about. Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [CLI]: ParseException:Unrecognized option: -p
Hi Guillame, Yeap I agree with you, the user documentation on each parser needs to be improved. Unfortunately documentation is not my forté so any submissions on this front are most welcome :-) Cheers, -John K On Monday, Dec 9, 2002, at 10:23 Europe/Dublin, Guillaume Coté wrote: Hi, snip/ As I already mention in a previous email today, I think there is at least a documentation bug since the different behavior of each parser should be clearly explain in the javadoc. (If those difference are expected.) Well maybe the documentation just needs to be moved. Check out the links below for descriptions of what the flatten methods in each Parser do: [1]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/ cli/ GnuParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.Str ing[],%20boolean) [2]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/ cli/ PosixParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.S tring[],%20boolean) [3]http://jakarta.apache.org/commons/cli/apidocs/org/apache/commons/ cli/ BasicParser.html#flatten(org.apache.commons.cli.Options,%20java.lang.S tring[],%20boolean) I check the refered documentation. I still think there is a need for more documentation, or a different documentation. The method flatten is protected, so its documentation is intent for developper who need to overload it (and of course developper who write the class). Simple user of a parser should not have to understand the implementation of it to be able to use it. The documentation of the class and its public method should be enough for anybody to use it, and know which behavior expected from the class they are using. For example, I think the documentation of the PosixParser should clearly state : That class expect all short option to have a single character. Also, those all parser assume that a -- is a long option, or just the posix. -- Guillaume Coté [EMAIL PROTECTED] Tel. : +33.1.41.45.13.87 Fax. : +33.1.41.45.10.50 - - - - - - - - - - - - - - - - - - - - - - - Jakarta Commons CLI http://jakarta.apache.org/commons/cli -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Morpher] status of the project
Tomasz Pik wrote: Hi, I started to look at Morpher codebase in Jakarta CVS because it looks like something I'm currently looking for. First I'd like to ask, if there's any work on this (it looks like CVS is untouched since some months)? Currently it's not being actively developed, but the reasons why it started are still there and it's still needed. If you want to help-contribute, I'd be very happy :-) I also want to ask if anybody knows about 'morphers' outisde main Morpher CVS tree (maybe for text/xml+svs - image/* using Batik Transcoder API? No, there are not, but the Batik Transcoder is one of the systems that Morphos intends to use. In this way users could use Morphos as an API and underneath have Batik, Cocoon blocks, etc... Andrew C. Oliver (acoliver at apache.org) is very interested in it and wants to start developing on it too BTW. If you have further questions, don't hesitate to ask :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Jelly]Message tag for load string messages from resource
I just thought about this over in Mavenville and was just about to go ahead and implement it out of curiosity when I saw this thread. If someone else is working on it already then I'll cease and desist ;) Saimon Kelly Chen wrote: Sounds good. James Strachan wrote: From: Kelly Chen [EMAIL PROTECTED] Hi: I searched Jelly tag reference, I couldn't find a tag that is similiar to struts-bean:message tag which can load resource strings based on an id and locale. It can be very useful for using Jelly as a templating system that can be internationalized. In order to avoid duplicated work, I just wonder if it already exists and I simply missed it. Or is there a plan to add it in the future? AFAIK noone's attempted anything like this yet but it sounds like a good idea. Maybe implementing something like the i18n tags in JSTL might be nice idea? James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15257] New: - Hierarchy support in ToStringBuilder.reflectionToString()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15257. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15257 Hierarchy support in ToStringBuilder.reflectionToString() Summary: Hierarchy support in ToStringBuilder.reflectionToString() Product: Commons Version: 1.0.1 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I just discovered that the method ToStringBuilder.reflectionToString() does not work in a class hierarchy. For example: class A defines inst var a. class B extends A defines inst var b. new A().toString returns a=... new B().toString returns b=... when I expected new B().toString to return a=...,b=... Can I use reflectionToString() to accomplish this? Thank you for considering this request. Gary -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration project.xml
henning 2002/12/10 15:25:53 Modified:configuration project.xml Log: Make commons-configuration buildable on JDKs that don't include xerces and xml-apis (e.g. JDK 1.3.x). Add missing dependencies. Revision ChangesPath 1.12 +12 -0 jakarta-commons-sandbox/configuration/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/project.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- project.xml 3 Dec 2002 12:21:59 - 1.11 +++ project.xml 10 Dec 2002 23:25:53 - 1.12 @@ -105,6 +105,18 @@ version3.7/version urlhttp://www.junit.org/url /dependency + +dependency + idxerces/id + version2.0.2/version + urlhttp://xml.apache.org/xerces2-j//url +/dependency + +dependency + idxml-apis/id + version2.0.2/version + urlhttp://xml.apache.org/xerces2-j//url +/dependency /dependencies build -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/conf - New directory
henning 2002/12/10 15:36:25 jakarta-commons-sandbox/configuration/conf - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration .cvsignore
henning 2002/12/10 15:38:15 Modified:configuration .cvsignore Log: Ignore the result of the TestPropertiesConfiguration and the ant generated lib directory Revision ChangesPath 1.3 +2 -0 jakarta-commons-sandbox/configuration/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/.cvsignore,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- .cvsignore26 Nov 2002 00:29:36 - 1.2 +++ .cvsignore10 Dec 2002 23:38:15 - 1.3 @@ -5,3 +5,5 @@ test-reports velocity.log* maven.log +STRING0 +lib -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration TestPropertiesConfiguration.java include.properties test.properties
henning 2002/12/10 15:39:41
Modified:configuration/src/test/org/apache/commons/configuration
TestPropertiesConfiguration.java
Added: configuration/conf README include.properties test.properties
Removed: configuration/src/test/org/apache/commons/configuration
include.properties test.properties
Log:
Fix up the test case for the PropertiesConfiguration to actually work. :-)
Move the tested properties file from the test source tree into a conf
subdirectory.
commons-configuration should now build under maven and ant (gump).
Revision ChangesPath
1.1 jakarta-commons-sandbox/configuration/conf/README
Index: README
===
DO NOT DELETE THESE FILES!
They're used for testing the PropertiesLoader in
the TestPropertiesConfiguration class
1.1 jakarta-commons-sandbox/configuration/conf/include.properties
Index: include.properties
===
include.loaded = true
packages = packageb, packagec
1.1 jakarta-commons-sandbox/configuration/conf/test.properties
Index: test.properties
===
configuration.loaded = true
packages = packagea
include = include.properties
1.3 +36 -55
jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestPropertiesConfiguration.java
Index: TestPropertiesConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration/TestPropertiesConfiguration.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestPropertiesConfiguration.java 3 Dec 2002 14:03:54 - 1.2
+++ TestPropertiesConfiguration.java 10 Dec 2002 23:39:41 - 1.3
@@ -54,19 +54,26 @@
* http://www.apache.org/.
*/
-import junit.framework.*;
-import java.io.*;
+import java.io.File;
+import java.io.InputStream;
+
import java.util.Vector;
+import junit.framework.TestCase;
/**
- * test foir loading and saving properties files
+ * test for loading and saving properties files
*
* @author a href=mailto:[EMAIL PROTECTED];Martin Poeschl/a
+ * @author a href=mailto:[EMAIL PROTECTED];Henning P. Schmiedehausen/a
* @version $Id$
*/
-public class TestPropertiesConfiguration extends TestCase
+public class TestPropertiesConfiguration
+extends TestCase
{
+/** The File that we test with */
+private String testProperties =
+new File(conf/test.properties).getAbsolutePath();
public TestPropertiesConfiguration(String s)
{
@@ -74,64 +81,44 @@
}
public void testLoad()
+throws Exception
{
-PropertiesConfiguration conf = new PropertiesConfiguration();
-InputStream input = this.getClass().getResourceAsStream(
-/org/apache/commons/configuration/test.properties);
-try
-{
-conf.load(input);
-String loaded = conf.getString(configuration.loaded);
-assertEquals(true, loaded);
-}
-catch (Exception e)
-{
-System.err.println(Exception thrown: + e);
-}
+PropertiesConfiguration conf =
+new PropertiesConfiguration(testProperties);
+
+String loaded = conf.getString(configuration.loaded);
+assertEquals(true, loaded);
}
/**
- * test if includes properites get loaded too
+ * test if includes properties get loaded too
*/
public void testLoadInclude()
+throws Exception
{
-PropertiesConfiguration conf = new PropertiesConfiguration();
-InputStream input = this.getClass().getResourceAsStream(
-/org/apache/commons/configuration/test.properties);
-try
-{
-conf.load(input);
-String loaded = conf.getString(include.loaded);
-assertEquals(true, loaded);
-}
-catch (Exception e)
-{
-System.err.println(Exception thrown: + e);
-}
+PropertiesConfiguration conf =
+new PropertiesConfiguration(testProperties);
+
+String loaded = conf.getString(include.loaded);
+assertEquals(true, loaded);
}
/**
- * test if includes properites get loaded too
+ * test if includes properties get loaded too
*/
public void testVector()
+throws Exception
{
-PropertiesConfiguration conf = new
Re: [Collections] NodeCachingLinkedList license issues?
On Wed, 11 Dec 2002, Rich Dougherty wrote: Date: Wed, 11 Dec 2002 10:34:23 +1300 (NZDT) From: Rich Dougherty [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Collections] NodeCachingLinkedList license issues? Also, I have some concerns about the code for NodeCachingLinkedList. It looks like a lot of the code has been copied from Sun's LinkedList implementation. If I understand correctly, this makes the code unsuitable for inclusion in an Apache project. I didn't know about these sorts of restrictions. I've looked around the Apache site and can't find any information on this-- you should've posted a link to whatever you were referring. Now, I have to say that Sun doesn't have a patent on the linked-list data structure, which is probably going to be implemented the same way over and over again if it adheres to the List interface. If I were to rewrite LinkedList, I would include an inner ListIterator class, etc. I would track modifications with a number variable at the class level. Would it make you feel better if I renamed variables? The point is that Java doesn't have a patent on the workings of any data structures in the Java language (and I've never seen a patent for a data structure anyway, although it would be possible to get one). They have copyrights on everything they release. Maybe we should investigate ASF's liability with regards to all code implementing interfaces or extending classes in the Java API. Maybe it would be good enough document things like this: /** implements the LinkedList(c) interface from Sun Microsystems, Inc. */ By the way, your trie implementation is sucky and guaranteed to be slow. Have a nice day. Please don't take my comment as a personal attack--your implementation is good and I'm not sure if there is a legal problem here. I was just checking it past the list. My (layperson) understanding says that we should check it out carefully. Despite the fact that a linked list is a common data structure and despite the fact that we've got a license to use the API, I don't think we're allowed to redistribute the source code. Hopefully someone familiar with licensing issues can tell us whether there is anything to worry about. Implementing the java.util.LinkedList interface is perfectly legal. The fact that many linked list implementations will look similar to each other is the nature of the beast -- the question is, did you write it yourself or did you copy someone else's implementation? Copying code directly from some other implementation is restricted by the terms under which you acquired that source code (i.e. if you copy code from an Apache class into you're own, you have to obey the Apache license terms; same for Sun source code or anyone elses). In the case at hand, if the code was directly copied from Sun source code then it is Sun intellectual property, bound by the click-through license that you accepted when you downloaded it. Short answer: you can't do that. I have not checked the proposed code against the Sun sources, but this sounds like it would be a problematic contribution to me. Rich Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15016] - HttpMethodBase does not compile on JDK prior to 1.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15016. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15016 HttpMethodBase does not compile on JDK prior to 1.3 --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 03:41 --- Created an attachment (id=4122) Fix for this bug. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15082] - elapsed time formatting utility method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15082. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15082 elapsed time formatting utility method --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 03:52 --- Ahhh...didn't know this class existed. StopWatch looks like the right class/place for this functionality. I just looked at the source for it. I can see why the getTimeString method was originally not public - it's because it takes in a long parameter and just formats that instead of referring to the internal fields of the class. I don't think the public method should have a parameter. I also think that overriding the toString method is a little ambiguous. (I assume that was the intended public method before). I would suggest: public static long getTime()(as-is) public static String getTimeString()(no parameters. this should then call a private formatTimeString method that accesses the internal fields.) That would eliminate the privacy issues while keeping the API clear, IMHO. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15170] - BeanUtils.setProperty doesn't convert primitive wrappers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170 BeanUtils.setProperty doesn't convert primitive wrappers [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 06:17 --- Rodney, Thanks for committing the converter code and adding the testcase. Unfortunately, these fixes do not address the bug I reported here. This bug only occurs when attempting to set a String property using a number wrapped in a primitive wrapper class. In order to illustrate this behavior, add the following lines to the new testcase testSetPropertyOnPrimitavieWrappers() [sic]: BeanUtils.setProperty(bean,stringProperty, new Integer(1)); assertEquals(1,Integer.parseInt(bean.getStringProperty())); (i.e. set a String property instead of an int property.) In this case, the ConvertUtils code is never called. The if block beginning around line 901 (comment: Value into scalar) maps this case to the final else case, which will attempt to set the property using the wrapper class (which will fail). I believe you need to add another check for primitive wrapper classes (or perhaps something more generic like testing the existence of a suitable converter), as I did in my suggested patch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15192] - Property Descriptor Utility Cache needs a way to clear it.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15192 Property Descriptor Utility Cache needs a way to clear it. [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |commons- |[EMAIL PROTECTED] |[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15170] - BeanUtils.setProperty doesn't convert primitive wrappers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170 BeanUtils.setProperty doesn't convert primitive wrappers --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 06:46 --- Created an attachment (id=4124) Patch to BeanUtilsTestCase that better illustrates this bug -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15170] - BeanUtils.setProperty doesn't convert primitive wrappers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170 BeanUtils.setProperty doesn't convert primitive wrappers --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 06:47 --- Created an attachment (id=4125) Slightly more elegant patch for this defect -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Jelly] JellyServlet
James,
On Mon, 9 Dec 2002 15:18:21 -, James Strachan said:
Thanks for the patch Kelvin, I've committed it to CVS.
I made a minor patch so that the URI itself could denote the script
to run.
So you could just run http://localhost:8080/foo/index.jelly for
example, rather than requiring a template=index.jelly query
parameter..
That's nice. I have changed the parameter template to script. Its
just that I'm so used to using Velocity. The patch you made uses
getServletPath, which returns the url of the servlet being called.
I've changed it to getPathInfo.
Another thing. Is it really appropriate to require all scripts to be
located beneath the web app's context root (which getResource does)?
The previous impl using new File(script).getUrl had no such
limitation...
Some thoughts for further improvement could be...
* implement a JellyServletContext so that the getResource() method
will use the ServletContext.getResource() method and allow access of
relative URIs when performing j:include's.
done.
* have a parent JellyServletContext to allow access to the
initParams of the ServletContext via variable expressions
?
* implement the JSTL mappings of request parameters, session
parameters, cookies etc in the expression language.
* it'd be nice to have a cache of Jelly Scripts to avoid parsing
them each time! :-)
Here's something which is a little surprise. So it means Jelly is not
internally caching scripts? This has some implications for usage of
Jelly as a templating subsystem for high-load systems, I imagine.
In any event, perhaps it would be a better idea to cache at the
engine level, rather than the servlet level, no?
See attached for patch to JellyServlet and JellyServletContext.
Regards,
Kelvin
The book giving manifesto - http://how.to/sharethisbook
JellyServletContext.java
Description: Binary data
cvs -z9 diff JellyServlet.java (in directory
C:\checkout\jakarta-commons-sandbox\jelly\src\java\org\apache\commons\jelly\servlet\)
Index: JellyServlet.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java,v
retrieving revision 1.1
diff -r1.1 JellyServlet.java
2c2
* $Header:
/home/cvspublic/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java,v
1.1 2002/12/09 15:18:26 jstrachan Exp $
---
* $Header:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java,v
1.1 2002/12/09 15:18:26 jstrachan Exp $
59c59
*
---
*
65d64
import java.io.File;
84,85c83,84
*
* @author Kelvin Tan
---
*
* @author a href=mailto:[EMAIL PROTECTED];Kelvin Tan/a
99c98
protected void doGet(
---
protected void doGet(
103c102
---
111c110
---
124c123
---
126d124
URL template = getTemplate(req);
128c126,127
runScript(template, context, req, res);
---
URL script = getScript(req);
runScript(script, context, req, res);
144,145c143,144
JellyContext ctx = new JellyContext();
---
JellyContext ctx = new JellyServletContext(getServletContext());
151a151,158
* p
* Either use the query parameter script, or the URI itself
* to denote the script to run.
* /p
* p
* Example: script=index.jelly or http://localhost:8080/foo/index.jelly.
* /p
*
157c164
protected URL getTemplate(HttpServletRequest req)
---
protected URL getScript(HttpServletRequest req)
159,162c166,169
String script = req.getParameter(template);
if (script == null) {
script = req.getServletPath();
---
String scriptUrl = req.getParameter(script);
if (scriptUrl == null) {
scriptUrl = req.getPathInfo();
164c171,175
return getServletContext().getResource(script);
---
URL url = getServletContext().getResource(scriptUrl);
if (url == null) {
throw new IllegalArgumentException(Invalid script url: + scriptUrl);
}
return url;
183c194
---
208c219
---
213c224
html.append(h2JellyServlet : Error processing the template/h2);
---
html.append(h2JellyServlet : Error processing the script/h2);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[jelly] code style
James, Any chance of code style guidelines for jelly? I noticed you reformatted JellyServlet. If you use idea, maybe you can post checkin the xml config file for codestyles... Regards, Kelvin The book giving manifesto - http://how.to/sharethisbook -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] code style
Any chance of code style guidelines for jelly? I noticed you reformatted JellyServlet. If you use idea, maybe you can post checkin the xml config file for codestyles... I think he tends to follow the Sun Coding Conventions, much to the irritation of those of us following the more sane Turbine-esque conventions, or the perfectly rationalized Werken flavour. Either way, I think checkstyle should alert you to any violations. -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] code style
On Wed, 11 Dec 2002 01:57:35 -0500 (EST), bob mcwhirter said: Any chance of code style guidelines for jelly? I noticed you reformatted JellyServlet. If you use idea, maybe you can post checkin the xml config file for codestyles... I think he tends to follow the Sun Coding Conventions, much to the irritation of those of us following the more sane Turbine-esque conventions, or the perfectly rationalized Werken flavour. +1. But lets not go down this slippery slope. :-) Either way, I think checkstyle should alert you to any violations. Not familiar with this. I use Maven to perform the check, I suppose? I saw a couple of declarations in project.properties... # use Sun coding standards maven.checkstyle.lcurly.type = eol maven.checkstyle.lcurly.method = eol maven.checkstyle.lcurly.other = eol #maven.checkstyle.header.file = src/conf/checkstyle-LICENSE.txt maven.checkstyle.header.ignore.line = 1,2,3,4,5,6 maven.checkstyle.const.pattern = ^[a-z][a-zA-Z0-9]*$ # disable these non-critical errors to highlight # more important ones line missing javadoc maven.checkstyle.max.line.len = 100 maven.checkstyle.ignore.whitespace = true maven.checkstyle.ignore.public.in.interface = true -bob -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] code style
Either way, I think checkstyle should alert you to any violations. Not familiar with this. I use Maven to perform the check, I suppose? I saw a couple of declarations in project.properties... maven checkstyle xdoc:transform That'll generate the checkstyle report for you. maven site:generate will generate the whole site, including test reports, style reports, metrics, code coverage, etc. Always a good thing to do. -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
