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

jsdever 2003/02/07 17:12:15 Modified:httpclient/src/java/org/apache/commons/httpclient HttpConnection.java HttpMethodBase.java Log: Fix for bug 16846 Bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16864 changeLog: - now requires the a "\r\n

Re: [CLI] char versus String for option name?

I've updated the class diagram again. This is a 'char as Option name' free zone ;) This results in a much cleaner API and a much nicer class hierarchy. I would be in favour of this approach. It would of course involve the user having to change the code. I am going to implement an XML->Java co

[BeanUtils] Adding ConverterSet

I am using BeanUtils.copyProperties(Object dest, Object orig) to copy from my "view" beans to my dto beans, and vica versa. I find that I need to apply slightly different rules based on which direction I am going. I would like to add the idea of a "ConverterSet" to beanutils, and plan on passi

Re: [logging] To depend or not to depend?

Craig R. McClanahan wrote: On Fri, 7 Feb 2003, Ryan Hoegg wrote: Starting a new thread for this, it really has little to do with CLI. We are having a similar dilemma in XML-RPC. The idea of a SafeCommonsLogger seems sound. It could even end up in a commons-stub package. It would do nothing

Re: [jexl] I assume that the build.xml came from maven?

Does jexl support div/mod? My experiments suggest not. Or would you consider them not working to be a bug? -bob On Fri, 7 Feb 2003, Geir Magnusson Jr. wrote: > Suggestion - might be nice to have a header in it, something like : > > > > or something. > > I guess that I should jus

Re: [logging] To depend or not to depend?

On Fri, 7 Feb 2003, Ryan Hoegg wrote: > Date: Fri, 07 Feb 2003 16:49:15 -0500 > From: Ryan Hoegg <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [logging] To depend or not to depend? > > Starting a new thread for this, it rea

[jexl] I assume that the build.xml came from maven?

Suggestion - might be nice to have a header in it, something like : or something. I guess that I should just go suggest that in maven-land Working on fixing the failing test cases. geir -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc.

Re: [CLI] new design possibly?

On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: > Date: Fri, 07 Feb 2003 23:03:00 +0100 > From: Nicola Ken Barozzi <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [CLI] new design possibly? > > > > Craig R. McClanahan wrote

Re: [jexl] commons website

On Thursday, February 6, 2003, at 01:49 PM, robert burrell donkin wrote: On Thursday, February 6, 2003, at 03:29 AM, Geir Magnusson Jr. wrote: On Wednesday, February 5, 2003, at 02:51 PM, robert burrell donkin wrote: i've updated the website. or downdated :) Can we either keep it the wa

Re: [CLI] new design possibly?

Craig R. McClanahan wrote, On 07/02/2003 22.45: On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: Date: Fri, 07 Feb 2003 22:28:24 +0100 From: Nicola Ken Barozzi <[EMAIL PROTECTED]> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [CLI] new design p

Re: [logging] To depend or not to depend?

Commons-logging-api.jar is 16K, which would increase our applet JAR size by 60+%. That's not acceptable for a system level service like logging. -- Ryan Hoegg Henri Yandell wrote: Why not just put SafeCommonsLogger in commons-logger.jar? Is commons-logging.jar's 20 odd K isn't that huge. Als

Re: [CLI] new design possibly?

Henri Yandell wrote, On 07/02/2003 22.39: On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: Henri Yandell wrote, On 07/02/2003 17.32: I don't see how this can work without ensuring that another package, commons-stub is in the classpath. I know I'm definitely not going to copy and paste pieces

Re: [logging] To depend or not to depend?

Why not just put SafeCommonsLogger in commons-logger.jar? Is commons-logging.jar's 20 odd K isn't that huge. Also, commons-logging could move the implementations out into commons-logging-impl.jar, or even one per underlying logging framework to make that 25K smaller. Hen On Fri, 7 Feb 2003, Ry

[logging] To depend or not to depend?

Starting a new thread for this, it really has little to do with CLI. We are having a similar dilemma in XML-RPC. The idea of a SafeCommonsLogger seems sound. It could even end up in a commons-stub package. It would do nothing if commons-logging-api.jar or commons-logging.jar is not in the CL

Re: [CLI] new design possibly?

On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: > Date: Fri, 07 Feb 2003 22:28:24 +0100 > From: Nicola Ken Barozzi <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [CLI] new design possibly? > > > Craig R. McClanahan wrote,

Re: [CLI] new design possibly?

On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: > > > Henri Yandell wrote, On 07/02/2003 17.32: > > > > I don't see how this can work without ensuring that another package, > > commons-stub is in the classpath. I know I'm definitely not going to copy > > and paste pieces of code from library to li

RE: [EL] instanceof

On Fri, 7 Feb 2003, O'brien, Tim wrote: > Date: Fri, 7 Feb 2003 15:27:26 -0600 > From: "O'brien, Tim" <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: 'Jakarta Commons Developers List' <[EMAIL PROTECTED]> > Subject: RE: [EL] instanceof > > > I meant to re

Re: [CLI] new design possibly?

Craig R. McClanahan wrote, On 07/02/2003 18.23: On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: Looks like an AOP-like system to intercept all logs of a package could help, but I'm lost here. If you implement your own LogFactory, this is pretty straightforward, since it is your LogFactory in

RE: [EL] instanceof

On Fri, 7 Feb 2003, O'brien, Tim wrote: > > I imagine EL will not be able to implement it until it is in > > the JSP 2.0 specification as, as far as I know, commons-el is > > the EL component of the JSP 2.0 spec. > > > > But I could be utterly wrong :) > > I understand that it is dependent on a

RE: [EL] instanceof

> I meant to reply to this on Taglibs earlier. > > I imagine EL will not be able to implement it until it is in > the JSP 2.0 specification as, as far as I know, commons-el is > the EL component of the JSP 2.0 spec. > > But I could be utterly wrong :) I think you are right, I'm just curious.

Re: [CLI] new design possibly?

Henri Yandell wrote, On 07/02/2003 17.32: On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: Speaking as a potential user of commons-logging to your suggestions: Look, I have some requirements that I'd like to be addressed somehow, let's see if you can help me. 1) a library should be able to wo

cvs commit: jakarta-commons-sandbox/daemon/src/native/nt/procrun procrunw.dev

mturk 2003/02/07 11:07:28 Added: daemon/src/native/nt/procrun procrunw.dev Log: DevC++ project file for WINAPP mode. Revision ChangesPath 1.1 jakarta-commons-sandbox/daemon/src/native/nt/procrun/procrunw.dev Index: procrunw.dev ===

cvs commit: jakarta-commons-sandbox/daemon/src/native/nt/procrun/bin procrunw.exe procrun.exe

mturk 2003/02/07 10:57:42 Modified:daemon/src/native/nt/procrun/bin procrunw.exe procrun.exe Log: Latest compile... Revision ChangesPath 1.2 +78 -79 jakarta-commons-sandbox/daemon/src/native/nt/procrun/bin/procrunw.exe <> 1.2 +72 -75

cvs commit: jakarta-commons-sandbox/daemon/src/native/nt/procrun readme.txt procrun.h procrun.c

mturk 2003/02/07 10:56:33 Modified:daemon/src/native/nt/procrun readme.txt procrun.h procrun.c Log: Added --User and --Password to enable to run the redirected process under other account. Revision ChangesPath 1.2 +7 -0 jakarta-commons-sandbox/daemon/src/na

Re: [latka] ways to handle common tests

I write my Latka tests as Jelly file and then run them in order using somthing like this: I'm assuming that something like that would work for what you want to do. -Kurt On Fri, 7 Feb 2003, Richard Dallaway wrote: > Does anyone have any ideas on good ways to handle units of common t

Re: [latka] ways to handle common tests

Hi Richard, > Does anyone have any ideas on good ways to handle units of common test > code in Latka? > > For example: login to an application. You may need to have a test user > log in to an application before running certain tests, and it would be > good to be able to code this common HTTP req

Re: [CLI] new design possibly?

On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: > > Looks like an AOP-like system to intercept all logs of a package could > help, but I'm lost here. > If you implement your own LogFactory, this is pretty straightforward, since it is your LogFactory instance that creates all the Log instances (ev

cvs commit: jakarta-commons/jelly/src/script makeTagDoc.jelly

jstrachan2003/02/07 09:16:38 Modified:jellymaven.xml project.xml Removed: jelly/src/java/org/apache/commons/jelly/util TagXMLDoclet.java XMLDoclet.java jelly/src/script makeTagDoc.jelly Log: removed the old doclet for generating docume

DO NOT REPLY [Bug 16875] - BeanUtils.populate does not skip zero lenght String

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 16876] - BeanUtils.populate does not skip zero lenght String

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 16875] - BeanUtils.populate does not skip zero lenght String

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: [JXPath] Problem adding objects to an ArrayList Variable

Adam, --- Adam J Chesney <[EMAIL PROTECTED]> wrote: > Dimitri, > > > > > > I think it might be a show stopper for me. I am almost certainly > trying > to > > > use JXPath in a way that was not intended. I am trying to build a > 2 way > > data > > > binding mapping structure which I think JXPath

Re: cvs commit: jakarta-commons-sandbox/configuration/src/test/org/apache/commons/configuration TestBaseConfiguration.java

[EMAIL PROTECTED] writes: > === > RCS file: /home/cvs/jakarta-commons-sandbox/configuration/project.xml,v > retrieving revision 1.20 > retrieving revision 1.21 > diff -u -r1.20 -r1.21 > --- project.xml 14 Jan 2003 03:53:12

[Jelly] BCEL taglibrary

Jelly Folks, Looks like theres alot of activity on the list with the "Big Move". I've made considerable progress on the BCEL taglibrary and the use of BSF to create enterpreted methods. For example: test1+test2; Returns: ${testExample3.testMethod(1,2)} It uses the BCEL libraries

Re: [CLI] new design possibly?

On Fri, 7 Feb 2003, Nicola Ken Barozzi wrote: Speaking as a potential user of commons-logging to your suggestions: > Look, I have some requirements that I'd like to be addressed somehow, > let's see if you can help me. > > 1) a library should be able to work even without commons-logging > i

Re: [CLI] new design possibly?

I've snipped quite some stuff, trying to remain focused. James Strachan wrote, On 06/02/2003 16.42: From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> James Strachan wrote, On 06/02/2003 12.32: ... digester uses an IOC approach to logging, take a look at the setLogger(Log) method http://jakart

Re: [latka] ways to handle common tests

My company has a large body of common tests, and we declare those tests via a DTD. I don't think it's a hack, it's just XML. :) - Morgan --- Richard Dallaway <[EMAIL PROTECTED]> wrote: > Does anyone have any ideas on good ways to handle > units of common test > code in Latka? > > For example:

Re: [JXPath] Problem adding objects to an ArrayList Variable

Dimitri, > > Hmmm. This seems a bit strange to me. It works for Maps (using put instead > > of add). > Sure, a Map is not a Collection. > Good point. :) > > So you can see that the Map is mutable. I'm not sure how difficult it is > to > > allow for mutable Lists, but if I can't do things like:

Re: [Graph2] nsUML license problem

David, Can you have a look at http://www.eclipse.org/emf/. It has an XMIReader and is CPL, but I don't have a clue what the code does in graph, Even though it is an eclipse plugin, the design could be that good that it is usable.. Mvgr, Martin On Wed, 2003-02-05 at 20:11, David Dixon-Peugh wrot

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

jsdever 2003/02/07 06:38:02 Modified:httpclient/src/java/org/apache/commons/httpclient/util Base64.java httpclient/src/test/org/apache/commons/httpclient TestBase64.java Log: Deprecate the Base64 class and its tests. Th

Re: [JXPath] Problem adding objects to an ArrayList Variable

Adam, > Hi Dimitri, > > Hmmm. This seems a bit strange to me. It works for Maps (using put instead > of add). Sure, a Map is not a Collection. > If I change the context definition to this: > > Object o = new Object (); > JXPathContext context = JXPathContext.newContext( o ); > context.getVaria

cvs commit: jakarta-commons/jelly/jelly-tags/jetty project.xml

jstrachan2003/02/07 05:31:54 Modified:jelly/jelly-tags/jetty project.xml Log: patched the dependencies so that unit tests run - though note that you have to manually download the Sun jars yourself Revision ChangesPath 1.12 +11 -0 jakarta-commons/jelly/jelly-tags

DO NOT REPLY [Bug 16880] New: - Language specs violation in Commons Logging 1.0.2 in class LogFactoryImpl

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

cvs commit: jakarta-commons/jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt ImageTag.java SwtTagLibrary.java

jstrachan2003/02/07 04:53:55 Modified:jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt SwtTagLibrary.java Added: jelly/jelly-tags/swt/src/java/org/apache/commons/jelly/tags/swt ImageTag.java Log: Applied patch sup

DO NOT REPLY [Bug 16876] New: - BeanUtils.populate does not skip zero lenght String

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 16875] New: - BeanUtils.populate does not skip zero lenght String

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

[latka] ways to handle common tests

Does anyone have any ideas on good ways to handle units of common test code in Latka? For example: login to an application. You may need to have a test user log in to an application before running certain tests, and it would be good to be able to code this common HTTP request in just one place

DO NOT REPLY [Bug 16873] New: - Specifying a different latka.properties file

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-jelly-tags-html

This email is autogenerated from the output from: Buildfile: build.xml init: get-deps: compile: compile-tests:

[GUMP] Build Failure - commons-codec

This email is autogenerated from the output from: <http://cvs.apache.org/builds/gump/2003-02-07/commons-codec.html> Buildfile: build.xml init: [echo] commons-codec 20

Re: [JXPath] Problem adding objects to an ArrayList Variable

Hi Dimitri, Hmmm. This seems a bit strange to me. It works for Maps (using put instead of add). If I change the context definition to this: Object o = new Object (); JXPathContext context = JXPathContext.newContext( o ); context.getVariables().declareVariable("myList", new ArrayList() ); cont

cvs commit: jakarta-commons/jelly project.xml

jstrachan2003/02/07 02:09:04 Modified:jellyproject.xml Log: updated the descriptor to point to commons proper and tidied up the dependencies some Revision ChangesPath 1.124 +10 -25jakarta-commons/jelly/project.xml Index: project.xml

cvs commit: jakarta-commons-sandbox/daemon/src/native/nt/procrun procrun.c

mturk 2003/02/07 01:58:48 Modified:daemon/src/native/nt/procrun procrun.c Log: 1. Added CLOSE and SHUTDOWN Console Events 2. Fixed bug in parsing -Java java 3. Added prety displaying of Service description for //TS// as console title Revision ChangesPath 1.2 +

cvs commit: jakarta-commons/jelly project.xml

mvdb2003/02/07 01:58:19 Modified:jellyproject.xml Log: Jelly is no longer sandbox :) Revision ChangesPath 1.123 +1 -1 jakarta-commons/jelly/project.xml Index: project.xml === RCS fil

cvs commit: jakarta-commons/jelly/xdocs overview.xml

jstrachan2003/02/07 01:54:30 Modified:jelly/xdocs overview.xml Log: patched whitespace issue Revision ChangesPath 1.9 +4 -2 jakarta-commons/jelly/xdocs/overview.xml Index: overview.xml ===