DO NOT REPLY [Bug 20813] - [FileUpload] does not take 'charset' parameter of the 'Content-Type' header into consideration
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=20813. 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=20813 [FileUpload] does not take 'charset' parameter of the 'Content-Type' header into consideration --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 09:03 --- Martin, I'll do so. Just give me a couple of days. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HiveMind] Re: Alternative module descriptors
Peanut gallery here. ;-) Every web app already has XML parsing and manipulation available to it. Adding a scripting language interpreter as well seems a bit heavyweight to me. This is from out of left field since I haven't yet worked with Hivemind, but perhaps if there was a pure Java API for setting up the configuration, people could do it in any way that they wanted (Jython, Groovy, whatever). Maybe there could be some type of JavaBean hierarchy representing the different services and extension points, etc. The XML configuration method could remain as a sensible default. One of the main ideas of HiveMind and other IOC Frameworks is that they try to be nonintrusive. Neither your services nor the configuration classes need to know anything about the framework that is used to set them up (in most cases). If you did things right you can use pure Java or a scripting language for setting up your system without any changes. All you need to start would be a central registry for managing and keeping the service instances (lets call it HashMap ;-) ). If you take away the xml part of hivemind you will probably get ... a different framework. Achim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Release Candidate Build of Commons Logging 1.0.4 Available
This might have been brought up before. It's about the dateformat used in SimpleLog. Currently SimpleLog uses /MM/dd, but the ISO 8601 standard, which is spreading rapidly, has this format -MM-dd. On the other hand, changing a thing like this might be concidered breaking backwards compatibility. -- Dennis Lundberg Craig R. McClanahan wrote: As has been discussed earlier on COMMONS-DEV, here is a pointer to a release candidate version of Commons Logging 1.0.4. All outstanding Bugzilla issues have been addressed and, barring any difficulties with this bundle, I plan on proposing a vote for a 1.0.4 release this coming week. The embedded RELEASE-NOTES.txt file documents the changes from the 1.0.3 release. http://cvs.apache.org/~craigmcc/commons-logging-1.0.4-rc1.zip Please help ensure the quality of this release by downloading the candidate bundle and making sure that it works correctly with your existing applications that use commons-logging. Craig McClanahan PS: As required by the Apache Software Fondation board, this release will be made under the new Apache License, version 2.0. - 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: [Hivemind] build hivemind in eclipse?
That's the version I'm using. +1 to losing maven! Geoff - Original Message - From: Howard M. Lewis Ship [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Sunday, March 07, 2004 9:18 AM Subject: RE: [Hivemind] build hivemind in eclipse? This is why we're going to get away from Maven. The exact version of Maven you have seems very significant. All I can say is that I'm using 1.0-rc2-SNAPSHOT. Does that help? Maybe not. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com -Original Message- From: Geoff Longman [mailto:[EMAIL PROTECTED] Sent: Saturday, March 06, 2004 11:27 PM To: [EMAIL PROTECTED] Subject: [Hivemind] build hivemind in eclipse? I got the missing MAVEN_REPO classpath variable errors so I installed maven and ran maven full-site and added the MAVEN_REPO classpath variable. All the errors are gone except this one: Error Missing required library: 'C:Documents and Settings/Administrator/.maven/repository/jboss/jars/jboss-jmx- 3.0.6.jar'. Although, the maven build did tank after a while with this: + | Generating site for HiveMind Framework | Memory: 12M/13M + BUILD FAILED File.. file:/C:/Documents and Settings/Administrator/.maven/plugins/maven-multiproject-plugin-1.1/ Element... maven:reactor Line.. 69 Column 7 Unable to obtain goal [site] -- file:/C:/Documents and Settings/Administrator/.maven/plugins/maven-site-plugin-1.3/:22:42: attainGo al Goal [xdoc:register-reports] has no action definition. Total time: 46 seconds Finished at: Sat Mar 06 22:47:33 EST 2004 What am I doing wrong? BTW I just pulled the latest code out of CVS and got the same error. Geoff - Original Message - From: Geoff Longman [EMAIL PROTECTED] To: Tapestry development [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 06, 2004 10:27 PM Subject: Re: [Hivemind] Tapestry/HttpSession service Ahh, but we're trying to reduce our dependency on the Visit. We have many groups of pages, and each group needs to store a distinct set of data. Our visit class was becoming a mess. Plus, a session local service could also be useful outside of Tapestry where there is no Visit! No reason why a JSP couldn't use a session local service. Geoff - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Tapestry development [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 06, 2004 10:14 PM Subject: Re: [Hivemind] Tapestry/HttpSession service The way I see it, you simply need a regular service with ThreadLocalStorage. The servlet filter would set the visit in the ThreadLocalStorage for every request and the service would simply get and set the data on the visit in the ThreadLocal. Would that work? -Harish Geoff Longman wrote: Perhaps, I wish I had more time to read the Hivemind source. I might be getting this wrong but how about a Factory that makes a session local instance of a service? Wait that can't be right. A SessionLocalService that pulls a service from a pool and hooks it up to the session. The existing servlet filter could be a model for a filter that sets up the SessionLocalService with the thread local session. The above ignores the need to restore/save a service's session local state though. hmm, still thinking.. Geoff - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Tapestry development [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 06, 2004 9:54 PM Subject: Re: [Hivemind] Tapestry/HttpSession service Ah, yes I did miss that part. Seems like you want a wrapper service to the HttpSession like the Visit? Geoff Longman wrote: I don't think ThreadLocalStorage is sufficient. Perhaps this is too specific to Tapestry and is a topic for Tapestry 3.1 discussion. It all boils down to a service that not only is thread local, but is also session local. Geoff - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: Tapestry development [EMAIL PROTECTED] Sent: Saturday, March 06, 2004 9:28 PM Subject: Re: [Hivemind] Tapestry/HttpSession service Have you looked into the ThreadLocalStorage? -Harish Geoff Longman wrote: The content of this message crosses boundaries so I'm cc'ing Tapestry dev too. I have a
Re: Re: [Hivemind] Tapestry/HttpSession service
I like this idea. Won't be able to get back to this before the weekend though. The day job calls.. Geoff - Original Message - From: christian essl [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, March 07, 2004 1:44 AM Subject: AW: Re: [Hivemind] Tapestry/HttpSession service another try without a sessin-model actually quite simular to yours. A ServiceFactory which is thread-local and delegates to another SerciceFact. the servicefact checks if the implementation is already in the session if not creates it and returns. it also keeps a list off all handed out implementations and right befor the request is over it stores them back in the session - therefor it is thread-local or pooled. this factory is than used from thread-local models. what do you think? thanks, chris -Original Message- From: Geoff Longman [EMAIL PROTECTED] Date: Sat, 6 Mar 2004 22:27:50 To:Tapestry development [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Hivemind] Tapestry/HttpSession service Ahh, but we're trying to reduce our dependency on the Visit. We have many groups of pages, and each group needs to store a distinct set of data. Our visit class was becoming a mess. Plus, a session local service could also be useful outside of Tapestry where there is no Visit! No reason why a JSP couldn't use a session local service. Geoff - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Tapestry development [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 06, 2004 10:14 PM Subject: Re: [Hivemind] Tapestry/HttpSession service The way I see it, you simply need a regular service with ThreadLocalStorage. The servlet filter would set the visit in the ThreadLocalStorage for every request and the service would simply get and set the data on the visit in the ThreadLocal. Would that work? -Harish Geoff Longman wrote: Perhaps, I wish I had more time to read the Hivemind source. I might be getting this wrong but how about a Factory that makes a session local instance of a service? Wait that can't be right. A SessionLocalService that pulls a service from a pool and hooks it up to the session. The existing servlet filter could be a model for a filter that sets up the SessionLocalService with the thread local session. The above ignores the need to restore/save a service's session local state though. hmm, still thinking.. Geoff - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Tapestry development [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 06, 2004 9:54 PM Subject: Re: [Hivemind] Tapestry/HttpSession service Ah, yes I did miss that part. Seems like you want a wrapper service to the HttpSession like the Visit? Geoff Longman wrote: I don't think ThreadLocalStorage is sufficient. Perhaps this is too specific to Tapestry and is a topic for Tapestry 3.1 discussion. It all boils down to a service that not only is thread local, but is also session local. Geoff - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: Tapestry development [EMAIL PROTECTED] Sent: Saturday, March 06, 2004 9:28 PM Subject: Re: [Hivemind] Tapestry/HttpSession service Have you looked into the ThreadLocalStorage? -Harish Geoff Longman wrote: The content of this message crosses boundaries so I'm cc'ing Tapestry dev too. I have a real problem in a Tapestry application and I'm wondering if another 'flavour' of Hivemind service approach would be applicable. We have a Tapestry app that has many hundreds of pages. Different groups of pages need to share different sets of information. We have tried using the Visit to share data and have also tried explicity passing things between pages but both methods are less than ideal.. The visit approach ends up being like a big hashtable. Explicity passing data via method calls leads to coupling between pages. What would be nice is a service that is not only pooled, but is peristent in the Tapestry way, i.e. the value of certain fields in the service are private to one user session. An example implementation could be a Wizard that uses 5 pages to build a new customer record in a database. If the service I described was doable, each page could access a NewCustomerWizard service, read data from it and set data in it. The NewCustomerWizardService could minimally reply to questions like: - Can the wizard finish? - What's the next page to show? - What's the previous page to show? Thus,
Re: [cli] v1 v2 API compatibility
John Keyes wrote: I spent today looking at realizing the v1 API with the v2 runtime. After making some progress, I started to wonder was there any compeling reason to do so. Nothing compelling - just ease of adoption. Still haven't looked into it in detail but an alternative to reimplementing the v1 api would be to simply deprecate the package and provide an adapter or two - that way people could perform the upgrade more gentley: gBuilder.withOption(Cli1Adapter.adaptOption(cli1Option)); or parser.setGroup(Cli1Adapter.adaptOptions(cli1Options)); parser.parse(args); Not sure its worth the effort though - we don't want to support the old codebase longer than necessary. Therefore, I propose to branch the v1 code and put it into maintanence mode. This will allow us to merge the v2 branch to the mainline (assuming it gets approval). I don't see this as being much of an overhead but I would like to hear what others think before putting this to a vote. I assume a decision of this nature requires a vote as it is almost like proposing a new subproject. The overhead seems perfectly reasonable for a new major version - most people accept api breakages for major versions anyway. This would also allow us to keep the org.apache.commons.cli package for both versions. Comments? We should probably queue up a review of the copyright statements in the licence header if we merge back to the old package - I'm pretty sure the rewrite versions all have 2003-2004 or 2004 but merging back might mean that some of them should probably classed as edits of older documents (hence start with older dates). Dunno though - IANAL etc etc. Rob -John K - 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 27515] New: - Add getters to OrPredicate and AndPredicate
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=27515. 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=27515 Add getters to OrPredicate and AndPredicate Summary: Add getters to OrPredicate and AndPredicate Product: Commons Version: 3.0 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Collections AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm building an UI for editing Predicates. The problem is that I can't query an OrPredicate or an AndPredicate for their predicate1 and predicate2 fields. Please provide a getter for each field. (sorry i should provide a patch but i'm behind a firewall and i can't access the CVS repository) Gilles Philippart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all][site] Site menu proposal
Cactus left commons a very long time ago. I don't see why we need any links now. Stephen --- Noel J. Bergman [EMAIL PROTECTED] wrote: On http://jakarta.apache.org/commons-mavenized/components.html, there is a link for Cactus, which is broken. Will the current page at http://jakarta.apache.org/commons/cactus/ be preserved, or should we just point to the new location? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Hivemind] Tapestry/HttpSession service
It's my understanding of SOA that the service should not deal with state at all. Forgive the lack of eloquence in my reply. A service that is thread local *is* dealing with state for the period that it is attached to a particular thread. For example, a service that provides database transactions must manage the state of the transactions it provides while its attached to a thread, but all bets are off at some point when its necessary to disassociate the the service from the thread (like at the end of a web request). I don't see the great difference here between a service that has an activate/passivate lifecycle with regards to threads and a service with the same lifecycle with regards to a web session. Making a service session local follows the same ideal, activation is a bit more work (restore/save some state from/to the session) . I'll stay with the transaction metaphor, but I assume that a transaction is something other than a database transaction. My hypothesis is that a wizard in a web application is a transaction, but it spans more than one web request. My thinking is that it could be modeled after the way Howard did the Symbol source stuff. Have a factory service, say WizardManager. This service has a configuration point called WizardSource. The interface for WizardSource has createWizard() and getType(). Then you have NewCustomerWizard, NewSupplierWizard etc. modules that contribute their own WizardSource implementations. You would make a call to the WizardManager...newWizard(customer) which would iterate over the various contributed WizardSource's and call createWizard() and return the appropriate one which could then be stored in the visit. If the wizards have a standard interface, the pages would only be coupled to the interface and nothing else. A very minimal implementation that ignores configuration points (because I'm still learning about those). Create a service called HttpSessionService that is pooled and has two methods setSession(HttpSession) HttpSession getSession() implements PoolManageable and overrides passivateService() to null out its session field on cleanup. Its job is make the session available to other services and that's it. Use a new servlet filter (or extend the hive one) to call setSession on a thread local HttpSessionService instance when a request starts. Another service, MyWizardService implements PoolManageable, uses the HttpSessionService to obtain the session.On activateService() is restores any session dependant state. When passivateService() is called, any session dependant state is stored in the session. Now, having ignored the interface for MyWizardService completely, clients can get a session local reference to MyWizardService with one simple call to the Registry, and the client is not responsible for keeping track of session dependant state somewhere (like the Visit). To me having a service to obtain a wizard but then making the client responsible for managing the wizard state would be like making Tapestry programmers responsible for maitaining the persistent properties of thier pages/components manually in the Visit. yuk. Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][site] Site menu proposal
First off, I'm very glad to actually have a website to play with that has expandable sections for the components. Up until now we have been guessing what it would be like. On home, the components really must be linked in the left nav, visible from the start. They are commons. Its also easy to forget with a fast connection that expanding and collapsing a menu goes to the server. We could consider having sandbox as collapsed however. Similarly on the project page, we need to get all the project docs at the top with a different background/clear separator. I could live with partially collapsed menus for components here - components menu open if viewing a component, sandbox menu open if viewing a sandbox project. Stephen --- Dirk Verbeeck [EMAIL PROTECTED] wrote: Hi all I have made a mavenized commons site with an alternative menu structure to the current proposal (http://jakarta.apache.org/commons-mavenized). The page content has to be updated but I wanted to show the menu first. http://cvs.apache.org/~dirkv/commons-site/index.html and as example I have also rendered the DBCP component site: http://cvs.apache.org/~dirkv/commons-site/dbcp/index.html As you can see the general pages and the component site have a very similar menu structure. The common site has a download, CVS related top menus where the component site has a component specific top level menu (including a specific download page) Project Documentation. I collapsed the components sandbox menus. If a direct link from the homepage to each component is needed then I propose a table on the page itself like on the jakarta homepage. Now you have to click on the components/sandbox menu item and then select a component (2 clicks). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Hivemind] Tapestry/HttpSession service
Geoff, I think you are right on to my thinking w.r.t. threaded services. Technically, HiveMind isn't SOA because services can have some state. However, I think this is OK. One of the problems with traditional SOAs is that (due to location and language transparency), they must have complex parameters to pass and client-specific state. HiveMind service interfaces are simple because a lot of conversation can go on, behind the scenes, via threaded/pooled services and event notifications. The public face is simple, the implementation involves a lot of collaboration. The use of proxies ensures that collaboration occurs properly, in accordance with the service model, without any imposition on the client code (or collaborating service). Things just lock together. Create a service called HttpSessionService that is pooled and has two methods Again, this is just the kind of thing I'm picturing for Tapestry 3.1 ... a central infrastructure service that knows about the current request. -- 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]
Re: [Hivemind] Tapestry/HttpSession service
Again, this is just the kind of thing I'm picturing for Tapestry 3.1 ... a central infrastructure service that knows about the current request. I would suggest that this central infrastructure service be located in the Hivemind library module. I think that such a service would be useful outside of Tapestry! Geoff - Original Message - From: Howard M. Lewis Ship [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, March 08, 2004 8:37 AM Subject: RE: [Hivemind] Tapestry/HttpSession service Geoff, I think you are right on to my thinking w.r.t. threaded services. Technically, HiveMind isn't SOA because services can have some state. However, I think this is OK. One of the problems with traditional SOAs is that (due to location and language transparency), they must have complex parameters to pass and client-specific state. HiveMind service interfaces are simple because a lot of conversation can go on, behind the scenes, via threaded/pooled services and event notifications. The public face is simple, the implementation involves a lot of collaboration. The use of proxies ensures that collaboration occurs properly, in accordance with the service model, without any imposition on the client code (or collaborating service). Things just lock together. Create a service called HttpSessionService that is pooled and has two methods Again, this is just the kind of thing I'm picturing for Tapestry 3.1 ... a central infrastructure service that knows about the current request. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][site] Site menu proposal
I didn't realize, its probibly just old content, then I'll make sure I remove it from the site docs. Are there any other projects that should not be on the list? -Mark Stephen Colebourne wrote: Cactus left commons a very long time ago. I don't see why we need any links now. Stephen --- Noel J. Bergman [EMAIL PROTECTED] wrote: On http://jakarta.apache.org/commons-mavenized/components.html, there is a link for Cactus, which is broken. Will the current page at http://jakarta.apache.org/commons/cactus/ be preserved, or should we just point to the new location? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/commons-build/xdocs components.xml
mdiggory2004/03/08 06:34:45 Modified:commons-build/xdocs components.xml Log: Removign Cactus, it is no longer a commons project. Revision ChangesPath 1.118 +0 -12 jakarta-commons/commons-build/xdocs/components.xml Index: components.xml === RCS file: /home/cvs/jakarta-commons/commons-build/xdocs/components.xml,v retrieving revision 1.117 retrieving revision 1.118 diff -u -r1.117 -r1.118 --- components.xml1 Mar 2004 22:31:33 - 1.117 +++ components.xml8 Mar 2004 14:34:45 - 1.118 @@ -44,18 +44,6 @@ /dd !-- /BeanUtils -- -!-- Cactus -- -dtbbiga href=cactus/Cactus/a/big/b/dt -dd - Commons-Cactus is a framework for testing server-side - (J2EE) Java code using in-container extensions to - a href=http://junit.org/;JUnit/a. - br/ - Note that Cactus has been moved to a top level Jakarta project. - See a href=http://jakarta.apache.org/cactus/;http://jakarta.apache.org/cactus//a. -/dd -!-- /Cactus -- - !-- CLI -- dtbbiga href=http://jakarta.apache.org/commons/cli/;CLI/a/big/b/dt dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] v1 v2 API compatibility
Rob Oxspring wrote: John Keyes wrote: I spent today looking at realizing the v1 API with the v2 runtime. After making some progress, I started to wonder was there any compeling reason to do so. Nothing compelling - just ease of adoption. Still haven't looked into it in detail but an alternative to reimplementing the v1 api would be to simply deprecate the package and provide an adapter or two - that way people could perform the upgrade more gentley: gBuilder.withOption(Cli1Adapter.adaptOption(cli1Option)); or parser.setGroup(Cli1Adapter.adaptOptions(cli1Options)); parser.parse(args); Not sure its worth the effort though - we don't want to support the old codebase longer than necessary. +1 - we need to keep the maintenance to a minimum Therefore, I propose to branch the v1 code and put it into maintanence mode. This will allow us to merge the v2 branch to the mainline (assuming it gets approval). I don't see this as being much of an overhead but I would like to hear what others think before putting this to a vote. I assume a decision of this nature requires a vote as it is almost like proposing a new subproject. The overhead seems perfectly reasonable for a new major version - most people accept api breakages for major versions anyway. In the majority of cases people seem okay. Just wouldn't like to step on anyones toes. This would also allow us to keep the org.apache.commons.cli package for both versions. Comments? We should probably queue up a review of the copyright statements in the licence header if we merge back to the old package - I'm pretty sure the rewrite versions all have 2003-2004 or 2004 but merging back might mean that some of them should probably classed as edits of older documents (hence start with older dates). Dunno though - IANAL etc etc. Well we should deprecate all of the code there anyway. Not sure what the best way to publicize this though. Do we make a release of 1.1 which has these changes for deprecation included? To make this release we need to have the code licensed with AL2. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proposal for the Commons Sandbox
I have recently started a project in the Java Foundry on Sourceforge called Jestr, and it seems like it might be a natural fit for the Jakarta Commons project. You can read about it here: http://jestr.sourceforge.net The project uses many Jakarta Commons components and is released under the Apache Software License. Jestr is still Beta software and I would not recommend it for promotion to the Commons proper at this point (besides, it depends on the Functor component which is currently sandboxed), but I'd like to offer it for inclusion in the Commons Sandbox. I just wanted to gauge whether there was any interest in accepting it here. If so, I would of course rename the root package from jestr to org.apache.commons.jestr, or perhaps org.apache.commons.stringify. Other than that there would be little to change, since Jestr uses the standard Jakarta Commons build and directory structure (I cannibalized the Functor component's build.xml). Plz post any comments, suggestions, etc., to the list. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal for the Commons Sandbox
Hi, Is this too close to commons-lang ToStringBuilder/ToStringStyle (http://jakarta.apache.org/commons/lang/apidocs/org/apache/commons/lang/ builder/ToStringBuilder.html) to be a separate project? Yoav Shapira Millennium ChemInformatics -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 9:54 AM To: [EMAIL PROTECTED] Subject: Proposal for the Commons Sandbox I have recently started a project in the Java Foundry on Sourceforge called Jestr, and it seems like it might be a natural fit for the Jakarta Commons project. You can read about it here: http://jestr.sourceforge.net The project uses many Jakarta Commons components and is released under the Apache Software License. Jestr is still Beta software and I would not recommend it for promotion to the Commons proper at this point (besides, it depends on the Functor component which is currently sandboxed), but I'd like to offer it for inclusion in the Commons Sandbox. I just wanted to gauge whether there was any interest in accepting it here. If so, I would of course rename the root package from jestr to org.apache.commons.jestr, or perhaps org.apache.commons.stringify. Other than that there would be little to change, since Jestr uses the standard Jakarta Commons build and directory structure (I cannibalized the Functor component's build.xml). Plz post any comments, suggestions, etc., to the list. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for the Commons Sandbox
David Gilliland wrote: I have recently started a project in the Java Foundry on Sourceforge called Jestr, and it seems like it might be a natural fit for the Jakarta Commons project. You can read about it here: http://jestr.sourceforge.net The project uses many Jakarta Commons components and is released under the Apache Software License. Jestr is still Beta software and I would not recommend it for promotion to the Commons proper at this point (besides, it depends on the Functor component which is currently sandboxed), but I'd like to offer it for inclusion in the Commons Sandbox. I just wanted to gauge whether there was any interest in accepting it here. If so, I would of course rename the root package from jestr to org.apache.commons.jestr, or perhaps org.apache.commons.stringify. Other than that there would be little to change, since Jestr uses the standard Jakarta Commons build and directory structure (I cannibalized the Functor component's build.xml). At a glance, this looks interesting. I sometimes wish that there was a way to define and register things at runtime like toString()s, comparators, equals(), and converters without having to modify the actual class. So that instead of having to make an explicit call to your special toString(), it would just magically happen. But, I guess this is what AOP is for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal for the Commons Sandbox
Hi, Good point, and that occurred to me as well. However I think Jestr is a little different from the ToStringBuilder stuff because it isn't necessarily concerned with helping you implement toString() methods; instead, it's more concerned with helping you log *arbitrary* objects, even if you don't have access to their source code to change their toString() methods. What I'd like is an implementation of log4j's ObjectRenderer (org.apache.log4j.or.ObjectRenderer) that uses reflection like commons-lang reflectionToStringBuilfer. This wouldn't be difficult to write, I imagine. I wouldn't want a whole new package or dependency for this. Log4j isn't going to add commons-lang as a dependency either. Hmm... ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27436] - With Oracle jdbc driver, an unnecessary SQL set transaction read write is issued each time a connection is retrieved from the pool
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=27436. 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=27436 With Oracle jdbc driver, an unnecessary SQL set transaction read write is issued each time a connection is retrieved from the pool [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal for the Commons Sandbox
I originally considered implementing Jestr as a Log4J object renderer, but decided against it because (a) I didn't want it to depend on Log4J, and more importantly (b) stringification and logging are logically distinct activities and there are some very good reasons for stringifying objects that are totally disconnected from logging. Once you have a stringified representation, you may do any number of different things with it. One of those things is to send it to the logger. Another might be to stuff it into your Struts form to be included by a JSP implementing some sort of monitoring console. In fact, at a previous job I implemented just such a console that would let you request a particular business object via a special URL syntax, and have that object's string representation displayed in your Web browser. So for example if customer sally is experiencing strange behavior, you can log in to the console and view her Customer instance along with all its dependent objects like accounts, profiles, etc, to see if something looks amiss. -- Original Message -- From: Shapira, Yoav [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 10:17:45 -0500 Hi, Good point, and that occurred to me as well. However I think Jestr is a little different from the ToStringBuilder stuff because it isn't necessarily concerned with helping you implement toString() methods; instead, it's more concerned with helping you log *arbitrary* objects, even if you don't have access to their source code to change their toString() methods. What I'd like is an implementation of log4j's ObjectRenderer (org.apache.log4j.or.ObjectRenderer) that uses reflection like commons-lang reflectionToStringBuilfer. This wouldn't be difficult to write, I imagine. I wouldn't want a whole new package or dependency for this. Log4j isn't going to add commons-lang as a dependency either. Hmm... ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpClient.java
olegk 2004/03/08 08:33:38
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH HttpClient.java
Log:
PR #27242 (Socket Closed IOException thrown by HttpConnection)
Changelog:
* HttpClient#executeMethod changed to perform stale connection check prior to
setting socket timeout
Contributed by Oleg Kalnichevski
Revision ChangesPath
No revision
No revision
1.76.2.5 +6 -6
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpClient.java
Index: HttpClient.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpClient.java,v
retrieving revision 1.76.2.4
retrieving revision 1.76.2.5
diff -u -r1.76.2.4 -r1.76.2.5
--- HttpClient.java 22 Feb 2004 18:21:13 - 1.76.2.4
+++ HttpClient.java 8 Mar 2004 16:33:38 - 1.76.2.5
@@ -623,8 +623,6 @@
method.setStrictMode(strictMode);
-connection.setSoTimeout(soTimeout);
-
if (!connection.isOpen()) {
connection.setConnectionTimeout(connectionTimeout);
connection.open();
@@ -632,6 +630,8 @@
method = new ConnectMethod(method);
}
}
+connection.setSoTimeout(soTimeout);
+
} catch (IOException e) {
connection.releaseConnection();
throw e;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils BeanPredicateTestCase.java
tobrien 2004/03/08 09:05:06
Added: beanutils/src/java/org/apache/commons/beanutils
BeanPredicate.java
beanutils/src/test/org/apache/commons/beanutils
BeanPredicateTestCase.java
Log:
Added BeanPredicate with a TestCase
Revision ChangesPath
1.1
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanPredicate.java
Index: BeanPredicate.java
===
/*
* Copyright 2001-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.beanutils;
import org.apache.commons.collections.Predicate;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import java.lang.reflect.InvocationTargetException;
public class BeanPredicate implements Predicate {
private final Log log = LogFactory.getLog(this.getClass());
private String propertyName;
private Predicate predicate;
public BeanPredicate(String propertyName, Predicate predicate) {
this.propertyName = propertyName;
this.predicate = predicate;
}
public boolean evaluate(Object object) {
boolean evaluation = false;
try {
Object propValue = PropertyUtils.getProperty( object, propertyName );
evaluation = predicate.evaluate(propValue);
} catch (IllegalArgumentException e) {
final String errorMsg = Problem during evaluation.;
log.error(ERROR: + errorMsg, e);
throw e;
} catch (IllegalAccessException e) {
final String errorMsg = Unable to access the property provided.;
log.error(errorMsg, e);
throw new IllegalArgumentException(errorMsg);
} catch (InvocationTargetException e) {
final String errorMsg = Exception occurred in property's getter;
log.error(errorMsg, e);
throw new IllegalArgumentException(errorMsg);
} catch (NoSuchMethodException e) {
final String errorMsg = Property not found.;
log.error(errorMsg, e);
throw new IllegalArgumentException(errorMsg);
}
return evaluation;
}
public String getPropertyName() {
return propertyName;
}
public void setPropertyName(String propertyName) {
this.propertyName = propertyName;
}
public Predicate getPredicate() {
return predicate;
}
public void setPredicate(Predicate predicate) {
this.predicate = predicate;
}
}
1.1
jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/BeanPredicateTestCase.java
Index: BeanPredicateTestCase.java
===
/*
* Copyright 2001-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.beanutils;
import junit.framework.TestCase;
import org.apache.commons.collections.functors.EqualPredicate;
import org.apache.commons.collections.functors.InstanceofPredicate;
import org.apache.commons.collections.functors.NotPredicate;
import org.apache.commons.collections.functors.NullPredicate;
public class BeanPredicateTestCase extends TestCase {
public BeanPredicateTestCase(String name) {
super(name);
}
public void testEqual() {
BeanPredicate predicate =
new BeanPredicate(stringProperty,new EqualPredicate(foo));
assertTrue(predicate.evaluate(new TestBean(foo)));
assertTrue(!predicate.evaluate(new TestBean(bar)));
}
public
[beanutils] A BeanPredicate which wraps another Predicate
BeanUtils has a BeanPropertyValueEqualsPredicate, this Predicate uses PropertyUtils to get a bean property and then checks to see if the bean property equals a certain value. This is great if your application needs to test a bean property for equality, but it limits what can be done with the various Predicates now available in collections 3.0. I've added a BeanPredicate which allows you to decorate a Predicate to act upon a bean property. This class is in the spirit of BeanComparator. BeanPropertyValueEqualsPredicate predicate = new BeanPropertyValueEqualsPredicate( activeEmployee, Boolean.FALSE ); Now becomes, BeanPredicate predicate = new BeanPredicate( activeEmployee, new EqualPredicate( Boolean.FALSE ) ); And it also allow for other predicates. To check for a null bean property: BeanPredicate predicate = new BeanPredicate( name, NullPredicate.INSTANCE ); Or to test the type of a bean property: BeanPredicate predicate = new BeanPredicate( name, new InstanceofPredicate(String.class) ); ... and so on and so forth ... Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Release Candidate Build of Commons Logging 1.0.4 Available
Quoting Dennis Lundberg [EMAIL PROTECTED]: This might have been brought up before. It's about the dateformat used in SimpleLog. Currently SimpleLog uses /MM/dd, but the ISO 8601 standard, which is spreading rapidly, has this format -MM-dd. On the other hand, changing a thing like this might be concidered breaking backwards compatibility. ISO Dates? Now where have I heard about *those* before? :-). I think it'd be a good idea to add an *option* so that you can have ISO dates, but have the default behavior be identical to the current in order to avoid breaking backwards compatibility. However, I don't necessarily have an itch to do this myself for the 1.0.4 release (it could easily be added immediately afterwards and thus be available in nightly builds to people that want it). Best way to make that happen would be to post an enhancement request into the issue tracking system (http://issues.apache.org/bugzilla/) -- even better would be a request plus a patch. Sound good? -- Dennis Lundberg Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/test/org/apache/commons/beanutils BeanPredicateTestCase.java
tobrien 2004/03/08 09:41:51 Modified:beanutils/src/java/org/apache/commons/beanutils BeanPredicate.java beanutils/src/test/org/apache/commons/beanutils BeanPredicateTestCase.java Log: Copyright was 2001-2004, changed to 2004 Revision ChangesPath 1.2 +1 -1 jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanPredicate.java Index: BeanPredicate.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanPredicate.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- BeanPredicate.java8 Mar 2004 17:05:06 - 1.1 +++ BeanPredicate.java8 Mar 2004 17:41:51 - 1.2 @@ -1,5 +1,5 @@ /* - * Copyright 2001-2004 The Apache Software Foundation. + * 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. 1.2 +1 -1 jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/BeanPredicateTestCase.java Index: BeanPredicateTestCase.java === RCS file: /home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/BeanPredicateTestCase.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- BeanPredicateTestCase.java8 Mar 2004 17:05:06 - 1.1 +++ BeanPredicateTestCase.java8 Mar 2004 17:41:51 - 1.2 @@ -1,5 +1,5 @@ /* - * Copyright 2001-2004 The Apache Software Foundation. + * 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal for the Commons Sandbox
Hello, However I think Jestr is a little different from the ToStringBuilder stuff because it isn't necessarily concerned with helping you implement toString() methods; instead, it's more concerned with helping you log *arbitrary* objects, even if you don't have access to their source code to change their toString() methods. Note that the o.a.c.l.builder package also provides the ability to operate on an arbitrary object. Please see: (1) The class ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/build er/ReflectionToStringBuilder.html (2) The ToStringBuilder methods which forward to ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/build er/ToStringBuilder.html#reflectionToString(java.lang.Object) Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] daemon: pass arbitrary number of parameters through procrun
When upgrading to tomcat5 from tomcat4, I noticed the service handling changed and
broke some useful things like passing parameters to tomcat when running as a service.
Specifically, it lost the ability to override the configuration files, with -config
server.xml, for example.
I reworked the command syntax a bit to expand on the --StartupClass argument. It now
works with an arbitrary number of parameters to pass to the method:
--StartupClass package.Class;method;param0;param1;param2;...;paramN
instead of:
--StartupClass package.Class;method;param
ie.
--StartupClass
org.apache.catalina.startup.Bootstrap;main;-config;..\custom\server.xml;start
To do this I had to make a couple changes to procrun.h (expanding the java_t struct)
and, of course, converting the parameter handling code to something a little more loop
based.
I tried to stick with the existing conventions, please don't beat me if I missed
something!
~Ryan
patch below:
Index: procrun.c
===
RCS file: /home/cvspublic/jakarta-commons/daemon/src/native/nt/procrun/procrun.c,v
retrieving revision 1.14
diff -u -r1.14 procrun.c
--- procrun.c 11 Feb 2004 06:52:24 - 1.14
+++ procrun.c 8 Mar 2004 18:34:29 -
@@ -565,6 +565,7 @@
*/
static void debug_process(int argc, char **argv, process_t *p)
{
+int i;
DBPRINTF1(DUMPING %s\n, argv[0]);
DBPRINTF0( SERVICE:\n);
DBPRINTF1(name: %s\n, p-service.name);
@@ -581,8 +582,10 @@
DBPRINTF1(stop: %s\n, p-java.stop_class);
DBPRINTF1(start method: %s\n, p-java.start_method);
DBPRINTF1(stop method : %s\n, p-java.stop_method);
-DBPRINTF1(start param : %s\n, p-java.start_param);
-DBPRINTF1(stop param : %s\n, p-java.stop_param);
+ for (i = 0; i p-java.start_param_count; i++)
+ DBPRINTF2(start param %d : %s\n, i, p-java.start_param[i]);
+ for (i = 0; i p-java.stop_param_count; i++)
+ DBPRINTF2(stop param %d : %s\n, i, p-java.stop_param[i]);
DBPRINTF0(DONE...\n);
}
@@ -848,7 +851,9 @@
char skey[256];
char kval[MAX_PATH];
unsigned long klen;
+ int param_count;
DWORD err;
+ char *px;
if (!proc-service.name)
return 0;
@@ -916,15 +921,36 @@
p = strchr(kval, ';');
if (p) *p = '\0';
proc-java.start_class = pool_strdup(proc-pool, kval);
+ DBPRINTF1(read start_class: %s\n, kval);
+ if (p) {
+ p++;
+ px = p;
+ if (p = strchr(p, ';')) {
+ *p = '\0';
+ p++;
+ }
+proc-java.start_method = pool_strdup(proc-pool, px);
+ DBPRINTF1(read start_method: %s\n, px);
+ }
if (p) {
-++p;
-proc-java.start_method = pool_strdup(proc-pool, p);
-p = strchr(proc-java.start_method, ';');
-if (p) {
-*p = '\0';
-++p;
-proc-java.start_param = pool_strdup(proc-pool, p);
-}
+ DBPRINTF1(reading parameters from: %s\n, p);
+ px = p;
+ param_count = 0;
+ while ( p *p ) {
+ px = strchr(p, ';');
+ if (px) {
+ //there are more parameters to come
+ *px = '\0';
+ px++;
+ DBPRINTF1(there are more parameters
in: %s\n, px);
+ }
+ proc-java.start_param[param_count] =
pool_strdup(proc-pool, p);
+ DBPRINTF2(read parameter %d: %s\n,
param_count, p);
+ param_count++;
+ /* param_count is 0 base, start_param_count is
not */
+ proc-java.start_param_count = param_count;
+ p = px;
+ }
}
}
klen = MAX_PATH;
@@ -935,15 +961,36 @@
p = strchr(kval, ';');
if (p) *p = '\0';
proc-java.stop_class = pool_strdup(proc-pool, kval);
+ DBPRINTF1(read stop_class: %s\n, kval);
+ if (p) {
+ p++;
+ px = p;
+ if (p = strchr(p, ';')) {
+
RE: Proposal for the Commons Sandbox
Yes, I think Jestr could be incorporated cleanly into the ToStringBuilder hierarchy, either as a subclass of ToStringBuilder, or as a subclass of ReflectionToStringBuilder. I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term builder a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I building? -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 13:43:51 -0500 Hello, However I think Jestr is a little different from the ToStringBuilder stuff because it isn't necessarily concerned with helping you implement toString() methods; instead, it's more concerned with helping you log *arbitrary* objects, even if you don't have access to their source code to change their toString() methods. Note that the o.a.c.l.builder package also provides the ability to operate on an arbitrary object. Please see: (1) The class ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/build er/ReflectionToStringBuilder.html (2) The ToStringBuilder methods which forward to ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/build er/ToStringBuilder.html#reflectionToString(java.lang.Object) Gary - 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: Proposal for the Commons Sandbox
Hi, I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term builder a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I building? You're building the string representation of that object. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Hivemind] Tapestry/HttpSession service
I'm just looking forward to collaborating on this on a wiki. I think there are some good ideas coming out: Replacing free-form interceptors with interceptor sets (bypassing concerns about interceptor order). Hopefully, the Orderable interface can go away. Making schemas, and portions of schemas, more reusable. I have some concerns, to be saved for later. Previous discussions wanted to address how the Registry was constructed; perhaps having a META-INF/hiveboot.xml that is used to control and configure the RegistryBuilder and ModuleParser? More work to make it possible to easily add modules to the registry that come from more disparate places (databases, non-XML files, etc.). However, to me, the most exciting stuff is starting to integrate HiveMind with Hibernate, JMX, JDBC, iBatis, JMS, etc., etc., etc., etc.! Need to check if any of the LGPL restrictions are lifted with the ASL 2.0. It would be nice to have Hibernate (LGPL) integrated with HiveMind as a core package, rather than an external add-on, much as Swing does. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com -Original Message- From: Geoff Longman [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 8:46 AM To: Jakarta Commons Developers List Subject: Re: [Hivemind] Tapestry/HttpSession service Again, this is just the kind of thing I'm picturing for Tapestry 3.1 ... a central infrastructure service that knows about the current request. I would suggest that this central infrastructure service be located in the Hivemind library module. I think that such a service would be useful outside of Tapestry! Geoff - Original Message - From: Howard M. Lewis Ship [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, March 08, 2004 8:37 AM Subject: RE: [Hivemind] Tapestry/HttpSession service Geoff, I think you are right on to my thinking w.r.t. threaded services. Technically, HiveMind isn't SOA because services can have some state. However, I think this is OK. One of the problems with traditional SOAs is that (due to location and language transparency), they must have complex parameters to pass and client-specific state. HiveMind service interfaces are simple because a lot of conversation can go on, behind the scenes, via threaded/pooled services and event notifications. The public face is simple, the implementation involves a lot of collaboration. The use of proxies ensures that collaboration occurs properly, in accordance with the service model, without any imposition on the client code (or collaborating service). Things just lock together. Create a service called HttpSessionService that is pooled and has two methods Again, this is just the kind of thing I'm picturing for Tapestry 3.1 ... a central infrastructure service that knows about the current request. -- 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] - 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]
FTP ing Japanese locale server : Code need to be changes?
Hi: I am trying to FTP a Server with Japanese locale. Is there any specific code needs to be changed? Please clarify! Any code sample is helpful. Asha
RE: Proposal for the Commons Sandbox
True, but the term builder in the org.apache.commons.lang.builder sense of the word means a thing that helps me build a method. After all, EqualsBuilder is named such because it helps me build an equals() method, not because it builds a thing called an equals. -- Original Message -- From: Shapira, Yoav [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 14:10:45 -0500 Hi, I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term builder a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I building? You're building the string representation of that object. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[HiveMind] Nonintrusive configuration
Hi, while it is rather easy to reuse HiveMind services with another ioc framework this is not true for configuration data. Look at this configuration: module id=moduleId version=1.0.0 contribution configuration-id=User user name=mka password=mka / /contribution /module HiveMind is quite intrusive here. The configuration data resides in a Hivemind specific contribution element which is nested in a module element. Reuse could be simplified by introducing external configurations: module id=moduleId version=1.0.0 file-contribution configuration-id=User fileName=users.xml root=users / /module .. external file users.xml (on classpath): ?xml version=1.0 encoding=ISO_8859-1? users user name=mka password=mka / /users Advantages: - configurations are framework independent - configuration files can use a schema for validation - you can use existing formats/files easily (for those switching to hivemind) What do you think? Bye Achim Huegen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27523] New: - Can not compile under Fedora Core 1 AMD64
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=27523. 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=27523 Can not compile under Fedora Core 1 AMD64 Summary: Can not compile under Fedora Core 1 AMD64 Product: Commons Version: 1.0 Alpha Platform: PC OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Daemon AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It is request for enhancement. Please add new architecture x86_64 into ./configure script. Thanks, Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal for the Commons Sandbox
In this case you are building a java.lang.String. Simple answer eh? ;-) The [Reflection]ToStringBuilder is used to create a String based on other Objects. The most common usage is to implement an Object's toString() method with a [Reflection]ToStringBuilder. You can also use the string builder classes to build a String for any object of course. For example, it can be useful for debugging purposes to use a ReflectionToStringBuilder toString to dump the contents of an arbitrary object. For the package as a whole, the term builder applies to the notion of building different kinds of algorithms for us with toString(), equals(), compareTo(), and hashCode(). Builder might not be a great name but it is hard to think of a name that says: Assits in overriding methods that are in Object: toString(), hashCode(), equals(), and also compareTo(). Gary -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 11:13 To: Jakarta Commons Developers List Subject: RE: Proposal for the Commons Sandbox Yes, I think Jestr could be incorporated cleanly into the ToStringBuilder hierarchy, either as a subclass of ToStringBuilder, or as a subclass of ReflectionToStringBuilder. I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term builder a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I building? -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List commons- [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 13:43:51 -0500 Hello, However I think Jestr is a little different from the ToStringBuilder stuff because it isn't necessarily concerned with helping you implement toString() methods; instead, it's more concerned with helping you log *arbitrary* objects, even if you don't have access to their source code to change their toString() methods. Note that the o.a.c.l.builder package also provides the ability to operate on an arbitrary object. Please see: (1) The class ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/buil d er/ReflectionToStringBuilder.html (2) The ToStringBuilder methods which forward to ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/buil d er/ToStringBuilder.html#reflectionToString(java.lang.Object) Gary - 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]
[Launcher] Requested change in Launcher.getBootstrapFile
Hi, I am trying to use the Launcher from a class running in a WAS 5.0 Web App. I ran into a problem when the Launcher.start is trying to get the Bootstrap File for use in determining the canonical path for its default launch file. The problem is that the code boolean isJar = jar.equals(resource.getProtocol()) ? true : false; Does not evaluate to true when running in the WAS Web App. The reason is that the protocol returned is wsjar. I would like to suggest changing the above line of code to: boolean isJar = (resource.getProtocol().indexOf(jar) = 0) ? true : false; Marcus Mosttler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] basic JAXB/jaxme tag library
On 7 Mar 2004, at 23:18, Paul Libbrecht wrote: On 6-Mar-04, at 11:43 Uhr, robert burrell donkin wrote: he organized an apache licensed, clean room implementation of the required API (it's distributed as the JaxMeAPI). That sounds great (I presume it's already into the ibliblio repository) but... does this mean that such an API is something that sort of replaces the javax.xxx packages ? If yes I fear this would be blatant violation of quite an amoount of Sun licenses (as far as I've understood them), otherwise, how can there be an interface with the interesting name ?? (it's the jar that has an interesting name, not the classes. sorry for being a bit unclear.) AIUI the sun license (for the JAXB specification) allows the creation of API implementations (in the javax.xxx package space) from the specification providing that they are pure (no extensions) and compliant, clean room implementations of the specification. what isn't allowed are works derived from the JAXB standard implementation (used to be called the reference implementation). (IIRC the tomcat did something similar for one of the earlier servlet specifications.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project Proposal
Hello You also can look at OGNL: http://www.ognl.org/ Best regards, Konstantin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cli] v1 v2 API compatibility
Sorry to be jumping late in the discussion but since I am a Cli 1 user... It seems to me that a solution would be to delivery either: [cli] which is (1) cli2 and cli1 is still available on the site OR (2) cli1.jar+cli2.jar where cli1 is just as it is now, NOT re-implemented on top of cli2. This allows for 0 risk of subtle behavioral changes and 100% backwards compatibility. I assume that both versions are in completely separate packages. Make both versions downloadable from the site. Here is why. I favor (1). I am cli1 user; I can keep on using cli1 as is. I want to use cli2 with new code. I can migrate from cli1 to cli2 at my leisure. Then I can get rid of cli1.jar (or whatever it is called) for good. My 2c, Gary -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 08, 2004 13:00 To: [EMAIL PROTECTED] Subject: Re: [cli] v1 v2 API compatibility John Keyes wrote: I spent today looking at realizing the v1 API with the v2 runtime. After making some progress, I started to wonder was there any compeling reason to do so. Therefore, I propose to branch the v1 code and put it into maintanence mode. This will allow us to merge the v2 branch to the mainline (assuming it gets approval). I don't see this as being much of an overhead but I would like to hear what others think before putting this to a vote. I assume a decision of this nature requires a vote as it is almost like proposing a new subproject. This would also allow us to keep the org.apache.commons.cli package for both versions. Comments? I don't know how many people use CLI v1, but this kind of action can have a huge ripple effect. IMO making backward incompatible changes should be deprecated :-), if the API can't be maintained you should use a different package name ( like cli2 ), to allow people to keep using both versions at the same time. Since the apis are incompatible and users who chose to upgrade will have to change code anyway - this just add a bit more inconvenience, but at least avoid the upgrade everything or nothing because one small library change. Costin - 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: [Digester] New rules
On 7 Mar 2004, at 20:15, Simon Kitching wrote: snip How about we start a Wiki page where these ideas can be jotted down for later reference? that sounds like a fine plan but probably it needs to be in the new wiki (rather than the old). might take a little time to set this up. (let me know if you fancy volunteering to help with the change.) BTW if you feel like taking on maven sometime (it installs reasonable easily and has many features that you'll find interesting) i'd be happy to see a link added to the digester site documentation about the ruby version. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [HiveMind] nested schemas
The act of assigning an id to a schema is, in effect, a promise on the part of the developer that the schema (and the Java objects assembled from contributions to that schema) are stable enough for others to reuse. In the case that no id is provided, it may be an oversight, or it may be that the Java objects are not reusable. Can you give me reasonable examples of why you think this change is necessary? To date, in HiveMind, everything really has been driven by real experience (generally, anti-patterns in other software, but still). -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com -Original Message- From: Christian Essl [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 4:07 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] nested schemas Thanks for the hint on schema-id! I've added it now. Checking and complaining early :). I removed the configuration-id and service-id atts and have just schema-id. However I still want to access schemas even if they don't provide an id. Therefore in my current implementation I give each schema which has no id set a default id. For configuration schemas 'c:'+config-id, for service schemas 's:'+service-id. (This ids can also be used in schema id-ref= ). What do you think of that, is this too much change? Thanks, Chris -- Christian Essl - 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]
[all] wiki migration...?
AIUI apache are moving away from the existing wiki towards a new implementation that will allow better supervision. see: http://nagoya.apache.org/wiki/apachewiki.cgi?MigrateFromThisWiki http://wiki.apache.org/general/UseModMigration the lazy consensus appears to be that jakarta will match sub-wiki's to sub-projects so probably commons would have it's own sub-wiki. we would need to watch out for change messages posted to the list and heal any vandalism. are we really to make the jump and (if so) does anyone feel like stepping forward to make this happen? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all][site] Site menu proposal
Howdy, BTW, the - (collapse) links aren't working for me. The + (expand) links are fine. IE 6 (latest patches) on Win2K. Yoav Shapira Millennium ChemInformatics -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 3:39 PM To: Jakarta Commons Developers List Subject: Re: [all][site] Site menu proposal OK, most people want the component specific menus the Project Documentation together. http://cvs.apache.org/~dirkv/commons-site2/dbcp/index.html What is left is the question if we want a list of (sandbox) components in the left menu or not. The current proposal (option 1) is to have 2 collapsed menu items in the top menu. (a) http://cvs.apache.org/~dirkv/commons-site2/index.html They are only expanded when you are on the componets/sanbox page. (b) http://cvs.apache.org/~dirkv/commons-site2/components.html (c) http://cvs.apache.org/~dirkv/commons-site2/sandbox.html On the other general pages and on the component specific pages they are collapsed. (d) http://cvs.apache.org/~dirkv/commons-site2/contributors.html (e) http://cvs.apache.org/~dirkv/commons-site2/dbcp/configuration.html This has the advantage that if a new component is created only a few pages have to be updated (b or c). The [+] is also nice because it is a visual reminder there is more to find behind the item. Option 2: same menu but do not expand the menu on pages b c. Option 3: expand the components menu on a,b,c,d (and move to bottom) Option 4: expand the components sandbox menu on a,b,c,d (and move to bottom) Option 5: expand the components menu on a,b,c,d,e (and move to bottom) Option 6: expand the components sandbox menu on a,b,c,d,e (and move to bottom) My preference is to the current one (option 1). Option 5 6 would require a full site rebuild of all components when a new component is added. Option 3 is not very fair to the sandbox components wanting more visibility to grow. I would put 2 tables with all components on the homepage. Implemented with reusable XML entities the tables will be the same as on the components sanbox pages. Can we then agree on option 1 or 2 if we add these tables on the homepage? Other options? -- Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][site] Site menu proposal
Dirk Verbeeck wrote: OK, most people want the component specific menus the Project Documentation together. http://cvs.apache.org/~dirkv/commons-site2/dbcp/index.html What is left is the question if we want a list of (sandbox) components in the left menu or not. The current proposal (option 1) is to have 2 collapsed menu items in the top menu. (a) http://cvs.apache.org/~dirkv/commons-site2/index.html They are only expanded when you are on the componets/sanbox page. (b) http://cvs.apache.org/~dirkv/commons-site2/components.html (c) http://cvs.apache.org/~dirkv/commons-site2/sandbox.html On the other general pages and on the component specific pages they are collapsed. (d) http://cvs.apache.org/~dirkv/commons-site2/contributors.html (e) http://cvs.apache.org/~dirkv/commons-site2/dbcp/configuration.html This has the advantage that if a new component is created only a few pages have to be updated (b or c). The [+] is also nice because it is a visual reminder there is more to find behind the item. Option 2: same menu but do not expand the menu on pages b c. Option 3: expand the components menu on a,b,c,d (and move to bottom) Option 4: expand the components sandbox menu on a,b,c,d (and move to bottom) Option 5: expand the components menu on a,b,c,d,e (and move to bottom) Option 6: expand the components sandbox menu on a,b,c,d,e (and move to bottom) My preference is to the current one (option 1). Option 5 6 would require a full site rebuild of all components when a new component is added. Option 3 is not very fair to the sandbox components wanting more visibility to grow. 1.) Ideally the site will be rebuilt on a regular basis to keep everything uptodate (ie Once a week would be respectable for the entire commons) so I'm not concerned about when projects are added/removed from the commons as a whole. 2.) It obvious people do not want the components expanded on top of the project documentation, thats what got us here in the first place. I'd vote +1 for Option 6 or +1 on Option 2. (-1 for Options 1,3-5). I would put 2 tables with all components on the homepage. Implemented with reusable XML entities the tables will be the same as on the components sanbox pages. You could (should) use velocity tags in the xdoc's to iterate over the reactor projects and include their contents, using the entities is not optimal for generating a list of the projects. You have to edit the file when you add/remove projects. If you use the reactor, then the list is built off the included project.xml descriptors, this is the same for the navigation, the navigation.xml project list can be built the same way. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [codec] StatefulDecoders
How about we put our minds together and finalize some of this stuff so I can start writing some codecs that can be added back to this project? Yeah definitely, sounds like we're trying to solve the same problem here. I haven't responded to your previous emails because I haven't contributed before and was leaving opinions to those who've actually proven themselves. In general, I have long preferred the pipeline/event model to the approach that Alex had, where it would give data to the codec, and then poll it for Agreed! Mine approach was not the best but have you had a chance at looking at the new interfaces that I sent out with the callbacks. Shall I resend those? I still have them here. I'll comment on them further down. Let me just list the requirements one more time: 1). Interfaces should allow for implementations that perform piece meal decodes - enables implementations to have constant sized processing footprints - enables implementations to have efficient non-blocking and streaming operation Agreed. 2). Easily understood and simple to use Agreed, although needs to be weighed up with any conflicting requirements. 3). Interfaces should in no way shape or form restrict or limit the performance of implementations what ever they may be. Agreed, although without knowing all of these implementations in advance we can never be sure ;-) You're right, my design has no concept of structured content. It was developed to solve a particular problem (ie. efficient streamable data manipulation). If API support for structured content is required then my implementation doesn't (yet) support it. You can build on this separately no? There is no need to have the codec interfaces take this into account other then allow this decoration in the future rather than inhibit it. Yes, I can build on it separately, however a new set of producers and consumers are needed for each type of structured data. I don't see this as a problem because trying to make this too generic may lead to loss of performance and a complicated API. I'll use engine for the want of a better word to describe an element in a pipeline performing some operation on the data passing through it. SEDA calls this a stage btw. Much better :-) With codecs the encoding is variable right? It could be anything. Something has to generate events/callbacks that delimit logical units of the encoding what ever that may be. For some encodings that you mentioned (base64) there may not be a data structure but the unit of encoding must be at least two characters for base64 I think. Please correct me if I'm wrong. 3 byte input 4 byte output for encoding, and 4 byte input 3 byte output for decoding. Input is padded if not a multiple of 3 bytes. So there is some minimum unit size that can range from one byte to anything and this is determined by the codec's encoding and reflected in some form of callback. SAX uses callbacks to allow builders that are content aware do their thing right? Now I'm not suggesting that a base64 codec's encoder/decoder pairs make callbacks on every 2 or single byte (depending on your direction). In the case of such a non-structured decoder the buffer size would be the determining factor or the end of the stream. Agreed. So I think we need to use callbacks to let decoders tell us when they hit some notable event that needs attention whatever that may be. I agree in principle here although I'm not sure that I agree with the structure of callbacks. I'll explain more later. operations. These are pipelines; receiving content on one end, performing operations, and generating events down a chain. More than one event could be generated at any point, and the chain can have multiple paths. This, the pipelining notion, IMHO is overly complicated for building out codec interfaces. The pipeline can be built from the smaller simpler parts we are discussing now. We must try harder to constrain the scope of a codec's definition. Noel as you know I have built server's based on pipelined components before and am trying it all over again. We must spare those wanting to implement simple codecs like base64 from these concepts let alone the language around them. The intended use of codecs by some folks may not be so grandiose. They may simply need it to just convert a byte buffer and be done with it. There is no reason why we should cloud this picture for the simple user. I agree that we definitely don't want to introduce complexity and computational overhead for simple cases. However I think many of the above concepts can be supported without creating complex APIs. I believe these are the interfaces you have previously posted. Let me know if I've got the wrong ones :-)
cvs commit: jakarta-commons/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
rleland 2004/03/08 15:24:25
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
Log:
Bug 17667 Patch and bug report by Alexander Merk
This allows multiple forms to be on the same page
by generating a unique variable name based on form name.
Revision ChangesPath
1.7 +3 -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.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- validateByte.js 2 Feb 2004 23:58:52 - 1.6
+++ validateByte.js 8 Mar 2004 23:24:25 - 1.7
@@ -11,7 +11,8 @@
var focusField = null;
var i = 0;
var fields = new Array();
-oByte = new ByteValidations();
+oByte = eval('new ' + form.name + '_ByteValidations()');
+
for (x in oByte) {
var field = form[oByte[x][0]];
1.6 +3 -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.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- validateCreditCard.js 15 Dec 2003 02:56:57 - 1.5
+++ validateCreditCard.js 8 Mar 2004 23:24:25 - 1.6
@@ -11,7 +11,8 @@
var focusField = null;
var i = 0;
var fields = new Array();
-oCreditCard = new creditCard();
+oCreditCard = eval('new ' + form.name + '_creditCard()');
+
for (x in oCreditCard) {
if ((form[oCreditCard[x][0]].type == 'text' ||
form[oCreditCard[x][0]].type == 'textarea')
1.8 +3 -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.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- validateDate.js 2 Feb 2004 23:58:52 - 1.7
+++ validateDate.js 8 Mar 2004 23:24:25 - 1.8
@@ -11,7 +11,8 @@
var focusField = null;
var i = 0;
var fields = new Array();
- oDate = new DateValidations();
+ oDate = eval('new ' + form.name + '_DateValidations()');
+
for (x in oDate) {
var field = form[oDate[x][0]];
var value = field.value;
1.7 +3 -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.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- validateEmail.js 2 Feb 2004 23:58:52 - 1.6
+++ validateEmail.js 8 Mar 2004 23:24:25 - 1.7
@@ -11,7 +11,8 @@
var focusField = null;
var i = 0;
var fields = new Array();
-oEmail = new email();
+oEmail = eval('new ' + form.name + '_email()');
+
for (x in oEmail) {
var field = form[oEmail[x][0]];
if ((field.type == 'hidden' ||
1.9 +2 -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.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- validateFloat.js 2 Feb 2004 23:58:52 - 1.8
+++ validateFloat.js 8 Mar 2004 23:24:25 - 1.9
@@ -11,7 +11,7 @@
var focusField = null;
var i = 0;
var fields = new Array();
-oFloat = new FloatValidations();
+oFloat =
cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration TestConfigurationXMLDocument.java
epugh 2004/03/08 15:27:09
Modified:configuration/src/java/org/apache/commons/configuration
CompositeConfiguration.java
ConfigurationFactory.java
Added: configuration/src/java/org/apache/commons/configuration
ConfigurationXMLDocument.java
configuration/conf testConfigurationXMLDocument.xml
testDigesterCreateObject.xml
configuration/src/test/org/apache/commons/configuration
TestConfigurationXMLDocument.java
Log:
Java classes and test data for Bug 26944 from Oliver Heger.
Revision ChangesPath
1.8 +6 -2
jakarta-commons/configuration/src/java/org/apache/commons/configuration/CompositeConfiguration.java
Index: CompositeConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/CompositeConfiguration.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- CompositeConfiguration.java 27 Feb 2004 17:41:35 - 1.7
+++ CompositeConfiguration.java 8 Mar 2004 23:27:09 - 1.8
@@ -258,6 +258,8 @@
{
CompositeConfiguration subsetCompositeConfiguration =
new CompositeConfiguration();
+Configuration subConf = null;
+int count = 0;
for (ListIterator i = configList.listIterator(); i.hasNext();)
{
Configuration config = (Configuration) i.next();
@@ -265,9 +267,11 @@
if (subset != null)
{
subsetCompositeConfiguration.addConfiguration(subset);
+subConf = subset;
+count++;
}
}
-return subsetCompositeConfiguration;
+return (count == 1) ? subConf : subsetCompositeConfiguration;
}
/**
* Get a List of strings associated with the given configuration key.
1.9 +7 -20
jakarta-commons/configuration/src/java/org/apache/commons/configuration/ConfigurationFactory.java
Index: ConfigurationFactory.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/ConfigurationFactory.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ConfigurationFactory.java 27 Feb 2004 17:41:35 - 1.8
+++ ConfigurationFactory.java 8 Mar 2004 23:27:09 - 1.9
@@ -154,7 +154,7 @@
{
log.error(IO Exception caught, ioe);
throw new ConfigurationException(IO Exception caught,ioe);
-}
+}
return builder.getConfiguration();
}
/**
@@ -267,7 +267,7 @@
matchString + hierarchicalDom4j,
new
BasePathConfigurationFactory(HierarchicalDOM4JConfiguration.class),
METH_LOAD,
- additional);
+ additional);
setupDigesterInstance(
digester,
matchString + jndi,
@@ -391,17 +391,13 @@
/**
* A base class for digester factory classes. This base class maintains
- * a default class for the objects to be created. It also supports a
- * codeclassName/code attribute for specifying a different class.
+ * a default class for the objects to be created.
* There will be sub classes for specific configuration implementations.
*/
public class DigesterConfigurationFactory
extends AbstractObjectCreationFactory
implements ObjectCreationFactory
{
-/** Constant for the className attribute.*/
-protected static final String ATTR_CLASSNAME = className;
-
/** Actual class to use. */
private Class clazz;
@@ -415,23 +411,14 @@
}
/**
- * Creates an instance of the specified class. If the passed in
- * attributes contain a codeclassName/code attribute, the value of
- * this attribute is interpreted as the full qualified class name of
- * the class to be instantiated. Otherwise the default class is used.
- * @param attribs the attributes
+ * Creates an instance of the specified class.
+ * @param attribs the attributes (ignored)
* @return the new object
* @exception Exception if object creation fails
*/
public Object createObject(Attributes attribs) throws Exception
{
-Class actCls;
-
-int idx = attribs.getIndex(ATTR_CLASSNAME);
-actCls = (idx 0) ? clazz :
-
DO NOT REPLY [Bug 26944] - [configuration] Missing classes after move to commons proper
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=26944. 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=26944 [configuration] Missing classes after move to commons proper [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 23:29 --- Oliver, sorry it took so long, but it is in.. I took the content from example.xml and added it a new howto_xml.xml document.. However, i think the flow of the howto_xml and howto_configurationfactory has been really messed up by myself... We should probably redo those examples.. Maybe merge them back into one document? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration TestConfigurationXMLDocument.java
epugh 2004/03/08 15:42:16 Modified:configuration/src/java/org/apache/commons/configuration ConfigurationXMLDocument.java configuration/src/test/org/apache/commons/configuration TestConfigurationXMLDocument.java Log: Update license to 2.0 Revision ChangesPath 1.4 +14 -52 jakarta-commons/configuration/src/java/org/apache/commons/configuration/ConfigurationXMLDocument.java Index: ConfigurationXMLDocument.java === RCS file: /home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/ConfigurationXMLDocument.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ConfigurationXMLDocument.java 8 Mar 2004 23:27:09 - 1.3 +++ ConfigurationXMLDocument.java 8 Mar 2004 23:42:16 - 1.4 @@ -1,57 +1,19 @@ package org.apache.commons.configuration; -/* - * The Apache Software License, Version 1.1 +/* + * Copyright 2004 The Apache Software Foundation. * - * Copyright (c) 2002-2003 The Apache Software Foundation. All rights - * reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * 1. Redistributions of source code must retain the above copyright - *notice, this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright - *notice, this list of conditions and the following disclaimer in - *the documentation and/or other materials provided with the - *distribution. - * - * 3. The end-user documentation included with the redistribution, if - *any, must include the following acknowledgement: - * This product includes software developed by the - *Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgement may appear in the software itself, - *if and wherever such third-party acknowledgements normally appear. - * - * 4. The names The Jakarta Project, Commons, and Apache Software - *Foundation must not be used to endorse or promote products derived - *from this software without prior written permission. For written - *permission, please contact [EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache - *nor may Apache appear in their names without prior written - *permission of the Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE - * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR - * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, - * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT - * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - * - * - * This software consists of voluntary contributions made by many - * individuals on behalf of the Apache Software Foundation. For more - * information on the Apache Software Foundation, please see - * http://www.apache.org/. + * 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. */ import java.io.IOException; 1.5 +14 -52 jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationXMLDocument.java Index: TestConfigurationXMLDocument.java === RCS file: /home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationXMLDocument.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- TestConfigurationXMLDocument.java 8
RE: Proposal for the Commons Sandbox
Hello, The set up you describe, if at all possible, seems too twisty to me. Here is what you could consider, perhaps one of: (0) Do nothing: you and your users are happy to use Jestr and/or commons-lang. I assume this is a no-go since you posted your message to commons-dev ;-) (1) Simple: Merge Jestr into builder. No functor dependency. (2) Recast Jestr as a sandbox project extending and depending on commons-lang. This is kind of like (1) but with the added overhead of it being an extra project. No matter what, I would start by outlining what additional features this would give commons-lang. I took a brief look at the Jestr page, and I am a bit busy right now (aren't we all!). For example, I noticed something to do with configuring the component from a file, which the builder package does not do for ToStringBuilder. So that's an interesting delta. Instead of making everyone figure out for themselves what the deltas are between [lang] and Jestr, why not provide a list? This way everyone can say, whether or not such and such a feature makes sense to add. Then you can write bugzilla tickets for each new feature and go at it. Side note: Personally, I am no fan of functors. There is no such thing as Smalltalk block in Java, very sad, and trying to emulate such things with interfaces is, IMHO, just too heavy handed and looks very cumbersome syntactically. Cheers, Gary -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 14:56 To: Gary Gregory Subject: RE: Proposal for the Commons Sandbox Hey Gary, Question for you: Supposing that Jestr were to be incorporated into commons.lang.builder, would it be possible to keep the Jestr portions in the sandbox while the rest of commons.lang.* remained in the Commons proper? Jestr depends on Commons Functor (which is sandboxed) and is thus ineligible for Commons proper at this point. Thanks, David -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 15:23:25 -0500 In this case you are building a java.lang.String. Simple answer eh? ;-) The [Reflection]ToStringBuilder is used to create a String based on other Objects. The most common usage is to implement an Object's toString() method with a [Reflection]ToStringBuilder. You can also use the string builder classes to build a String for any object of course. For example, it can be useful for debugging purposes to use a ReflectionToStringBuilder toString to dump the contents of an arbitrary object. For the package as a whole, the term builder applies to the notion of building different kinds of algorithms for us with toString(), equals(), compareTo(), and hashCode(). Builder might not be a great name but it is hard to think of a name that says: Assits in overriding methods that are in Object: toString(), hashCode(), equals(), and also compareTo(). Gary -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 11:13 To: Jakarta Commons Developers List Subject: RE: Proposal for the Commons Sandbox Yes, I think Jestr could be incorporated cleanly into the ToStringBuilder hierarchy, either as a subclass of ToStringBuilder, or as a subclass of ReflectionToStringBuilder. I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term builder a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I building? -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List commons- [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 13:43:51 -0500 Hello, However I think Jestr is a little different from the ToStringBuilder stuff because it isn't necessarily concerned with helping you implement toString() methods; instead, it's more concerned with helping you log *arbitrary* objects, even if you don't have access to their source code to change their toString() methods. Note that the o.a.c.l.builder package also provides the ability to operate on an arbitrary object. Please see: (1) The class ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui l d er/ReflectionToStringBuilder.html (2) The ToStringBuilder methods which forward to ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui l d er/ToStringBuilder.html#reflectionToString(java.lang.Object) Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: [cli] v1 v2 API compatibility
[EMAIL PROTECTED] wrote: John Keyes wrote: I spent today looking at realizing the v1 API with the v2 runtime. After making some progress, I started to wonder was there any compeling reason to do so. Therefore, I propose to branch the v1 code and put it into maintanence mode. This will allow us to merge the v2 branch to the mainline (assuming it gets approval). I don't see this as being much of an overhead but I would like to hear what others think before putting this to a vote. I assume a decision of this nature requires a vote as it is almost like proposing a new subproject. This would also allow us to keep the org.apache.commons.cli package for both versions. Comments? I don't know how many people use CLI v1, but this kind of action can have a huge ripple effect. IMO making backward incompatible changes should be deprecated :-), if the API can't be maintained you should use a different package name ( like cli2 ), to allow people to keep using both versions at the same time. Well the changes were very necessary, unfortunately. We are currently using cli2 as the package name. We can keep this. Since the apis are incompatible and users who chose to upgrade will have to change code anyway - this just add a bit more inconvenience, but at least avoid the upgrade everything or nothing because one small library change. Point taken. -John K Costin - 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: [cli] v1 v2 API compatibility
Gary Gregory wrote: Sorry to be jumping late in the discussion but since I am a Cli 1 user... It seems to me that a solution would be to delivery either: [cli] which is (1) cli2 and cli1 is still available on the site OR (2) cli1.jar+cli2.jar where cli1 is just as it is now, NOT re-implemented on top of cli2. This allows for 0 risk of subtle behavioral changes and 100% backwards compatibility. Not too sure what the difference is between these choices. I assume that both versions are in completely separate packages. Make both versions downloadable from the site. Here is why. I favor (1). This is what I proposed (but using a branch for the cli1 code and using the mainline for the cli2 code). I am cli1 user; I can keep on using cli1 as is. I want to use cli2 with new code. I can migrate from cli1 to cli2 at my leisure. Then I can get rid of cli1.jar (or whatever it is called) for good. Absolutely. We want to minimize the effect on users. This is why I raised the topic in the first place. Thanks for the direction. -John K My 2c, Gary -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, March 08, 2004 13:00 To: [EMAIL PROTECTED] Subject: Re: [cli] v1 v2 API compatibility John Keyes wrote: I spent today looking at realizing the v1 API with the v2 runtime. After making some progress, I started to wonder was there any compeling reason to do so. Therefore, I propose to branch the v1 code and put it into maintanence mode. This will allow us to merge the v2 branch to the mainline (assuming it gets approval). I don't see this as being much of an overhead but I would like to hear what others think before putting this to a vote. I assume a decision of this nature requires a vote as it is almost like proposing a new subproject. This would also allow us to keep the org.apache.commons.cli package for both versions. Comments? I don't know how many people use CLI v1, but this kind of action can have a huge ripple effect. IMO making backward incompatible changes should be deprecated :-), if the API can't be maintained you should use a different package name ( like cli2 ), to allow people to keep using both versions at the same time. Since the apis are incompatible and users who chose to upgrade will have to change code anyway - this just add a bit more inconvenience, but at least avoid the upgrade everything or nothing because one small library change. Costin - 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: [configuration] SubsetConfiguration
Applied! Can you review.. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 5:28 PM To: Jakarta Commons Developers List Subject: Re: [configuration] SubsetConfiguration Here is a new implementation of the SubsetConfiguration: - a null or empty key can now be used to retrieve the subset root element. - subset.getKeys() and subset.getKeys(prefix) are now fixed, previously they returned the keys of the parent configuration and not the keys of the subset. - AbstractConfiguration.getKeys(prefix) has been changed to use a FilterIterator and fix Bug 27427. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] SubsetConfiguration
Oh, one more thing, because I hadn't applied the Locale patch yet, I had to drop those methods from SubsetConfiguration. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 5:28 PM To: Jakarta Commons Developers List Subject: Re: [configuration] SubsetConfiguration Here is a new implementation of the SubsetConfiguration: - a null or empty key can now be used to retrieve the subset root element. - subset.getKeys() and subset.getKeys(prefix) are now fixed, previously they returned the keys of the parent configuration and not the keys of the subset. - AbstractConfiguration.getKeys(prefix) has been changed to use a FilterIterator and fix Bug 27427. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] ConfigurationXMLDocumentTest fails
Oliver, I think I was a little too commit happy.. I thought I ran the tests to verify that the ConfigurationXMLDocument was working properly, but I missed it's testcase, which is now failing. Do you mind looking at it? The patch file applied properly, but maybe something post your creating the patch has changed to cause these errors? ERic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] wrong test for CompositeConfiguration.subset ?
Hi, I'm just trying to do some cleanup, make sure nothing was missed. I checked, and the changes suggested for TestHierarchicalConfiguration and TestCompositeConfiguration have been made.. Nothing else needs doing here, correct? Eric -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Jörg Schaible Sent: Thursday, March 04, 2004 9:03 PM To: [EMAIL PROTECTED] Subject: Re: [configuration] wrong test for CompositeConfiguration.subset ? Emmanuel Bourg wrote: I tracked back the code to the version in Velocity, this was changed in the revision 1.14 of Configuration.java 3 years ago: http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/src/java/or g/apache/velocity/runtime/configuration/Configuration.java?r1= 1.13r2=1.14diff_format=h It looks like a workaround to avoid an IndexOutOfBoundException if the key and the prefix have the same length on calling: key.substring(prefix.length() + 1); This feature is not documented in the javadoc and the subset produced is not useful. Even if it has been around for 3 years I think it's safe to assume nobody relies on this. Fine with me. I think also, it is more consistant to return null. Please apply first my patch of http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27427 to this function. You may just remove afterwards the test for equality. Regards, Jörg - 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 27528] New: - [logging][PATCH] Enable the configuration of date and time format in SimpleLog
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=27528. 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=27528 [logging][PATCH] Enable the configuration of date and time format in SimpleLog Summary: [logging][PATCH] Enable the configuration of date and time format in SimpleLog Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Logging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It would be nice if the user could configure the date and time format used by SimpleLog. I have made patches for SimpleLog and the unittests. The patch enables a new optional configuration property org.apache.commons.logging.simplelog.dateTimeFormat. The property takes a value of a SimpleDateFormat pattern. If the pattern is not specified or is invalid, the default pattern is used. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27528] - [logging][PATCH] Enable the configuration of date and time format in SimpleLog
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=27528. 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=27528 [logging][PATCH] Enable the configuration of date and time format in SimpleLog --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 00:38 --- Created an attachment (id=10714) Patch for SimpleLog.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27528] - [logging][PATCH] Enable the configuration of date and time format in SimpleLog
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=27528. 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=27528 [logging][PATCH] Enable the configuration of date and time format in SimpleLog --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 00:39 --- Created an attachment (id=10715) Patch for unittests - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27528] - [logging][PATCH] Enable the configuration of date and time format in SimpleLog
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=27528. 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=27528 [logging][PATCH] Enable the configuration of date and time format in SimpleLog --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 00:39 --- Created an attachment (id=10716) Patch for unittests - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27528] - [logging][PATCH] Enable the configuration of date and time format in SimpleLog
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=27528. 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=27528 [logging][PATCH] Enable the configuration of date and time format in SimpleLog --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 00:39 --- Created an attachment (id=10717) Patch for unittests - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Release Candidate Build of Commons Logging 1.0.4 Available
Craig R. McClanahan wrote: Quoting Dennis Lundberg [EMAIL PROTECTED]: This might have been brought up before. It's about the dateformat used in SimpleLog. Currently SimpleLog uses /MM/dd, but the ISO 8601 standard, which is spreading rapidly, has this format -MM-dd. On the other hand, changing a thing like this might be concidered breaking backwards compatibility. ISO Dates? Now where have I heard about *those* before? :-). That's what I thought... I think it'd be a good idea to add an *option* so that you can have ISO dates, but have the default behavior be identical to the current in order to avoid breaking backwards compatibility. However, I don't necessarily have an itch to do this myself for the 1.0.4 release (it could easily be added immediately afterwards and thus be available in nightly builds to people that want it). Best way to make that happen would be to post an enhancement request into the issue tracking system (http://issues.apache.org/bugzilla/) -- even better would be a request plus a patch. Sound good? Craig Sure thing. I am done scratching now: http://issues.apache.org/bugzilla/show_bug.cgi?id=27528 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27427] - [configuration] Invalid subsets
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=27427. 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=27427 [configuration] Invalid subsets [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 02:06 --- Hi Eric, it seems you've mixed up this bug report with something else. Neither seems your comment apply to the patch nor is the reported bug fixed in CVS (did you mean 26994 ?). The new SubsetConfiguration of Emmanual Bourgh (http://article.gmane.org/gmane.comp.jakarta.commons.devel/41897) would have made this patch additionally obsolete as already stated in that mail. While I saw, that you stated, that you've applied Emmanuels patch also (http://article.gmane.org/gmane.comp.jakarta.commons.devel/42228), I cannot see anything in CVS. Therefore I've reopened this bug again. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbutils] Bean Handling
The factoring of bean processing in DbUtils doesn't feel right to me. BasicRowProcessor is overwhelmed by support methods for bean conversions. We needed more flexibility with column to property matching so we created the ColumnProcessor interface causing bean handling to be split across multiple classes. My proposal is to move all BasicColumnProcessor methods and bean related BasicRowProcessor methods to a new class called BeanProcessor that would be solely responsible for bean handling. Then we would remove the ColumnProcessor interface and BasicColumnProcessor class as they haven't been released yet. BeanProcessor would use the Template Method pattern so subclasses could override methods like mapColumnsToProperties() with custom implementations. Comments? David __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbutils project.xml
dgraham 2004/03/08 19:05:51
Modified:dbutils/src/test/org/apache/commons/dbutils
BaseTestCase.java
dbutils project.xml
Added: dbutils/src/test/org/apache/commons/dbutils/handlers
ColumnListHandlerTest.java
dbutils/src/java/org/apache/commons/dbutils/handlers
ColumnListHandler.java
Log:
Added ColumnListHandler implementation of ResultSetHandler interface.
PR: 27377
Patches provided by: Péter Bagyinszki
Revision ChangesPath
1.7 +3 -0
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/BaseTestCase.java
Index: BaseTestCase.java
===
RCS file:
/home/cvs/jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/BaseTestCase.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- BaseTestCase.java 28 Feb 2004 00:12:22 - 1.6
+++ BaseTestCase.java 9 Mar 2004 03:05:51 - 1.7
@@ -13,6 +13,7 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
+
package org.apache.commons.dbutils;
import java.math.BigInteger;
@@ -28,6 +29,7 @@
import org.apache.commons.dbutils.handlers.ArrayListHandlerTest;
import org.apache.commons.dbutils.handlers.BeanHandlerTest;
import org.apache.commons.dbutils.handlers.BeanListHandlerTest;
+import org.apache.commons.dbutils.handlers.ColumnListHandlerTest;
import org.apache.commons.dbutils.handlers.MapHandlerTest;
import org.apache.commons.dbutils.handlers.MapListHandlerTest;
import org.apache.commons.dbutils.handlers.ScalarHandlerTest;
@@ -150,6 +152,7 @@
suite.addTestSuite(MapHandlerTest.class);
suite.addTestSuite(MapListHandlerTest.class);
suite.addTestSuite(ScalarHandlerTest.class);
+suite.addTestSuite(ColumnListHandlerTest.class);
suite.addTestSuite(StringTrimmedResultSetTest.class);
suite.addTestSuite(SqlNullCheckedResultSetTest.class);
1.1
jakarta-commons/dbutils/src/test/org/apache/commons/dbutils/handlers/ColumnListHandlerTest.java
Index: ColumnListHandlerTest.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.dbutils.handlers;
import java.sql.SQLException;
import java.util.List;
import org.apache.commons.dbutils.BaseTestCase;
import org.apache.commons.dbutils.ResultSetHandler;
/**
* ColumnListHandlerTest
*/
public class ColumnListHandlerTest extends BaseTestCase {
public ColumnListHandlerTest(String name) {
super(name);
}
public void testHandle() throws SQLException {
ResultSetHandler h = new ColumnListHandler();
List results = (List) h.handle(this.rs);
assertNotNull(results);
assertEquals(ROWS, results.size());
assertEquals(1, results.get(0));
assertEquals(4, results.get(1));
}
public void testColumnIndexHandle() throws SQLException {
ResultSetHandler h = new ColumnListHandler(2);
List results = (List) h.handle(this.rs);
assertNotNull(results);
assertEquals(ROWS, results.size());
assertEquals(2, results.get(0));
assertEquals(5, results.get(1));
}
public void testColumnNameHandle() throws SQLException {
ResultSetHandler h = new ColumnListHandler(Three);
List results = (List) h.handle(this.rs);
assertNotNull(results);
assertEquals(ROWS, results.size());
assertEquals(3, results.get(0));
assertEquals(6, results.get(1));
}
public void testEmptyResultSetHandle() throws SQLException {
ResultSetHandler h = new ColumnListHandler();
List results = (List) h.handle(this.emptyResultSet);
assertNotNull(results);
assertTrue(results.isEmpty());
}
}
1.1
jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/handlers/ColumnListHandler.java
Index: ColumnListHandler.java
DO NOT REPLY [Bug 27377] - ColumnListHandler implementation
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=27377. 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=27377 ColumnListHandler implementation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 03:07 --- Fixed. Thanks for the patches! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27530] New: - Add QueryRunner.batch()
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=27530.
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=27530
Add QueryRunner.batch()
Summary: Add QueryRunner.batch()
Product: Commons
Version: 1.0 Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: DbUtils
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
From commons-dev:
Adkins Kendall wrote:
Has any consideration been given to adding batch update capability?
For
instance, the following method could be added to the QueryRunner class:
/**
* Execute a batch of SQL INSERT, UPDATE, or DELETE queries.
*
* @param conn The connection to use to run the query.
* @param sql The SQL to execute.
* @param params An array of query replacement parameters.
* @return The number of rows updated per statement.
* @throws SQLException
*/
public int[] batchUpdate(Connection conn, String sql, Object[][]
params)
throws SQLException {
PreparedStatement stmt = null;
int[] rows = null;
try {
stmt = this.prepareStatement(conn, sql);
for(int i = 0; i params.length; i++) {
this.fillStatement(stmt, params[i]);
stmt.addBatch();
}
rows = stmt.executeBatch();
} catch (SQLException e) {
this.rethrow(e, sql, params);
} finally {
DbUtils.close(stmt);
}
return rows;
}
David Graham wrote:
I'm fine with adding this to query runner but executeBatch() is marked
as
@since 1.3 so we would need to bump DbUtils' minimum Java level. I
would
shorten the method name to batch() so we would have query(), update()
and
batch() and of course some test cases are needed.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27531] New: - [dbutils] Support bean property to SQL IN parameter mapping
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=27531. 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=27531 [dbutils] Support bean property to SQL IN parameter mapping Summary: [dbutils] Support bean property to SQL IN parameter mapping Product: Commons Version: 1.0 Final Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: DbUtils AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This commons-dev message brings up interesting points: http://www.mail-archive.com/[EMAIL PROTECTED]/msg36011.html Providing a way to map bean properties to SQL IN parameters would round out the bean functionality. We already have ResultSet columns being transferred to bean properties; why not transfer the other way as well? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal for the Commons Sandbox
On Mon, 8 Mar 2004, Gary Gregory wrote: Hello, The set up you describe, if at all possible, seems too twisty to me. Here is what you could consider, perhaps one of: (0) Do nothing: you and your users are happy to use Jestr and/or commons-lang. I assume this is a no-go since you posted your message to commons-dev ;-) (1) Simple: Merge Jestr into builder. No functor dependency. (2) Recast Jestr as a sandbox project extending and depending on commons-lang. This is kind of like (1) but with the added overhead of it being an extra project. If Jestr is going to come to Apache, I believe it would need to do so via the incubator. We can't accept external projects from non-Apache folks straight into Commons, sandbox or otherwise. -- Martin Cooper No matter what, I would start by outlining what additional features this would give commons-lang. I took a brief look at the Jestr page, and I am a bit busy right now (aren't we all!). For example, I noticed something to do with configuring the component from a file, which the builder package does not do for ToStringBuilder. So that's an interesting delta. Instead of making everyone figure out for themselves what the deltas are between [lang] and Jestr, why not provide a list? This way everyone can say, whether or not such and such a feature makes sense to add. Then you can write bugzilla tickets for each new feature and go at it. Side note: Personally, I am no fan of functors. There is no such thing as Smalltalk block in Java, very sad, and trying to emulate such things with interfaces is, IMHO, just too heavy handed and looks very cumbersome syntactically. Cheers, Gary -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 14:56 To: Gary Gregory Subject: RE: Proposal for the Commons Sandbox Hey Gary, Question for you: Supposing that Jestr were to be incorporated into commons.lang.builder, would it be possible to keep the Jestr portions in the sandbox while the rest of commons.lang.* remained in the Commons proper? Jestr depends on Commons Functor (which is sandboxed) and is thus ineligible for Commons proper at this point. Thanks, David -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 15:23:25 -0500 In this case you are building a java.lang.String. Simple answer eh? ;-) The [Reflection]ToStringBuilder is used to create a String based on other Objects. The most common usage is to implement an Object's toString() method with a [Reflection]ToStringBuilder. You can also use the string builder classes to build a String for any object of course. For example, it can be useful for debugging purposes to use a ReflectionToStringBuilder toString to dump the contents of an arbitrary object. For the package as a whole, the term builder applies to the notion of building different kinds of algorithms for us with toString(), equals(), compareTo(), and hashCode(). Builder might not be a great name but it is hard to think of a name that says: Assits in overriding methods that are in Object: toString(), hashCode(), equals(), and also compareTo(). Gary -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 11:13 To: Jakarta Commons Developers List Subject: RE: Proposal for the Commons Sandbox Yes, I think Jestr could be incorporated cleanly into the ToStringBuilder hierarchy, either as a subclass of ToStringBuilder, or as a subclass of ReflectionToStringBuilder. I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term builder a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I building? -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List commons- [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 13:43:51 -0500 Hello, However I think Jestr is a little different from the ToStringBuilder stuff because it isn't necessarily concerned with helping you implement toString() methods; instead, it's more concerned with helping you log *arbitrary* objects, even if you don't have access to their source code to change their toString() methods. Note that the o.a.c.l.builder package also provides the ability to operate on an arbitrary object. Please see: (1) The class ReflectionToStringBuilder: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui l d er/ReflectionToStringBuilder.html (2) The ToStringBuilder
RE: Proposal for the Commons Sandbox
As it appears that Jestr duplicates some lang functionality, I am hoping that a non-project-whole approach can be taken. Perhaps the Jestr author (David) would be interested in improving [lang] by implementing new features in [lang]. So this would not involve any lock-stock-and-barrel Jestr project import but rather writing new lang code inspired by Jestr assuming David is interested. Gary -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 19:29 To: Jakarta Commons Developers List Cc: [EMAIL PROTECTED] Subject: RE: Proposal for the Commons Sandbox On Mon, 8 Mar 2004, Gary Gregory wrote: Hello, The set up you describe, if at all possible, seems too twisty to me. Here is what you could consider, perhaps one of: (0) Do nothing: you and your users are happy to use Jestr and/or commons-lang. I assume this is a no-go since you posted your message to commons-dev ;-) (1) Simple: Merge Jestr into builder. No functor dependency. (2) Recast Jestr as a sandbox project extending and depending on commons-lang. This is kind of like (1) but with the added overhead of it being an extra project. If Jestr is going to come to Apache, I believe it would need to do so via the incubator. We can't accept external projects from non-Apache folks straight into Commons, sandbox or otherwise. -- Martin Cooper No matter what, I would start by outlining what additional features this would give commons-lang. I took a brief look at the Jestr page, and I am a bit busy right now (aren't we all!). For example, I noticed something to do with configuring the component from a file, which the builder package does not do for ToStringBuilder. So that's an interesting delta. Instead of making everyone figure out for themselves what the deltas are between [lang] and Jestr, why not provide a list? This way everyone can say, whether or not such and such a feature makes sense to add. Then you can write bugzilla tickets for each new feature and go at it. Side note: Personally, I am no fan of functors. There is no such thing as Smalltalk block in Java, very sad, and trying to emulate such things with interfaces is, IMHO, just too heavy handed and looks very cumbersome syntactically. Cheers, Gary -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 14:56 To: Gary Gregory Subject: RE: Proposal for the Commons Sandbox Hey Gary, Question for you: Supposing that Jestr were to be incorporated into commons.lang.builder, would it be possible to keep the Jestr portions in the sandbox while the rest of commons.lang.* remained in the Commons proper? Jestr depends on Commons Functor (which is sandboxed) and is thus ineligible for Commons proper at this point. Thanks, David -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Date: Mon, 8 Mar 2004 15:23:25 -0500 In this case you are building a java.lang.String. Simple answer eh? ;-) The [Reflection]ToStringBuilder is used to create a String based on other Objects. The most common usage is to implement an Object's toString() method with a [Reflection]ToStringBuilder. You can also use the string builder classes to build a String for any object of course. For example, it can be useful for debugging purposes to use a ReflectionToStringBuilder toString to dump the contents of an arbitrary object. For the package as a whole, the term builder applies to the notion of building different kinds of algorithms for us with toString(), equals(), compareTo(), and hashCode(). Builder might not be a great name but it is hard to think of a name that says: Assits in overriding methods that are in Object: toString(), hashCode(), equals(), and also compareTo(). Gary -Original Message- From: David Gilliland [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 11:13 To: Jakarta Commons Developers List Subject: RE: Proposal for the Commons Sandbox Yes, I think Jestr could be incorporated cleanly into the ToStringBuilder hierarchy, either as a subclass of ToStringBuilder, or as a subclass of ReflectionToStringBuilder. I would be happy to incorporate it into org.apache.commons.lang.builder, but there's just something about this categorization that bugs me a little: Isn't the term builder a bit misleading here? After all, Jestr doesn't really care if I am building a toString() method or not, and if I am stringifying some legacy or third party class, then what exactly am I building? -- Original Message -- From: Gary Gregory [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List commons- [EMAIL
Re: [HiveMind] nested schemas
That's a good point. I've removed all the references to schemas without a
ids.
A use case would have been an ServiceFactory using BuilderFactory which
chosses at runtime between different implementations. In generaly if you
reuse a service having access to it's parameters-schema is not bad.
Apart of this I am not sure how private even the processing part of a
schema is. Configurations can be accessed by anyone and should therefore
be considered public. There is no way to express 'no stable result'.
Schemas for services are defined in the service-point and not in the
implementation. They are part of the service-interface and implementations
will have to rely on the processing.
IMO that's just a consequence of combining the processing with the
xml-defintion. The public xml-def trags the procssing-result into public.
So while I've strong doubts about this promis on stability I agree that
expressing it explicitly is a good idea. I also agree with you that
HiveMind is build around use-cases and I've to say that all the use cases
I can imagine can also be full-filled if recursion is supported and if
plain elements are returned.
Thank you. Eclosed is my new diff.
On Mon, 8 Mar 2004 17:28:44 -0500, Howard M. Lewis Ship
[EMAIL PROTECTED] wrote:
The act of assigning an id to a schema is, in effect, a promise on the
part of the developer that
the schema (and the Java objects assembled from contributions to that
schema) are stable enough
for others to reuse.
In the case that no id is provided, it may be an oversight, or it may be
that the Java objects are
not reusable.
Can you give me reasonable examples of why you think this change is
necessary? To date, in HiveMind,
everything really has been driven by real experience (generally,
anti-patterns in other software,
but still).
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
http://howardlewisship.com
-Original Message-
From: Christian Essl [mailto:[EMAIL PROTECTED]
Sent: Monday, March 08, 2004 4:07 PM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] nested schemas
Thanks for the hint on schema-id!
I've added it now. Checking and complaining early :).
I removed the configuration-id and service-id atts and have just
schema-id.
However I still want to access schemas even if they don't
provide an id.
Therefore in my current implementation I give each schema
which has no id
set a default id. For configuration schemas 'c:'+config-id,
for service
schemas 's:'+service-id. (This ids can also be used in
schema id-ref=
).
What do you think of that, is this too much change?
Thanks,
Chris
--
Christian Essl
-
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]
--
Christian Essl Index: framework/src/java/org/apache/hivemind/impl/SchemaElement.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/hivemind/framework/src/java/org/apache/hivemind/impl/SchemaElement.java,v
retrieving revision 1.1
diff -u -r1.1 SchemaElement.java
--- framework/src/java/org/apache/hivemind/impl/SchemaElement.java 26 Feb 2004
23:07:40 - 1.1
+++ framework/src/java/org/apache/hivemind/impl/SchemaElement.java 9 Mar 2004
05:45:58 -
@@ -30,6 +30,7 @@
import org.apache.hivemind.schema.ElementModel;
import org.apache.hivemind.schema.Rule;
import org.apache.hivemind.schema.SchemaProcessor;
+import org.apache.hivemind.schema.impl.SchemaContent;
/**
* A wrapper around [EMAIL PROTECTED] org.apache.hivemind.schema.ElementModel} used
@@ -182,5 +183,9 @@
r.end(processor, element);
}
+}
+
+SchemaContent getSchemaContent(){
+ return _model.getSchemaContent();
}
}
Index: framework/src/java/org/apache/hivemind/impl/SchemaProcessorImpl.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/hivemind/framework/src/java/org/apache/hivemind/impl/SchemaProcessorImpl.java,v
retrieving revision 1.1
diff -u -r1.1 SchemaProcessorImpl.java
--- framework/src/java/org/apache/hivemind/impl/SchemaProcessorImpl.java26 Feb
2004 23:07:40 - 1.1
+++ framework/src/java/org/apache/hivemind/impl/SchemaProcessorImpl.java9 Mar
2004 05:45:59 -
@@ -14,19 +14,23 @@
package org.apache.hivemind.impl;
+import java.lang.reflect.Method;
import java.util.ArrayList;
+import java.util.Collections;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.apache.hivemind.ApplicationRuntimeException;
import
DO NOT REPLY [Bug 27524] - Percentile calculation is not correct
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=27524. 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=27524 Percentile calculation is not correct --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 06:20 --- Excel is using a different percentile interpolation definition than what [math] currently uses. Unfortunately, the javadoc and test cases describing the [math] algorithm have been inadvertently removed. [math] uses the index number method with simple linear interpolation as described in the first example here: http://www.math.bcit.ca/faculty/david_sabo/apples/math2441/section4/relstanding/RelStanding.htm The code is working as designed. The reference above also describes the method used by Excel, which is another commonly used algorithm that gives different results. R uses this method as well. I am +1 to changing to the R / Excel method and will make the change (and add complete javadoc) if there are no objections. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@lsd]: jelly-tags/commons-jelly-tags-define failed
To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project commons-jelly-tags-define has an issue affecting it's community integration, and has been outstanding for 6 runs. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/jelly-tags/commons-jelly-tags-define.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Sole jar [/data3/gump/jelly-tags/define/target/commons-jelly-tags-define-20040309.jar] identifier set to project name - Error - Failed with reason build failed - - - - - -- -- G U M P Gump performed this work: Work Name: build_jelly-tags_commons-jelly-tags-define (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 11 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only -Dfinal.name=commons-jelly-tags-define-20040309 jar [Working Directory: /data3/gump/jelly-tags/define] - [junit] at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:642) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:242) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:79) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:236) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) [junit] Caused by: java.lang.NullPointerException [junit] at org.apache.commons.jelly.tags.define.SuperTag.doTag(SuperTag.java:44) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] ... 19 more [junit] Root cause [junit] java.lang.NullPointerException [junit] at org.apache.commons.jelly.tags.define.SuperTag.doTag(SuperTag.java:44) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:79) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) [junit] at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:236) [junit] at org.apache.commons.jelly.tags.core.SetTag.doTag(SetTag.java:90) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:233) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:89) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:59) BUILD FAILED /data3/gump/jelly-tags/define/build.xml:110: Test org.apache.commons.jelly.tags.define.TestJelly failed at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:658) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:613) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:301) at org.apache.tools.ant.Target.performTasks(Target.java:328) at org.apache.tools.ant.Project.executeTarget(Project.java:1215) at org.apache.tools.ant.Project.executeTargets(Project.java:1063) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:188) at org.apache.tools.ant.Main.start(Main.java:152) at org.apache.tools.ant.Main.main(Main.java:235) Total time: 10
Re: [configuration] ConfigurationXMLDocumentTest fails
Okay, I will have a look tonight. Oliver Eric Pugh schrieb: Oliver, I think I was a little too commit happy.. I thought I ran the tests to verify that the ConfigurationXMLDocument was working properly, but I missed it's testcase, which is now failing. Do you mind looking at it? The patch file applied properly, but maybe something post your creating the patch has changed to cause these errors? ERic - 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: [Configuration] IniFile
I doubt many if any use the .ini code in simple-jndi. It's a classic example of some code written for the hell of it. I'd need to test to see what happens with an empty section. Hopefully it'd be linked to an empty string, but pass 'hasValue' tests. Hen On Tue, 9 Mar 2004, [iso-8859-1] Jörg Schaible wrote: Hi Inger, just as a side note: Configurations uses in its examples simple-jndi to demonstrate the JNDI functionality. This library creates an InitialContext for property, XML and ini files in a file structure. May be you can have a look at it, how the [section] problem is solved there, because we can assume, that some users already use it and it would be confuising if your implementation behaves different. Regards, Jörg Inger, Matthew wrote on Wednesday, March 03, 2004 8:10 PM: Any interest in an INI File configuration class? It would read a Windows style .ini file. A sample: [Section1] key1=value1 [Section2] key2=value2 would produce the following properties: Section1/key1=value1 Section2/key2=value2 Unfortunately, empty sections would not be dealt with by the existing state of what i have. - 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: [configuration] SubsetConfiguration
Hi Eric, Eric Pugh wrote on Tuesday, March 09, 2004 1:06 AM: Applied! Can you review.. Eric I don't know, what you've done yesterday night (at least for me), but I cannot see any of Emmanuel's changes in CVS. Look yourself: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/configuration/src/java/org/apache/commons/configuration/ Neither the new SubsectionConfiguration nor any of the files are changed, that shoul have been affected by the patch ... Regards, Jörg -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 5:28 PM To: Jakarta Commons Developers List Subject: Re: [configuration] SubsetConfiguration Here is a new implementation of the SubsetConfiguration: - a null or empty key can now be used to retrieve the subset root element. - subset.getKeys() and subset.getKeys(prefix) are now fixed, previously they returned the keys of the parent configuration and not the keys of the subset. - AbstractConfiguration.getKeys(prefix) has been changed to use a FilterIterator and fix Bug 27427. Emmanuel Bourg - 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 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
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=26070. 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=26070 [RFE] Allow streaming of POST methods via chunked transfer encoding. --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 15:18 --- Mike's patch looks good to me. I've attached a direct replacement for ChunkedOutputStream that buffers writes to avoid tiny chunks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
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=26070. 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=26070 [RFE] Allow streaming of POST methods via chunked transfer encoding. --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 15:19 --- Created an attachment (id=10705) Buffered ChunkedOutputStream - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
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=26070.
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=26070
[RFE] Allow streaming of POST methods via chunked transfer encoding.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-08 15:27 ---
To use the buffered ChunkedOutputStream, one change is required: In
EntityEnclodingMethod, the code:
if (outstream instanceof ChunkedOutputStream) {
((ChunkedOutputStream) outstream).writeClosingChunk();
}
has to be changed to
if (outstream instanceof ChunkedOutputStream) {
((ChunkedOutputStream) outstream).finish();
}
finish() flushes the cache as well writes the final chunk.
Thanks
Moh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
small fix to HttpConnection
I've come across a minor problem with the ConnectionTimeoutException.
The exception isn't serializable because it is declared as an non static
inner class to HttpConnection, which in turn has references to all maner of
goodies.
It becomes a problem when http client is used in a J2EE application and the
Exception gets thrown as a root cause out of an EJB.
FIX:
// -- Timeout Exception
/**
* Signals that a timeout occured while opening the socket.
*/
public static class ConnectionTimeoutException extends IOException {
/** Create an instance */
public ConnectionTimeoutException() {
}
}
Garet Davis
Confidentiality: This email and its attachments are intended for the above
named only and may be confidential. If they have come to you in error you
must take no action based on them, nor must you copy or show them to
anyone; please reply to this email and highlight the error.
Viruses: Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure that they are actually
virus-free.
Brokerage services provided by TD Waterhouse Investor Services (Europe)
Limited (a subsidiary of The Toronto-Dominion Bank). Authorised and
regulated by the Financial Services Authority (FSA registered number
141282), member of the London Stock Exchange and OFEX. Incorporated in
England and Wales under registration number 2101863. Registered office:
Exchange Court, Duncombe Street, Leeds LS1 4AX. Banking services provided
by TD Waterhouse Bank N.V. authorised and regulated by De Nederlandsche
Bank and the Financial Services Authority for UK Business (FSA registered
number 216791). Incorporated in the Netherlands and registered as a branch
in England and Wales under branch registration number BR006780.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27242] - Socket Closed IOException thrown by HttpConnection
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=27242. 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=27242 Socket Closed IOException thrown by HttpConnection [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 16:34 --- Patch committed to the 2.0 branch. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
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=26070. 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=26070 [RFE] Allow streaming of POST methods via chunked transfer encoding. --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 18:57 --- Created an attachment (id=10706) patch that includes Oleg's suggestions without the test case - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26070] - [RFE] Allow streaming of POST methods via chunked transfer encoding.
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=26070. 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=26070 [RFE] Allow streaming of POST methods via chunked transfer encoding. --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 20:40 --- Mohammad, Cool. But test cases still need to be provided, as the ChunkedOutputStream class has virtually no test case coverage at all. It's not fun, but it needs to be done. Again, I can take it from here, but if you contibuted a few test cases, it would be very welcome. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: small fix to HttpConnection
Gareth,
In the development version of HttpClient (which will eventually become
3.0) ConnectionTimeoutException is no longer an inner class of
HttpConnection.
Folks, do you see any reasons for not making ConnectionTimeoutException
static in the 2.0 branch?
Oleg
On Mon, 2004-03-08 at 16:33, [EMAIL PROTECTED] wrote:
I've come across a minor problem with the ConnectionTimeoutException.
The exception isn't serializable because it is declared as an non static
inner class to HttpConnection, which in turn has references to all maner of
goodies.
It becomes a problem when http client is used in a J2EE application and the
Exception gets thrown as a root cause out of an EJB.
FIX:
// -- Timeout Exception
/**
* Signals that a timeout occured while opening the socket.
*/
public static class ConnectionTimeoutException extends IOException {
/** Create an instance */
public ConnectionTimeoutException() {
}
}
Garet Davis
Confidentiality: This email and its attachments are intended for the above
named only and may be confidential. If they have come to you in error you
must take no action based on them, nor must you copy or show them to
anyone; please reply to this email and highlight the error.
Viruses: Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure that they are actually
virus-free.
Brokerage services provided by TD Waterhouse Investor Services (Europe)
Limited (a subsidiary of The Toronto-Dominion Bank). Authorised and
regulated by the Financial Services Authority (FSA registered number
141282), member of the London Stock Exchange and OFEX. Incorporated in
England and Wales under registration number 2101863. Registered office:
Exchange Court, Duncombe Street, Leeds LS1 4AX. Banking services provided
by TD Waterhouse Bank N.V. authorised and regulated by De Nederlandsche
Bank and the Financial Services Authority for UK Business (FSA registered
number 216791). Incorporated in the Netherlands and registered as a branch
in England and Wales under branch registration number BR006780.
-
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 27366] - GetMethod.getResponseBodyAsStream() .available() could return content-length
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=27366. 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=27366 GetMethod.getResponseBodyAsStream() .available() could return content-length --- Additional Comments From [EMAIL PROTECTED] 2004-03-08 21:16 --- I do not think we should violate standard Java API even in such a subtle manner. The purpose of InputStream#available() method is different and we should not get too creative about Java API. I agree that the available() method is not documented to mean length of stream, however even Java's own ProgressMonitorInputStream uses it this way. Gosling wrote that class, and in it he sets size = available(). If available() only returns the amount of data currently buffered, the ProgressMonitor does nothing useful. I guess it would have been nice if the InputStream base class had a length() method as well. Anyway, I can implement the behavior by writing an extension class, so no need for you to violate the API in HttpClient. Feel free to close this enhancement request, and thanks for your consideration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27366] - GetMethod.getResponseBodyAsStream() .available() could return content-length
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=27366. 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=27366 GetMethod.getResponseBodyAsStream() .available() could return content-length --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 00:27 --- I agree with Oleg. Making available() return the content length, though useful, would be pretty non- standard. Making getResponseContentLength() public is the way to go. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: small fix to HttpConnection
Static works for me.
Mike
On Mar 8, 2004, at 4:03 PM, Oleg Kalnichevski wrote:
Gareth,
In the development version of HttpClient (which will eventually become
3.0) ConnectionTimeoutException is no longer an inner class of
HttpConnection.
Folks, do you see any reasons for not making ConnectionTimeoutException
static in the 2.0 branch?
Oleg
On Mon, 2004-03-08 at 16:33, [EMAIL PROTECTED] wrote:
I've come across a minor problem with the ConnectionTimeoutException.
The exception isn't serializable because it is declared as an non
static
inner class to HttpConnection, which in turn has references to all
maner of
goodies.
It becomes a problem when http client is used in a J2EE application
and the
Exception gets thrown as a root cause out of an EJB.
FIX:
// -- Timeout Exception
/**
* Signals that a timeout occured while opening the socket.
*/
public static class ConnectionTimeoutException extends
IOException {
/** Create an instance */
public ConnectionTimeoutException() {
}
}
Garet Davis
Confidentiality: This email and its attachments are intended for the
above
named only and may be confidential. If they have come to you in
error you
must take no action based on them, nor must you copy or show them to
anyone; please reply to this email and highlight the error.
Viruses: Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with
good
computing practice the recipient should ensure that they are actually
virus-free.
Brokerage services provided by TD Waterhouse Investor Services
(Europe)
Limited (a subsidiary of The Toronto-Dominion Bank). Authorised and
regulated by the Financial Services Authority (FSA registered number
141282), member of the London Stock Exchange and OFEX. Incorporated in
England and Wales under registration number 2101863. Registered
office:
Exchange Court, Duncombe Street, Leeds LS1 4AX. Banking services
provided
by TD Waterhouse Bank N.V. authorised and regulated by De
Nederlandsche
Bank and the Financial Services Authority for UK Business (FSA
registered
number 216791). Incorporated in the Netherlands and registered as a
branch
in England and Wales under branch registration number BR006780.
-
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]
Having Trouble with MultipartPostMethod
Greetings, Having some trouble with transferring a file to another server. Here's the flow: User submits excel doc to ServerA ServerA get post, creates MultipartPost and posts to ServerB. ServerB saves the file received, but when opened the encoding is all wrong. The data is there but No Alderan Submitting the file directly to ServerA or ServerB is fine. The file can be read by excel. From what I can tell, I'm doing something incorrectly with creation of the MultipartPost before transmission to the other server. Here's some code of what I'm doing: MultipartPostMethod method = new MultipartPostMethod(buildURL(getPath())); method.setFollowRedirects(false); ... ... MultiPartRequestWrapper request = ServletActionContext.getMultiPartRequest(); fileForUpload = request.getFile(FILENAME_FIELD); FilePart p = new FilePart(fileForUpload.getName(), fileForUpload,null, null); p.setTransferEncoding(null); method.addPart(p); ServerA is IIS:Tomcat 4.1.29 SeverB is WebLogic8.1 jdk 1.4.1 Thanks, eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
