Re: [vfs] parsing uri
As you might have seen I implemented the plugin-resolve-stuff. Now we could extend VFS by simply drop a jar into the classpath and if we find a /META-INF/vfs-plugins.xml it would be added. That way we could keep the VFS core slim and could provide extension jars to allow whatever we can think of. I think this is a good compromise. Is this the point of view that I am trying to compromise with? We should add everything to vfs that seems at least remotely useful or if not useful then at least somewhat cool. And if at somepoint something we added is no longer neither useful nor cool we still keep it around to keep vfs backward compatible. Did I get this right? My point of view is: We should clearly and explicitly define the scope of vfs to be an excellent api to filesystems in general in heterogenous and distributed environment. We should write elegant, logicallly correct and well documented piece of software to do that. And make it extremely robust. So the compromise is this (please confirm): We make all providers to be pluggable so that there is the vfs-core with maybe one provider for logical testing of the core. And a bunch of provider plugins nicely packaged so that you can just grab the once you need and ignore the rest. And the core will not get any extra quirks because it would be nice when doing something with hibernate through vfs. So, yes, I think this could be a good compromise between the conservatists (me) and the liberal (them). Note that politically I am liberal but logically I am conservatist. But I already talked about, think of accessing your mailfolder through an imap provider and your mailcontent through an mime provider. e.g. mime:imap://[EMAIL PROTECTED]/INBOX/mail9012718!/part1.txt Sooner or later, this might happen ... and why not - its cool, isnt it? Our ideas of coolness slightly differ. My idea of coolness would be that the imap protocol would be better defined and more to the point (pop3 was much better in this). I remember the times when I was planning on accessing lotus notes through it's imap interface that supposedly could give you a hierarchical representation of notes databases. Here's a new cool provider idea for vfs. Lotus Notes provider that uses the imap service of notes. This way you could nicely present notes documents and forms as files and folders. And write a few books about the possible semantics. Plus since notes is commercial one could actually make a few dollars out of it. So you get the point. Not all that glitters is gold. But sometimes all we really want and need is just the glitter :) - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
Hello! So the compromise is this (please confirm): We make all providers to be pluggable so that there is the vfs-core with maybe one provider for logical testing of the core. And a bunch of provider plugins nicely packaged so that you can just grab the once you need and ignore the rest. Yes! Though I am not sure what the core should be. Maybe we would define the current state as core? VFS in its current packaging is widely used and accepted. Every new filesystem will be extra packaged and only if the community might find it useful a voting could start to decide if we put it into the core. And the core will not get any extra quirks because it would be nice when doing something with hibernate through vfs. YES! And I hope my progress so far made clear that I am definitely would NOT put some quirks into VFS. In fact I would say I am VERY conservative in the stuff I do. All I have done so far was to stabilize and complete VFS: *) cache *) RandomAccessContent *) compressed files *) filename parsing *) plugin *) now and then (more then then now ;-) ) a little bit documentation After every change I let VFS settle down a sufficient time period to gave everyone a chance to test and report errors. So you get the point. Not all that glitters is gold. But sometimes all we really want and need is just the glitter :) And sometimes we just find some spare minutes and would like to experiment a little bit - even if the result is glitter, maybe for the time being it become gold. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] parsing uri
And sometimes we just find some spare minutes and would like to experiment a little bit I have absolutely nothing against experimenting and coding all kinds of weird and useful things for your own purposes. I was just talking about what should be included into vfs. even if the result is glitter, maybe for the time being it become gold. The difference between gold and glitter is that the good feeling that gold gives lasts long. With glitter it only lasts a moment. YES! And I hope my progress so far made clear that I am definitely would NOT put some quirks into VFS. In fact I would say I am VERY conservative in the stuff I do. 12 points ... Mario. - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-207) http:get causes a null pointer exception
http:get causes a null pointer exception Key: JELLY-207 URL: http://issues.apache.org/jira/browse/JELLY-207 Project: jelly Type: Bug Components: taglib.http Environment: define:taglib Reporter: Frank Cornelis Attachments: SessionTag-static-httpclient.patch http:get causes a null pointer exception when used within define:tag with a surrounding http:session When a http:get that lives inside define:tag find a parent http:session, which was defined inside define:taglib, then http:get creates a new SessionTag object, which an unset httpclient, and tries to use it. This cause a null pointer exception. Making the _httpClient static inside the SessionTag solves to problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JELLY-207) http:get causes a null pointer exception
[ http://issues.apache.org/jira/browse/JELLY-207?page=history ] Frank Cornelis updated JELLY-207: - Attachment: SessionTag-static-httpclient.patch This patch fixes the problem. http:get causes a null pointer exception Key: JELLY-207 URL: http://issues.apache.org/jira/browse/JELLY-207 Project: jelly Type: Bug Components: taglib.http Environment: define:taglib Reporter: Frank Cornelis Attachments: SessionTag-static-httpclient.patch http:get causes a null pointer exception when used within define:tag with a surrounding http:session When a http:get that lives inside define:tag find a parent http:session, which was defined inside define:taglib, then http:get creates a new SessionTag object, which an unset httpclient, and tries to use it. This cause a null pointer exception. Making the _httpClient static inside the SessionTag solves to problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-207) http:get causes a null pointer exception
[ http://issues.apache.org/jira/browse/JELLY-207?page=comments#action_61880 ] dion gillard commented on JELLY-207: I'm not sure this is the right solution. All the get tags would then share the same session regardless of their nesting. http:get causes a null pointer exception Key: JELLY-207 URL: http://issues.apache.org/jira/browse/JELLY-207 Project: jelly Type: Bug Components: taglib.http Environment: define:taglib Reporter: Frank Cornelis Attachments: SessionTag-static-httpclient.patch http:get causes a null pointer exception when used within define:tag with a surrounding http:session When a http:get that lives inside define:tag find a parent http:session, which was defined inside define:taglib, then http:get creates a new SessionTag object, which an unset httpclient, and tries to use it. This cause a null pointer exception. Making the _httpClient static inside the SessionTag solves to problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Latka
Hi there, I recently installed the Commons-Latka utility on my PC, but I'm having problems running the sample test. Actually, the test seems to run fine, but it fails. C:\Latka\binlatka file../tests/samples/TestCommonsWebsite.xml TEST SUITE FAILED 0 requests 0 passed 0 failed 0 skipped 0 errors Thank you very much C:\Latka\bin I'd really appreciate any ideas you may have on this as I couldn't find much help documentation. Cheers, Sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JELLY-207) http:get causes a null pointer exception
Exactly, nesting sessions should be pointless. There should be only one global httpclient when you use http:session. dion gillard (JIRA) wrote: [ http://issues.apache.org/jira/browse/JELLY-207?page=comments#action_61880 ] dion gillard commented on JELLY-207: I'm not sure this is the right solution. All the get tags would then share the same session regardless of their nesting. http:get causes a null pointer exception Key: JELLY-207 URL: http://issues.apache.org/jira/browse/JELLY-207 Project: jelly Type: Bug Components: taglib.http Environment: define:taglib Reporter: Frank Cornelis Attachments: SessionTag-static-httpclient.patch http:get causes a null pointer exception when used within define:tag with a surrounding http:session When a http:get that lives inside define:tag find a parent http:session, which was defined inside define:taglib, then http:get creates a new SessionTag object, which an unset httpclient, and tries to use it. This cause a null pointer exception. Making the _httpClient static inside the SessionTag solves to problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r159615 - in jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient: HttpMethodDirector.java auth/AuthChallengeProcessor.java
Author: olegk
Date: Thu Mar 31 09:28:59 2005
New Revision: 159615
URL: http://svn.apache.org/viewcvs?view=revrev=159615
Log:
Some extra debug log entries for the authenticaton process
Contributed by Oleg Kalnichevski
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/AuthChallengeProcessor.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java?view=diffr1=159614r2=159615
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpMethodDirector.java
Thu Mar 31 09:28:59 2005
@@ -188,6 +188,7 @@
}
if (isAuthenticationNeeded(method)) {
if (processAuthenticationResponse(method)) {
+LOG.debug(Retry authentication);
retry = true;
}
}
@@ -668,6 +669,7 @@
Map challenges = AuthChallengeParser.parseChallenges(
method.getResponseHeaders(WWW_AUTH_CHALLENGE));
if (challenges.isEmpty()) {
+LOG.debug(Authentication challenge(s) not found);
return false;
}
AuthScheme authscheme = null;
@@ -689,8 +691,11 @@
AuthScope authscope = new AuthScope(
host, port,
authscheme.getRealm(),
-authscheme.getSchemeName());
-
+authscheme.getSchemeName());
+
+if (LOG.isDebugEnabled()) {
+LOG.debug(Authentication scope: + authscope);
+}
if (authstate.isAuthAttempted() authscheme.isComplete()) {
// Already tried and failed
Credentials credentials = promptForCredentials(
@@ -731,6 +736,7 @@
Map proxyChallenges = AuthChallengeParser.parseChallenges(
method.getResponseHeaders(PROXY_AUTH_CHALLENGE));
if (proxyChallenges.isEmpty()) {
+LOG.debug(Proxy authentication challenge(s) not found);
return false;
}
AuthScheme authscheme = null;
@@ -749,6 +755,9 @@
authscheme.getRealm(),
authscheme.getSchemeName());
+if (LOG.isDebugEnabled()) {
+LOG.debug(Proxy authentication scope: + authscope);
+}
if (authstate.isAuthAttempted() authscheme.isComplete()) {
// Already tried and failed
Credentials credentials = promptForProxyCredentials(
@@ -837,6 +846,7 @@
final HttpParams params,
final AuthScope authscope)
{
+LOG.debug(Credentials required);
Credentials creds = null;
CredentialsProvider credProvider =
(CredentialsProvider)params.getParameter(CredentialsProvider.PROVIDER);
@@ -853,6 +863,8 @@
LOG.debug(authscope + new credentials given);
}
}
+} else {
+LOG.debug(Credentials provider not available);
}
return creds;
}
@@ -862,6 +874,7 @@
final HttpParams params,
final AuthScope authscope)
{
+LOG.debug(Proxy credentials required);
Credentials creds = null;
CredentialsProvider credProvider =
(CredentialsProvider)params.getParameter(CredentialsProvider.PROVIDER);
@@ -878,6 +891,8 @@
LOG.debug(authscope + new credentials given);
}
}
+} else {
+LOG.debug(Proxy credentials provider not available);
}
return creds;
}
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/AuthChallengeProcessor.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/AuthChallengeProcessor.java?view=diffr1=159614r2=159615
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/AuthChallengeProcessor.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/auth/AuthChallengeProcessor.java
Thu Mar 31 09:28:59 2005
@@ -158,6 +158,7 @@
authorization challenge expected, but not found);
}
authscheme.processChallenge(challenge);
+LOG.debug(Authorization challenge processed);
return authscheme;
}
}
[net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
Two patches to make the FTP timestamp parsing tests pass also on
non-english systems.
I'm not sure if this is the best way to fix those issues, though.
Rgds,
Neeme
Index: FTPTimestampParserImplTest.java
===
--- FTPTimestampParserImplTest.java (revision 159615)
+++ FTPTimestampParserImplTest.java (working copy)
@@ -15,6 +15,7 @@
*/
package org.apache.commons.net.ftp.parser;
+import java.text.DateFormatSymbols;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
@@ -73,8 +74,19 @@
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+// assume we are FTPing a server in Chicago, two hours ahead of
+// L. A.
+FTPClientConfig config =
+new FTPClientConfig(FTPClientConfig.SYST_UNIX);
+config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
+config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
+// 2 hours difference
+config.setServerTimeZoneId(America/Chicago);
+parser.configure(config);
+
+
SimpleDateFormat sdf =
- new
SimpleDateFormat(parser.getRecentDateFormatString());
+ new
SimpleDateFormat(parser.getRecentDateFormatString(),
parser.getRecentDateFormat().getDateFormatSymbols());
// assume we're in the US Pacific Time Zone
TimeZone tzla = TimeZone.getTimeZone(America/Los_Angeles);
sdf.setTimeZone(tzla);
@@ -84,17 +96,6 @@
String fmtTimePlusThreeHours = sdf.format(threeHoursFromNow);
- // assume we are FTPing a server in Chicago, two hours ahead of
- // L. A.
- FTPClientConfig config =
- new FTPClientConfig(FTPClientConfig.SYST_UNIX);
- config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
-
config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
- // 2 hours difference
- config.setServerTimeZoneId(America/Chicago);
- parser.configure(config);
-
-
try {
Calendar parsed =
parser.parseTimestamp(fmtTimePlusOneHour);
// the only difference should be the two hours
@@ -103,7 +104,7 @@
(long)TWO_HOURS_OF_MILLISECONDS,
cal.getTime().getTime() -
parsed.getTime().getTime());
} catch (ParseException e){
- fail(Unable to parse);
+ fail(Unable to parse + fmtTimePlusOneHour);
}
//but if the file's timestamp is THREE hours ahead of now, that
should
@@ -123,13 +124,18 @@
public void testParser() {
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+Calendar cal = Calendar.getInstance();
+cal.set(Calendar.YEAR, 2002);
+cal.set(Calendar.MONTH, 1);
+cal.set(Calendar.DAY_OF_MONTH, 22);
+SimpleDateFormat sdf = new SimpleDateFormat(MMM dd );
try {
- parser.parseTimestamp(feb 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.default);
}
try {
- parser.parseTimestamp(fév 22 2002);
+ parser.parseTimestamp(f�v 22 2002);
fail(should.have.failed.to.parse.default);
} catch (ParseException e) {
// this is the success case
@@ -140,14 +146,17 @@
config.setRecentDateFormatStr(d MMM HH:mm);
config.setServerLanguageCode(fr);
parser.configure(config);
+DateFormatSymbols dfs = FTPClientConfig.lookupDateFormatSymbols(fr);
+sdf = new SimpleDateFormat(MMM d , dfs);
try {
- parser.parseTimestamp(déc 22 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
fail(incorrect.field.order);
} catch (ParseException e) {
// this is the success case
}
+sdf = new SimpleDateFormat(d MMM , dfs);
try {
- parser.parseTimestamp(22 déc 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.french);
}
@@ -159,27 +168,28 @@
// this is the success case
}
try {
- parser.parseTimestamp(29 fév 2002);
+
[RESULT] [VOTE]Configuration release 1.1
The commons community has voted to release commons-configuration 1.1. Here are the results in detail: +1: 3 Emmanuel Bourg Dion Gillard Oliver Heger +/-0 : none -1: none I am going to cut the release at the coming weekend. Oliver Oliver Heger wrote: Dear community, since the 1.0 release of [configuration] we made some progress and added a couple of new features. To make these available for a larger user base, I think it is time to cut out a new 1.1 release. A complete list of changes since the 1.0 releaes can be found here: http://www.apache.org/~oheger/commons-configuration-1.1rc3-docs/changes-report.html. In the process of preparing the release there have been some release candidates. The latest is 1.1rc3, which can be inspected at http://www.apache.org/~oheger/commons-configuration-1.1rc3 (the tag for 1.1RC3 is named CONFIGURATION_1_1RC3). Here is my +1! Oliver - 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 29716] - [configuration] Disabling string splitting
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=29716. 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=29716 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 20:16 --- This idea is certainly worth a thought, but it may cause other problems: In the hierarchical configurations an extended syntax for querying properties is supported, which allows to address certain elements based on their index. So you can have something like config.getString(mylist.entry(1)); If we did not parse values when they are inserted, the implementation of this feature would be much more complicated. Situation becomes even worse when we want to support other query languages, e.g. XPath. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32450] - [io] Add cancel() to Finder
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=32450.
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=32450
--- Additional Comments From [EMAIL PROTECTED] 2005-03-31 20:45 ---
on way to work around this problem is to us a CancellingListener
CancelingListener implements FindListener extends RuntimeException{
boolean cancelled = false;
public void fileFound(FindEvent fe) { check(); }
public void directoryStarted(FindEvent fe) { check(); }
public void directoryFinished(FindEvent fe) { check(); }
private void check() {
if(cancelled)
throw this;
}
public void doCancel(){
cancelled = true;
}
}
and in you find call
-
CancelingListener clistener = new CancelingListener();
try{
finder.addListener(clistener);
find(dir);
}catch(CancelingListener cl){
// find() was cancelled when another thread
// or listener calls clistener.doCancel();
}
-
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r159628 - jakarta/commons/proper/betwixt/trunk/project.xml
Author: rdonkin
Date: Thu Mar 31 11:28:18 2005
New Revision: 159628
URL: http://svn.apache.org/viewcvs?view=revrev=159628
Log:
Pointed deployment at minotaur
Modified:
jakarta/commons/proper/betwixt/trunk/project.xml
Modified: jakarta/commons/proper/betwixt/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/project.xml?view=diffr1=159627r2=159628
==
--- jakarta/commons/proper/betwixt/trunk/project.xml (original)
+++ jakarta/commons/proper/betwixt/trunk/project.xml Thu Mar 31 11:28:18 2005
@@ -43,7 +43,7 @@
gumpRepositoryIdjakarta/gumpRepositoryId
issueTrackingUrlhttp://issues.apache.org/bugzilla//issueTrackingUrl
- siteAddressjakarta.apache.org/siteAddress
+ siteAddresscvs.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r159631 - jakarta/commons/proper/betwixt/trunk/xdocs/powered.xml
Author: rdonkin Date: Thu Mar 31 11:42:26 2005 New Revision: 159631 URL: http://svn.apache.org/viewcvs?view=revrev=159631 Log: Added another powered by. Reported by Cristoph Gaffga. Modified: jakarta/commons/proper/betwixt/trunk/xdocs/powered.xml Modified: jakarta/commons/proper/betwixt/trunk/xdocs/powered.xml URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/betwixt/trunk/xdocs/powered.xml?view=diffr1=159630r2=159631 == --- jakarta/commons/proper/betwixt/trunk/xdocs/powered.xml (original) +++ jakarta/commons/proper/betwixt/trunk/xdocs/powered.xml Thu Mar 31 11:42:26 2005 @@ -57,6 +57,15 @@ A dynamic self-publishing classifieds system utilizing Betwixt for caching ads as xml /td /tr + tr + tda href=http://www.triplemind.com/;Triplemind Vacation Homes (Commercial)/a/td + td + An Application Service for tourist information systems using + Betwixt to convert business logic output to XML for tranformation to + websites. References for the App are a href=http://www.unterkunft.de;Unterkunft.de/a + and a href=http://www.apartments.de;Apartments.de/a. + /td + /tr /table /subsection /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] [nag] Please commit stuff for DispatchChain
Sean, I don't mind applying these changes so long as the other committers agree that this would be a good fit. Last I heard, there are still questions or concerns about adding this. I have not been able to find the time to look any deeper into this, so I can't argue one way or the other. Sorry. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, March 30, 2005 1:36 PM Subject: Re: [chain] [nag] Please commit stuff for DispatchChain I know its been a while since we discussed this ... but I would like to bring up the issue of DispatchChain again. I have a pressing need for something like this in my current application. I need to go ahead and move it into our project codebase or have it added to commons-chain. No hard feelings if I cannot convince you that this is useful. I will briefly summarize my arguments again. The dispatch chain allows you to compose a chain of commands where the command method can be something other than execute. It will always have the same arguments and it will always be the same for every command in the chain. I think the fact that it is always the same method for every command in the chain is a key point here. Its still the CoR pattern. There is nothing special about the name of the execute method, the pattern just requires a consistent method. If you do not accept this line of reasoning then I would suggest that DispatchLookupCommand be removed from the codebase as well. I don't think you can justify one and not the other. Finally, its in the generic package so its entirely optional if you don't want to use it. I'd like to resolve this ASAP so I can go forward on my project here at work. Please give some thought to my arguments. As I said earlier, I will accept the decision of the group if the group cannot be persuaded. Regards, sean On Fri, 14 Jan 2005 16:09:11 -0500, Sean Schofield [EMAIL PROTECTED] wrote: My original post to bugzilla didn't generate any responses. I figured once I wrote something and started pestering for a commit that would get the discussion going ;-) I will await your guys feedback once you've had a chance to think about use cases, etc. Let me know if you have any questions. sean On Fri, 14 Jan 2005 11:37:47 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:20 AM -0800 1/14/05, Craig McClanahan wrote: I plead guilty to being lukewarm (is lukecold a word? :-) about DispatchChain and friends being part of the standard chain package -- I'd like to spend some time tomorrow (Saturday) looking at the code and seeing if I buy in to Sean's use cases. This has been my hesitation too. Since I haven't yet had a use case for it, it seems a bit heavy for inclusion in the core library. I wouldn't veto it, but it's why I have been hesitant. Like Craig, I haven't looked very carefully at it, so I haven't spoken up yet. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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]
svn commit: r159632 - jakarta/commons/proper/betwixt/trunk
Author: rdonkin Date: Thu Mar 31 11:48:38 2005 New Revision: 159632 URL: http://svn.apache.org/viewcvs?view=revrev=159632 Log: Improved ignores Modified: jakarta/commons/proper/betwixt/trunk/ (props changed) Propchange: jakarta/commons/proper/betwixt/trunk/ -- --- svn:ignore (original) +++ svn:ignore Thu Mar 31 11:48:38 2005 @@ -9,3 +9,4 @@ .classpath lib junit*.properties +javadoc* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] [nag] Please commit stuff for DispatchChain
At 2:42 PM -0500 3/31/05, James Mitchell wrote: Sean, I don't mind applying these changes so long as the other committers agree that this would be a good fit. Last I heard, there are still questions or concerns about adding this. I have not been able to find the time to look any deeper into this, so I can't argue one way or the other. I'm at +0 right now -- I don't feel strongly enough about my earlier reservations to put up a fuss. Joe Sorry. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, March 30, 2005 1:36 PM Subject: Re: [chain] [nag] Please commit stuff for DispatchChain I know its been a while since we discussed this ... but I would like to bring up the issue of DispatchChain again. I have a pressing need for something like this in my current application. I need to go ahead and move it into our project codebase or have it added to commons-chain. No hard feelings if I cannot convince you that this is useful. I will briefly summarize my arguments again. The dispatch chain allows you to compose a chain of commands where the command method can be something other than execute. It will always have the same arguments and it will always be the same for every command in the chain. I think the fact that it is always the same method for every command in the chain is a key point here. Its still the CoR pattern. There is nothing special about the name of the execute method, the pattern just requires a consistent method. If you do not accept this line of reasoning then I would suggest that DispatchLookupCommand be removed from the codebase as well. I don't think you can justify one and not the other. Finally, its in the generic package so its entirely optional if you don't want to use it. I'd like to resolve this ASAP so I can go forward on my project here at work. Please give some thought to my arguments. As I said earlier, I will accept the decision of the group if the group cannot be persuaded. Regards, sean On Fri, 14 Jan 2005 16:09:11 -0500, Sean Schofield [EMAIL PROTECTED] wrote: My original post to bugzilla didn't generate any responses. I figured once I wrote something and started pestering for a commit that would get the discussion going ;-) I will await your guys feedback once you've had a chance to think about use cases, etc. Let me know if you have any questions. sean On Fri, 14 Jan 2005 11:37:47 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:20 AM -0800 1/14/05, Craig McClanahan wrote: I plead guilty to being lukewarm (is lukecold a word? :-) about DispatchChain and friends being part of the standard chain package -- I'd like to spend some time tomorrow (Saturday) looking at the code and seeing if I buy in to Sean's use cases. This has been my hesitation too. Since I haven't yet had a use case for it, it seems a bit heavy for inclusion in the core library. I wouldn't veto it, but it's why I have been hesitant. Like Craig, I haven't looked very carefully at it, so I haven't spoken up yet. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34254] New: - [id] New string identifier generators, PrefixedNumericGenerator c.
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=34254. 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=34254 Summary: [id] New string identifier generators, PrefixedNumericGenerator c. Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Sandbox AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In order to generate identifiers for an instance of the Ensembl database [1], I needed a generator for identifiers of the style ENSG01, ENSG02, ENST01, ENST02, ENSP01, and so on. Attached is a class PrefixedLeftPaddedNumericGenerator (sorry about the long class name) that solves this use case and also PrefixedNumericGenerator and PrefixedAlphanumericGenerator for completeness' sake. new PrefixedLeftPaddedNumericGenerator(foo, true, 5); returns foo01 foo02 foo03 foo04 foo05 foo06 foo07 foo08 foo09 foo10 foo11 new PrefixedNumericGenerator(foo, true, 0L) returns foo1 foo2 foo3 foo4 foo5 foo6 foo7 foo8 foo9 foo10 foo11 new PrefixedAlphanumericGenerator(foo, true, 5); returns foo01 foo02 foo03 foo04 foo05 foo06 foo07 foo08 foo09 foo0a foo0b [1] http://www.ensembl.org -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r159635 - jakarta/commons/proper/logging/branches/DON_QUIXOTE/classic/src/java/org/apache/commons/logging/LogFactory.java
Author: rdonkin
Date: Thu Mar 31 12:29:44 2005
New Revision: 159635
URL: http://svn.apache.org/viewcvs?view=revrev=159635
Log:
Finished worked example of lifting simple class from LogFactory
Modified:
jakarta/commons/proper/logging/branches/DON_QUIXOTE/classic/src/java/org/apache/commons/logging/LogFactory.java
Modified:
jakarta/commons/proper/logging/branches/DON_QUIXOTE/classic/src/java/org/apache/commons/logging/LogFactory.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/branches/DON_QUIXOTE/classic/src/java/org/apache/commons/logging/LogFactory.java?view=diffr1=159634r2=159635
==
---
jakarta/commons/proper/logging/branches/DON_QUIXOTE/classic/src/java/org/apache/commons/logging/LogFactory.java
(original)
+++
jakarta/commons/proper/logging/branches/DON_QUIXOTE/classic/src/java/org/apache/commons/logging/LogFactory.java
Thu Mar 31 12:29:44 2005
@@ -410,7 +410,7 @@
public static Log getLog(Class clazz)
throws LogConfigurationException {
-return (getFactory().getInstance(clazz));
+return LogManager.getLog(clazz);
}
@@ -429,7 +429,7 @@
public static Log getLog(String name)
throws LogConfigurationException {
-return (getFactory().getInstance(name));
+return LogManager.getLog(name);
}
@@ -662,5 +662,23 @@
}
}
});
+}
+
+public static class Manager extends LogManager
+{
+/**
+ * Gets a codeLog/code implementation.
+ * Hook for subclassing.
+ * @param param codeObject/code identifying the codeLog/code,
not null
+ * @return codeLog/code, not null
+ */
+protected Log getLogInstance(Object param) {
+if (param instanceof Class) {
+Class clazz = (Class) param;
+return LogFactory.getFactory().getInstance(clazz);
+}
+String logName = param.toString();
+return LogFactory.getFactory().getInstance(logName);
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34254] - [id] New string identifier generators, PrefixedNumericGenerator c.
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=34254. 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=34254 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 22:31 --- Created an attachment (id=14602) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14602action=view) java source files Attached PrefixedAlphanumericGenerator.java PrefixedLeftPaddedNumericGenerator.java PrefixedNumericGenerator.java PrefixedAlphanumericGeneratorTest.java PrefixedLeftPaddedNumericGeneratorTest.java PrefixedNumericGeneratorTest.java -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r159636 - jakarta/commons/proper/logging/branches/DON_QUIXOTE/kernel/src/java/org/apache/commons/logging/LogManager.java
Author: rdonkin
Date: Thu Mar 31 12:33:43 2005
New Revision: 159636
URL: http://svn.apache.org/viewcvs?view=revrev=159636
Log:
Example of how a simple super class can be lifted from LogFactory
Modified:
jakarta/commons/proper/logging/branches/DON_QUIXOTE/kernel/src/java/org/apache/commons/logging/LogManager.java
Modified:
jakarta/commons/proper/logging/branches/DON_QUIXOTE/kernel/src/java/org/apache/commons/logging/LogManager.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/branches/DON_QUIXOTE/kernel/src/java/org/apache/commons/logging/LogManager.java?view=diffr1=159635r2=159636
==
---
jakarta/commons/proper/logging/branches/DON_QUIXOTE/kernel/src/java/org/apache/commons/logging/LogManager.java
(original)
+++
jakarta/commons/proper/logging/branches/DON_QUIXOTE/kernel/src/java/org/apache/commons/logging/LogManager.java
Thu Mar 31 12:33:43 2005
@@ -64,7 +64,7 @@
String discoveryProperty =
System.getProperty(DISCOVERY_CONFIGURATION);
if (discoveryProperty == null) {
try {
- Class discoveryClass =
Class.forName(org.apache.commons.logging.LogFactory);
+ Class discoveryClass =
Class.forName(org.apache.commons.logging.LogFactory$Manager);
result = (LogManager)
discoveryClass.newInstance();
} catch (Throwable t) {
// swallow
@@ -97,7 +97,7 @@
* @return codeLog/code, not null
*/
public static Log getLog(Object param) {
- return manager.getLogImpl(param);
+ return manager.getLogInstance(param);
}
/**
@@ -106,7 +106,7 @@
* @param param codeObject/code identifying the codeLog/code, not
null
* @return codeLog/code, not null
*/
- protected Log getLogImpl(Object param) {
+ protected Log getLogInstance(Object param) {
return fallbackLog;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34185] - Requirement: Combine JCL and UGLI
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=34185. 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=34185 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 22:44 --- I thought an example would be useful :) So, I've create a branch in jakarta/commons/logging called DON_QUIXOTE and added some example code into their. This lifts off a superclass called LogManager (for no very good reason) from LogFactory. The most common user method (getLog) is rewired so that it first calls the superclass. When LogFactory is in the same classloader (ideally in the same jar) as LogManager, the call will be routed through LogFactory. This preserves backwards compatibility. This is the way that Richard and I saw JCL2 proceeding. An option which you may want to consider is compile-time statically binding an alternative LogManager implementation to UGLI. This (I believe) would in line with the spirit of the UGLI way whilst also ensure no actual core dependencies either way. If anyone feels this sounds like a reasonable approach and would like to take a look at creating some experimental implementation code along those lines, I'd be glad to review it for possible inclusion in the branch. I'm don't intend to particularly push this solution (UGLI is the responsibility of others) but I think it's important that all possible solutions are considered. Robert -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[logging] DON_QUIXOTE branch
i've committed some code into a branch called DON_QUIXOTE. it's illustrative code showing how it's possible to lift off a simple superclass from LogFactory. i've believe for some time that this is the most important step forward. moving to a simplified API would allow static binding (whether compile time ala UGLI or byte code manipulation) to be offered in addition to (improved) dynamic binding. one aspect that has been holding me back is the increased complexity that this choice gives. however, i'm now convinced that it really isn't any use running away from the complexity: we need to cover advanced use cases with better documentation as well as giving some intermediary heuristic recipes (to stop JCL blowing up so much). this kind of design is (i think) one way forward for JCL. opinions welcomed (but please forgive the implementation: it's only illustrative). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] [nag] Please commit stuff for DispatchChain
Personally, I'm leaning towards -0 (multiple execute methods per chain seem to encourage the wrong behavior -- combining lots of functionality into a single command versus splitting it up into fine grained reusable chunks), but won't veto it if others think the functionality is desireable. Craig On Thu, 31 Mar 2005 13:50:28 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 2:42 PM -0500 3/31/05, James Mitchell wrote: Sean, I don't mind applying these changes so long as the other committers agree that this would be a good fit. Last I heard, there are still questions or concerns about adding this. I have not been able to find the time to look any deeper into this, so I can't argue one way or the other. I'm at +0 right now -- I don't feel strongly enough about my earlier reservations to put up a fuss. Joe Sorry. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, March 30, 2005 1:36 PM Subject: Re: [chain] [nag] Please commit stuff for DispatchChain I know its been a while since we discussed this ... but I would like to bring up the issue of DispatchChain again. I have a pressing need for something like this in my current application. I need to go ahead and move it into our project codebase or have it added to commons-chain. No hard feelings if I cannot convince you that this is useful. I will briefly summarize my arguments again. The dispatch chain allows you to compose a chain of commands where the command method can be something other than execute. It will always have the same arguments and it will always be the same for every command in the chain. I think the fact that it is always the same method for every command in the chain is a key point here. Its still the CoR pattern. There is nothing special about the name of the execute method, the pattern just requires a consistent method. If you do not accept this line of reasoning then I would suggest that DispatchLookupCommand be removed from the codebase as well. I don't think you can justify one and not the other. Finally, its in the generic package so its entirely optional if you don't want to use it. I'd like to resolve this ASAP so I can go forward on my project here at work. Please give some thought to my arguments. As I said earlier, I will accept the decision of the group if the group cannot be persuaded. Regards, sean On Fri, 14 Jan 2005 16:09:11 -0500, Sean Schofield [EMAIL PROTECTED] wrote: My original post to bugzilla didn't generate any responses. I figured once I wrote something and started pestering for a commit that would get the discussion going ;-) I will await your guys feedback once you've had a chance to think about use cases, etc. Let me know if you have any questions. sean On Fri, 14 Jan 2005 11:37:47 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:20 AM -0800 1/14/05, Craig McClanahan wrote: I plead guilty to being lukewarm (is lukecold a word? :-) about DispatchChain and friends being part of the standard chain package -- I'd like to spend some time tomorrow (Saturday) looking at the code and seeing if I buy in to Sean's use cases. This has been my hesitation too. Since I haven't yet had a use case for it, it seems a bit heavy for inclusion in the core library. I wouldn't veto it, but it's why I have been hesitant. Like Craig, I haven't looked very carefully at it, so I haven't spoken up yet. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - 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]
svn commit: r159637 - jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java
Author: olegk
Date: Thu Mar 31 13:05:48 2005
New Revision: 159637
URL: http://svn.apache.org/viewcvs?view=revrev=159637
Log:
Fixed broken #isRepeatable method
Contributed by Matthew-J Watson matthew-j.watson at db.com
Reviewed by Oleg Kalnichevski
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java
Modified:
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java?view=diffr1=159636r2=159637
==
---
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java
(original)
+++
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/methods/InputStreamRequestEntity.java
Thu Mar 31 13:05:48 2005
@@ -158,7 +158,7 @@
* @see #getContentLength()
*/
public boolean isRepeatable() {
-return content != null;
+return buffer != null;
}
/* (non-Javadoc)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r159638 - jakarta/commons/proper/httpclient/trunk/release_notes.txt
Author: olegk Date: Thu Mar 31 13:09:04 2005 New Revision: 159638 URL: http://svn.apache.org/viewcvs?view=revrev=159638 Log: Fix for broken InputStreamRequestEntity#isRepeatable method, contributed by Matthew-J Watson matthew-j.watson at db.com Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt Modified: jakarta/commons/proper/httpclient/trunk/release_notes.txt URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/httpclient/trunk/release_notes.txt?view=diffr1=159637r2=159638 == --- jakarta/commons/proper/httpclient/trunk/release_notes.txt (original) +++ jakarta/commons/proper/httpclient/trunk/release_notes.txt Thu Mar 31 13:09:04 2005 @@ -1,5 +1,8 @@ Changes since Release Candidate 1: + * - - Fixed broken InputStreamRequestEntity#isRepeatable method + Contributed by Matthew-J Watson matthew-j.watson at db.com + * 33677 - Fixed the bug preventing the HTTP retry handler from handling ConnectionExceptions Contributed by Oleg Kalnichevski olegk at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34256] New: - [io]faster FileFinder
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=34256. 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=34256 Summary: [io]faster FileFinder Product: Commons Version: unspecified Platform: All URL: http://cvs.apache.org/viewcvs.cgi/jakarta- commons/io/src/java/org/apache/commons/io/find/FileFinde r.java?rev=1.4view=log OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: IO AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] when searching a large directory tree, there is no need to allocate a new File[] for every recursion. see propsed patch -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34256] - [io]faster FileFinder
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=34256. 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=34256 --- Additional Comments From [EMAIL PROTECTED] 2005-03-31 23:36 --- Created an attachment (id=14604) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14604action=view) patch + test makeing multiple calls fot find() in different directories to collect on list is cheap -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r159646 - in jakarta/commons/sandbox/jci/trunk: .classpath project.xml src/java/org/apache/commons/jci/compilers/janino/ src/java/org/apache/commons/jci/compilers/janino/JaninoJavaCompiler.java
Author: tcurdt
Date: Thu Mar 31 14:04:49 2005
New Revision: 159646
URL: http://svn.apache.org/viewcvs?view=revrev=159646
Log:
initial janino implementation,
thanks to Art ([EMAIL PROTECTED])
Added:
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/janino/
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/janino/JaninoJavaCompiler.java
Modified:
jakarta/commons/sandbox/jci/trunk/.classpath
jakarta/commons/sandbox/jci/trunk/project.xml
Modified: jakarta/commons/sandbox/jci/trunk/.classpath
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/.classpath?view=diffr1=159645r2=159646
==
--- jakarta/commons/sandbox/jci/trunk/.classpath (original)
+++ jakarta/commons/sandbox/jci/trunk/.classpath Thu Mar 31 14:04:49 2005
@@ -10,5 +10,6 @@
classpathentry kind=var
path=MAVEN_REPO/commons-logging/jars/commons-logging-1.0.4.jar/
classpathentry kind=var
path=MAVEN_REPO/commons-logging/jars/commons-logging-api-1.0.4.jar/
classpathentry kind=var
path=MAVEN_REPO/commons-collections/jars/commons-collections-3.1.jar/
+ classpathentry kind=var
path=MAVEN_REPO/janino/jars/janino-2.3.0.jar/
classpathentry kind=output path=eclipse/
/classpath
Modified: jakarta/commons/sandbox/jci/trunk/project.xml
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/project.xml?view=diffr1=159645r2=159646
==
--- jakarta/commons/sandbox/jci/trunk/project.xml (original)
+++ jakarta/commons/sandbox/jci/trunk/project.xml Thu Mar 31 14:04:49 2005
@@ -69,6 +69,12 @@
version3.0.1/version
typejar/type
/dependency
+dependency
+ groupIdjanino/groupId
+ artifactIdjanino/artifactId
+ version2.3.0/version
+ typejar/type
+/dependency
/dependencies
/project
Added:
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/janino/JaninoJavaCompiler.java
URL:
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/janino/JaninoJavaCompiler.java?view=autorev=159646
==
---
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/janino/JaninoJavaCompiler.java
(added)
+++
jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/janino/JaninoJavaCompiler.java
Thu Mar 31 14:04:49 2005
@@ -0,0 +1,168 @@
+/*
+ * Copyright 1999-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.jci.compilers.janino;
+
+import java.io.ByteArrayInputStream;
+import java.io.File;
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.Map;
+
+import org.apache.commons.jci.compilers.JavaCompiler;
+import org.apache.commons.jci.problems.CompilationProblem;
+import org.apache.commons.jci.problems.CompilationProblemHandler;
+import org.apache.commons.jci.problems.ConsoleCompilationProblemHandler;
+import org.apache.commons.jci.readers.FileResourceReader;
+import org.apache.commons.jci.readers.ResourceReader;
+import org.apache.commons.jci.stores.MemoryResourceStore;
+import org.apache.commons.jci.stores.ResourceStore;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.codehaus.janino.ClassLoaderIClassLoader;
+import org.codehaus.janino.DebuggingInformation;
+import org.codehaus.janino.Descriptor;
+import org.codehaus.janino.IClass;
+import org.codehaus.janino.IClassLoader;
+import org.codehaus.janino.Java;
+import org.codehaus.janino.Parser;
+import org.codehaus.janino.Scanner;
+import org.codehaus.janino.Java.CompileException;
+import org.codehaus.janino.Parser.ParseException;
+import org.codehaus.janino.Scanner.ScanException;
+import org.codehaus.janino.util.ClassFile;
+
+/**
+ *
+ * @author [EMAIL PROTECTED]
+ */
+public class JaninoJavaCompiler implements JavaCompiler {
+
+private final static Log log = LogFactory.getLog(JaninoJavaCompiler.class);
+
+private class CompilingIClassLoader extends IClassLoader {
+
+private ResourceReader resourceReader;
+private CompilationProblemHandler problemHandler;
+private Map classes,types;
+private
[jira] Created: (JELLY-208) JellyContext.getJellyContextURL() assumes slashes
JellyContext.getJellyContextURL() assumes slashes - Key: JELLY-208 URL: http://issues.apache.org/jira/browse/JELLY-208 Project: jelly Type: Bug Versions: 1.0-RC1 Reporter: Thomas Burns The method org.apache.commons.jelly.JellyContext.getJellyContextURL() (both the URL and InputSource version of this method) assumes that the supplied URL or InputSource.getSystemId() uses forward slashes as part of the URL or systemId. Our system uses a custom URL protocol (or scheme in URL-lingo) that does not use slashes, and when the URL is used within Jelly (such as in the core import tag) this method fails due to the assumption that the URL must have at least one forward slash. Also, this bug will appear if an http URL is specified that does not include any slashes (for example, if the web server was to serve a jelly script as its default page). It should be noted that the scheme-specific-part (the path-portion of the URL) is defined by the scheme and need follow no specific layout requirements, such as the use of slashes as separators. References: URI RFC: http://www.faqs.org/rfcs/rfc2396.html URL RFC: http://www.faqs.org/rfcs/rfc1738.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r159551 - jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
For the record, this is my preferred style for calculated return
statements. I'm not going to -1 the change, but I do view it as a
stylistic choice that isn't wrong.
Stephen
[EMAIL PROTECTED] wrote:
Author: ggregory
Date: Wed Mar 30 16:56:20 2005
New Revision: 159551
URL: http://svn.apache.org/viewcvs?view=revrev=159551
Log:
Removed extra C style parens in return statements.
Modified:
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
Modified: jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java
URL: http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java?view=diffr1=159550r2=159551
==
--- jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java (original)
+++ jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java Wed Mar 30 16:56:20 2005
@@ -192,7 +192,7 @@
* @return codetrue/code if the String is empty or null
*/
public static boolean isEmpty(String str) {
-return (str == null || str.length() == 0);
+return str == null || str.length() == 0;
}
/**
@@ -210,7 +210,7 @@
* @return codetrue/code if the String is not empty and not null
*/
public static boolean isNotEmpty(String str) {
-return (str != null str.length() 0);
+return str != null str.length() 0;
}
/**
@@ -292,7 +292,7 @@
* Method will be removed in Commons Lang 3.0.
*/
public static String clean(String str) {
-return (str == null ? EMPTY : str.trim());
+return str == null ? EMPTY : str.trim();
}
/**
@@ -319,7 +319,7 @@
* @return the trimmed string, codenull/code if null String input
*/
public static String trim(String str) {
-return (str == null ? null : str.trim());
+return str == null ? null : str.trim();
}
/**
@@ -346,7 +346,7 @@
*/
public static String trimToNull(String str) {
String ts = trim(str);
-return (isEmpty(ts) ? null : ts);
+return isEmpty(ts) ? null : ts;
}
/**
@@ -371,7 +371,7 @@
* @since 2.0
*/
public static String trimToEmpty(String str) {
-return (str == null ? EMPTY : str.trim());
+return str == null ? EMPTY : str.trim();
}
// Stripping
@@ -4397,7 +4397,7 @@
* was codenull/code
*/
public static String defaultString(String str) {
-return (str == null ? EMPTY : str);
+return str == null ? EMPTY : str;
}
/**
@@ -4418,7 +4418,7 @@
* @return the passed in String, or the default if it was codenull/code
*/
public static String defaultString(String str, String defaultStr) {
-return (str == null ? defaultStr : str);
+return str == null ? defaultStr : str;
}
// Reversing
-
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: [lang] New StringUtils method - defaultIfEmpty
It depends really on how you perceive the function, ie. which group of
methods does it belong to.
I perceive this as an extension to the default* methods, as its just
deaulting based on another condition.
trimToDefault isn't wrong, but its not where *I* would look for the method.
Stephen
Gary Gregory wrote:
It sounds OK but there might be a different (better?) way.
We now have trimToEmpty and trimToNull methods. What about a
trimToDefault method?
Just a thought.
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 30, 2005 2:29 PM
To: Jakarta Commons Developers List
Subject: [lang] New StringUtils method - defaultIfEmpty
Currently we have two default methods, both of which default when the
string parameter is null. At my job we just had need of a default if
empty method:
public String defaultIfEmpty(String str, String defaultString) {
if (isEmpty(str)) {
return defaultString;
} else {
return str;
}
}
Does this sound OK to add?
Stephen
-
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: [logging] DON_QUIXOTE branch
This is good to see, anything which leads towards a more predictable behaviour for CL is great. I would personally prefer the static binding approach over byte code manipulation as a more deterministic approach. I'm curious at to your choice of 'Don Quixote' as a branch name, please, please put me out of my misery and explain what the reference means! :-) Regards, Andy -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: 31 March 2005 21:57 To: Jakarta Commons Developers List Subject: [logging] DON_QUIXOTE branch i've committed some code into a branch called DON_QUIXOTE. it's illustrative code showing how it's possible to lift off a simple superclass from LogFactory. i've believe for some time that this is the most important step forward. moving to a simplified API would allow static binding (whether compile time ala UGLI or byte code manipulation) to be offered in addition to (improved) dynamic binding. one aspect that has been holding me back is the increased complexity that this choice gives. however, i'm now convinced that it really isn't any use running away from the complexity: we need to cover advanced use cases with better documentation as well as giving some intermediary heuristic recipes (to stop JCL blowing up so much). this kind of design is (i think) one way forward for JCL. opinions welcomed (but please forgive the implementation: it's only illustrative). - robert - 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]
webdav servlet in commons?
Regarding: (Bhttp://archives.devshed.com/m/200412-5091/WebDAV-servelt-in-commons (B (BI too would like to have a webdav servlet in commons. Since our product (Breleases against multiple containers (not only Tomcat), I can't use the (Bwebdav servlet in Tomcat. (Or at the very least I'd feel a little (Bstrange including that whole JAR file as part of my distribution.) (B (BBesides a class that maps to the file system, I'd also like "a simple (BAPI to map WebDAV to your system and thus people could very easily add (Bbasic WebDAV features to their application." (B (BBill (B (B- (BTo unsubscribe, e-mail: [EMAIL PROTECTED] (BFor additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] [ftp] [patch] FTPTimestampParserImplTest.java and FTPClientConfigTest.java
What do you mean, make the tests pass? The tests, as written, already
pass. Perhaps you are saying that the tests don't test everything they
need to test. But you have not identified what those issues are.
If you come up with a test case that shows a problem, then the solution
is to add the test and fix the code as necessary.
Or am I misunderstanding you?
Neeme Praks wrote:
Two patches to make the FTP timestamp parsing tests pass also on
non-english systems.
I'm not sure if this is the best way to fix those issues, though.
Rgds,
Neeme
Index: FTPTimestampParserImplTest.java
===
--- FTPTimestampParserImplTest.java (revision 159615)
+++ FTPTimestampParserImplTest.java (working copy)
@@ -15,6 +15,7 @@
*/
package org.apache.commons.net.ftp.parser;
+import java.text.DateFormatSymbols;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
@@ -73,8 +74,19 @@
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+// assume we are FTPing a server in Chicago, two hours ahead of
+// L. A.
+FTPClientConfig config =
+new FTPClientConfig(FTPClientConfig.SYST_UNIX);
+config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
+config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
+// 2 hours difference
+config.setServerTimeZoneId(America/Chicago);
+parser.configure(config);
+
+
SimpleDateFormat sdf =
- new SimpleDateFormat(parser.getRecentDateFormatString());
+ new SimpleDateFormat(parser.getRecentDateFormatString(), parser.getRecentDateFormat().getDateFormatSymbols());
// assume we're in the US Pacific Time Zone
TimeZone tzla = TimeZone.getTimeZone(America/Los_Angeles);
sdf.setTimeZone(tzla);
@@ -84,17 +96,6 @@
String fmtTimePlusThreeHours = sdf.format(threeHoursFromNow);
- // assume we are FTPing a server in Chicago, two hours ahead of
- // L. A.
- FTPClientConfig config =
- new FTPClientConfig(FTPClientConfig.SYST_UNIX);
- config.setDefaultDateFormatStr(FTPTimestampParser.DEFAULT_SDF);
- config.setRecentDateFormatStr(FTPTimestampParser.DEFAULT_RECENT_SDF);
- // 2 hours difference
- config.setServerTimeZoneId(America/Chicago);
- parser.configure(config);
-
-
try {
Calendar parsed = parser.parseTimestamp(fmtTimePlusOneHour);
// the only difference should be the two hours
@@ -103,7 +104,7 @@
(long)TWO_HOURS_OF_MILLISECONDS,
cal.getTime().getTime() - parsed.getTime().getTime());
} catch (ParseException e){
- fail(Unable to parse);
+ fail(Unable to parse + fmtTimePlusOneHour);
}
//but if the file's timestamp is THREE hours ahead of now, that should
@@ -123,13 +124,18 @@
public void testParser() {
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
+Calendar cal = Calendar.getInstance();
+cal.set(Calendar.YEAR, 2002);
+cal.set(Calendar.MONTH, 1);
+cal.set(Calendar.DAY_OF_MONTH, 22);
+SimpleDateFormat sdf = new SimpleDateFormat(MMM dd );
try {
- parser.parseTimestamp(feb 22 2002);
+ parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.default);
}
try {
- parser.parseTimestamp(fv 22 2002);
+ parser.parseTimestamp(fv 22 2002);
fail(should.have.failed.to.parse.default);
} catch (ParseException e) {
// this is the success case
@@ -140,14 +146,17 @@
config.setRecentDateFormatStr(d MMM HH:mm);
config.setServerLanguageCode(fr);
parser.configure(config);
+DateFormatSymbols dfs = FTPClientConfig.lookupDateFormatSymbols(fr);
+sdf = new SimpleDateFormat(MMM d , dfs);
try {
- parser.parseTimestamp(dc 22 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
fail(incorrect.field.order);
} catch (ParseException e) {
// this is the success case
}
+sdf = new SimpleDateFormat(d MMM , dfs);
try {
- parser.parseTimestamp(22 dc 2002);
+parser.parseTimestamp(sdf.format(cal.getTime()));
} catch (ParseException e) {
fail(failed.to.parse.french);
}
@@ -159,27 +168,28 @@
// this is the success case
}
try {
- parser.parseTimestamp(29 fv 2002);
+ parser.parseTimestamp(29 fv 2002);
fail(nonexistent.date);
} catch (ParseException e) {
// this is the success case
}
try {
- parser.parseTimestamp(22 ao 30:02);
+ parser.parseTimestamp(22 ao 30:02);
fail(bad.hour);
} catch (ParseException e) {
// this is the success case
}
try {
- parser.parseTimestamp(22 ao 20:74);
+ parser.parseTimestamp(22 ao 20:74);
fail(bad.minute);
} catch (ParseException e) {
// this is the success case
}
+sdf = new SimpleDateFormat(d MMM HH:mm,
Re: Latka
To help us help you, what did you install? On Mar 31, 2005 7:41 PM, Sean McGowan [EMAIL PROTECTED] wrote: Hi there, I recently installed the Commons-Latka utility on my PC, but I'm having problems running the sample test. Actually, the test seems to run fine, but it fails. C:\Latka\binlatka file../tests/samples/TestCommonsWebsite.xml TEST SUITE FAILED 0 requests 0 passed 0 failed 0 skipped 0 errors Thank you very much C:\Latka\bin I'd really appreciate any ideas you may have on this as I couldn't find much help documentation. Cheers, Sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] [nag] Please commit stuff for DispatchChain
I'm in the -0.5 camp myself. I agree with most of William Slough's comments here: http://issues.apache.org/bugzilla/show_bug.cgi?id=33006#c11 In particular, the notion that the execute() method - the only method a Command has - becomes irrelevant for commands that are intended to be used this way seems to stretch things too far, IMO. Also, as William mentions, the lack of interchangeability is significant; you can't drop a regular command into such a chain and have it work, nor can you take one of these commands and drop it into a regular chain and expect the right thing to happen. -- Martin Cooper On Mar 31, 2005 12:59 PM, Craig McClanahan [EMAIL PROTECTED] wrote: Personally, I'm leaning towards -0 (multiple execute methods per chain seem to encourage the wrong behavior -- combining lots of functionality into a single command versus splitting it up into fine grained reusable chunks), but won't veto it if others think the functionality is desireable. Craig On Thu, 31 Mar 2005 13:50:28 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 2:42 PM -0500 3/31/05, James Mitchell wrote: Sean, I don't mind applying these changes so long as the other committers agree that this would be a good fit. Last I heard, there are still questions or concerns about adding this. I have not been able to find the time to look any deeper into this, so I can't argue one way or the other. I'm at +0 right now -- I don't feel strongly enough about my earlier reservations to put up a fuss. Joe Sorry. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Sean Schofield [EMAIL PROTECTED] To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Sent: Wednesday, March 30, 2005 1:36 PM Subject: Re: [chain] [nag] Please commit stuff for DispatchChain I know its been a while since we discussed this ... but I would like to bring up the issue of DispatchChain again. I have a pressing need for something like this in my current application. I need to go ahead and move it into our project codebase or have it added to commons-chain. No hard feelings if I cannot convince you that this is useful. I will briefly summarize my arguments again. The dispatch chain allows you to compose a chain of commands where the command method can be something other than execute. It will always have the same arguments and it will always be the same for every command in the chain. I think the fact that it is always the same method for every command in the chain is a key point here. Its still the CoR pattern. There is nothing special about the name of the execute method, the pattern just requires a consistent method. If you do not accept this line of reasoning then I would suggest that DispatchLookupCommand be removed from the codebase as well. I don't think you can justify one and not the other. Finally, its in the generic package so its entirely optional if you don't want to use it. I'd like to resolve this ASAP so I can go forward on my project here at work. Please give some thought to my arguments. As I said earlier, I will accept the decision of the group if the group cannot be persuaded. Regards, sean On Fri, 14 Jan 2005 16:09:11 -0500, Sean Schofield [EMAIL PROTECTED] wrote: My original post to bugzilla didn't generate any responses. I figured once I wrote something and started pestering for a commit that would get the discussion going ;-) I will await your guys feedback once you've had a chance to think about use cases, etc. Let me know if you have any questions. sean On Fri, 14 Jan 2005 11:37:47 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:20 AM -0800 1/14/05, Craig McClanahan wrote: I plead guilty to being lukewarm (is lukecold a word? :-) about DispatchChain and friends being part of the standard chain package -- I'd like to spend some time tomorrow (Saturday) looking at the code and seeing if I buy in to Sean's use cases. This has been my hesitation too. Since I haven't yet had a use case for it, it seems a bit heavy for inclusion in the core library. I wouldn't veto it, but it's why I have been hesitant. Like Craig, I haven't looked very carefully at it, so I haven't spoken up yet. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
RE: [lang] New StringUtils method - defaultIfEmpty
Agreed.
FWIW, for this kind of method I kind of like the return condition ? v1
: v2; idiom.
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 31, 2005 2:52 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] New StringUtils method - defaultIfEmpty
It depends really on how you perceive the function, ie. which group of
methods does it belong to.
I perceive this as an extension to the default* methods, as its just
deaulting based on another condition.
trimToDefault isn't wrong, but its not where *I* would look for the
method.
Stephen
Gary Gregory wrote:
It sounds OK but there might be a different (better?) way.
We now have trimToEmpty and trimToNull methods. What about a
trimToDefault method?
Just a thought.
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 30, 2005 2:29 PM
To: Jakarta Commons Developers List
Subject: [lang] New StringUtils method - defaultIfEmpty
Currently we have two default methods, both of which default when the
string parameter is null. At my job we just had need of a default if
empty method:
public String defaultIfEmpty(String str, String defaultString) {
if (isEmpty(str)) {
return defaultString;
} else {
return str;
}
}
Does this sound OK to add?
Stephen
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
