[modeler] removing deps ?

It would be reasonably easy to remove the deps of modeler on digester ( use DOM or SAX directly instead ) and beanutils ( we use only a a very small piece ). Our use of introspection will not be exposed to the user and we have some very specific requirements ( as mandated by the spec ), so there

cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie - New directory

jsdever 2002/12/07 22:02:15 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/converters package.html

craigmcc2002/12/07 15:34:41 Modified:beanutils/src/java/org/apache/commons/beanutils BeanComparator.java ResultSetDynaClass.java beanutils/src/java/org/apache/commons/beanutils/converters package.html beanutils

DO NOT REPLY [Bug 15160] - speedup for beanutils / array getter

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

Re: [core] Scope, you choose!

On Sat, 7 Dec 2002, Henri Yandell wrote: > > One potential criteria for the zipped Commons distro would be that it must > not be dependent on external jars, ie) the distro is entirely > self-cohesive. > Wouldn't this restrict us to include only Commons components that do not depend on things th

cvs commit: jakarta-commons/lang default.properties project.xml

bayard 2002/12/07 13:52:19 Modified:lang default.properties project.xml Log: Updated version from 1.0 to 1.1-dev. Revision ChangesPath 1.8 +2 -1 jakarta-commons/lang/default.properties Index: default.properties ==

cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang StringUtilsTest.java

bayard 2002/12/07 13:50:30 Modified:lang STATUS.html lang/src/java/org/apache/commons/lang StringUtils.java lang/src/test/org/apache/commons/lang StringUtilsTest.java Log: Added the StringUtils.unescape method, UnitTest and STATUS change. Revis

Re: [beanutils] moving reflection classes out of beanutils

On Fri, 6 Dec 2002, Costin Manolache wrote: > Craig R. McClanahan wrote: > > I don't know. > > this kind of stuff. > > If the [reflect] package will have the same features and better API - > then it may be better to mark beanutils as "stable"/"closed" and > migrate modeler, digester, etc directl

Re: [beanutils] moving reflection classes out of beanutils

On Sat, 7 Dec 2002, robert burrell donkin wrote: > On Saturday, December 7, 2002, at 08:57 PM, Henri Yandell wrote: > > > java.lang.reflect :) The proposal, nice and umbrella-like as it is, refers > > to anything that provides Utils for the java.lang.reflect classes. > > yep. the reflection clas

Re: [beanutils] moving reflection classes out of beanutils

On Saturday, December 7, 2002, at 08:57 PM, Henri Yandell wrote: On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: ... BTW. I agree that the [lang] charter would need to be reworked to clarify the inclusion of 'reflection'. "This proposal is to create a package of Java utility classes for the class

Re: [beanutils] moving reflection classes out of beanutils

On Fri, 6 Dec 2002, Costin Manolache wrote: > robert burrell donkin wrote: > > > what we have is clear duplication. twice the support and twice the > > maintenance. > > Nobody asks you to support 2 versions. There is nothing wrong with > duplication ( at least in commons ). You can just maintain

DO NOT REPLY [Bug 15160] - speedup for beanutils / array getter

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

DO NOT REPLY [Bug 15160] New: - speedup for beanutils / array getter

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

[GUMP] Build Failure - commons-email

This email is autogenerated from the output from: Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/rubys/jakart

[GUMP] Build Failure - commons-jelly

This email is autogenerated from the output from: Buildfile: build.xml init: [mkdir] Created dir: /home/rubys/jakarta/jak

Re: [beanutils] moving reflection classes out of beanutils

On Saturday, December 7, 2002, at 06:59 AM, Costin Manolache wrote: Craig R. McClanahan wrote: It doesn't quite matter. There are people using it ( digester, other projects), it was released - we have to live with it. We may learn a lesson about APIs and use it next time, but as long as it doe

Re: [beanutils] moving reflection classes out of beanutils

On Friday, December 6, 2002, at 06:53 PM, Costin Manolache wrote: robert burrell donkin wrote: the guidelines have an inbuilt mechanism whereby components may - if they wish - prevent a new existing commons committer joining. that is, they can veto the addition of the committers name to the li

Re: [beanutils] moving reflection classes out of beanutils

On Friday, December 6, 2002, at 06:51 PM, Costin Manolache wrote: [EMAIL PROTECTED] wrote: from:Jeff Robertson <[EMAIL PROTECTED]> From: Rodney Waldhoff [mailto:[EMAIL PROTECTED]] Costin> If duplication is a concern - then just use Costin> beanutils ( however duplication is explicitely

Re: [VOTE] moving Jelly to the commons proper

On Friday, December 6, 2002, at 02:13 PM, James Strachan wrote: - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [X] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote agai

[beanutils] statics [WAS Re: [digester] collections and default for useThreadClassLoader]

On Saturday, December 7, 2002, at 06:50 AM, Costin Manolache wrote: There is also the issue of statics ( which become very visible when you move stuff to the top loader), and the issue of security - which is particularily important for beanutil and probably in collections ( i.e. - if things are

RE: [Collections] [SUBMIT] Trie

I should explain usage of Trie (specially case binary Patricia): Storage requirement - Minimal (good balance between storage and performance) Functionality - Exact match (it is usual case), Prefix Match, Some kind of flexible expressions may be used as key For a long strings even Exact match is mu

RE: [Collections] [SUBMIT] Trie

Charles, You are 100% right. It depends on application. For such applications as billing in telecomunications it is enough to use object-based storage of elements (with some optimizations like converting UNICODE String to the BDC string). For text retrieving DBMS indexes primitive data structures a