cvs commit: jakarta-commons-sandbox/jelly/xdocs tutorial.xml
jstrachan2002/12/11 00:32:05 Modified:jelly/xdocs tutorial.xml Log: fixed typo on bad URL Revision ChangesPath 1.5 +1 -1 jakarta-commons-sandbox/jelly/xdocs/tutorial.xml Index: tutorial.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/xdocs/tutorial.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- tutorial.xml 21 Oct 2002 12:02:55 - 1.4 +++ tutorial.xml 11 Dec 2002 08:32:05 - 1.5 @@ -153,7 +153,7 @@ subsection name=Homepage Builder (JellySwing Edition) p -This is a good chance to use the Jelly Runner. Find HomepageBuilder.jelly, which is located in /src/test/org/apache/commons/jelly/demos/ (View the a href=http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/demos/HomepageBuilder.jelly?rev=HEADamp;content-type=text/vnd.viewcvs-markup;demo source/a). +This is a good chance to use the Jelly Runner. Find HomepageBuilder.jelly, which is located in /src/test/org/apache/commons/jelly/demos/ (View the a href=http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/demos/homepageBuilder.jelly?rev=HEADamp;content-type=text/vnd.viewcvs-markup;demo source/a). /p p -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JNDI based selection
I have been a long time critic of commons-logging API for its class loader based approach of selecting the logging implementation. See for example my http://qos.ch/logging/thinkAgain.html document. I think more reliable solutions exist. In particular, you might want to consider the JNDI based solution discussed in http://qos.ch/logging/sc.html. I suggest that you begin reading thinkAgain.html first and then read sc.html. You are welcome to use the heretical ideas contained therein to your advantage or alternatively ignore them altogether. Your comments, constructive or otherwise, are welcome. Regards, -- Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] [patch] changes for ArrayListIterator was: Re: [collections] private member access in o.a.c.collections.iterators
from:Rich Dougherty [EMAIL PROTECTED] I have seen this sort of thing done before. For example, in the JODA Time library, ReadableWritableInstant (mutable) extends ReadableInstant (immutable). :-) Actually, the ReadableInstant interface is named and defined to allow a field to be read, not to imply immutability. Hence the subinterface ReadableWritableInstant made sense ;-) Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] NodeCachingLinkedList license issues?
Rich, can you declare either: a) declare that the implementation was not copied b) supply a reimplementation if it was Otherwise I will be forced (legally) to remove the code from CVS (which I don't really want to do ;-), don't you just love licencing issues) Stephen from:Craig R. McClanahan [EMAIL PROTECTED] On Wed, 11 Dec 2002, Rich Dougherty wrote: Implementing the java.util.LinkedList interface is perfectly legal. The fact that many linked list implementations will look similar to each other is the nature of the beast -- the question is, did you write it yourself or did you copy someone else's implementation? Copying code directly from some other implementation is restricted by the terms under which you acquired that source code (i.e. if you copy code from an Apache class into you're own, you have to obey the Apache license terms; same for Sun source code or anyone elses). In the case at hand, if the code was directly copied from Sun source code then it is Sun intellectual property, bound by the click-through license that you accepted when you downloaded it. Short answer: you can't do that. I have not checked the proposed code against the Sun sources, but this sounds like it would be a problematic contribution to me. Rich Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/xdocs powered.xml
jstrachan2002/12/11 04:07:52 Modified:jelly/xdocs powered.xml Log: Added a bunch of new powered by links Revision ChangesPath 1.3 +34 -5 jakarta-commons-sandbox/jelly/xdocs/powered.xml Index: powered.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/xdocs/powered.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- powered.xml 20 Sep 2002 14:36:21 - 1.2 +++ powered.xml 11 Dec 2002 12:07:51 - 1.3 @@ -19,25 +19,54 @@ table trthProject/ththOverview/th/tr tr - tda href=http://jakarta.apache.org/turbine/maven/;Maven/a/td + tda href=http://aft.sourceforge.net/;Anteater/a/td td -A java project management and project comprehension tool. +A testing framework which provides an easy way to write tests for checking the functionality of a +Web application or of an XML Web service. /td /tr tr - tda href=http://drools.org/;drools/a/td + tda href=http://drools.org/;Drools/a/td td A Java rules engine. /td /tr tr - tda href=http://blissed.werken.com/;blissed/a/td + tda href=http://blissed.werken.com/;Blissed/a/td td A Java process and state framework. /td /tr tr - tda href=http://werkflow.werken.com/;werkflow/a/td + tda href=http://jakarta.apache.org/commons/latka/;Latka/a/td + td +A functional (end-to-end) testing tool implemented in Java, and using an XML syntax to +define a series of HTTP (or HTTPS) requests and a set of validations used to verify that +the request was processed correctly. + /td +/tr +tr + tda href=http://jakarta.apache.org/turbine/maven/;Maven/a/td + td +A java project management and project comprehension tool. + /td +/tr +tr + tda href=http://nanning.sourceforge.net/;Nanning/a/td + td +A simple yet scaleable aspect-oriented framework for Java + /td +/tr +tr + tda href=http://seedling.sourceforge.net;Seedling/a/td + td +A generic application platform that enables streamlined development of Java applications from +reusable components. In particular JellyUnit and JellySwing are used to implement Swing based +unit testing. + /td +/tr +tr + tda href=http://werkflow.werken.com/;Werkflow/a/td td A Java workflow system. /td -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly project.xml
jstrachan2002/12/11 04:34:49 Modified:jellyproject.xml Log: patch to use consistent version of Ant and Ant+optional Revision ChangesPath 1.99 +1 -1 jakarta-commons-sandbox/jelly/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/jelly/project.xml,v retrieving revision 1.98 retrieving revision 1.99 diff -u -r1.98 -r1.99 --- project.xml 10 Dec 2002 08:58:43 - 1.98 +++ project.xml 11 Dec 2002 12:34:49 - 1.99 @@ -225,7 +225,7 @@ dependency idant+optional/id - version1.5/version + version1.5.1/version /dependency dependency -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly/xdocs .cvsignore
jstrachan2002/12/11 04:35:19 Added: jelly/xdocs .cvsignore Log: add cvsignore to hide stuff Maven sometimes generates Revision ChangesPath 1.1 jakarta-commons-sandbox/jelly/xdocs/.cvsignore Index: .cvsignore === stylesheets -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestCookie.java
oglueck 2002/12/11 05:16:09
Modified:httpclient/src/java/org/apache/commons/httpclient/cookie
CookieSpecBase.java
httpclient/src/test/org/apache/commons/httpclient
TestCookie.java
Log:
Fixed StringIndexOutOfBoundsException and added test case.
Reported by: Christopher Lenz
Patch contributed by: Michael Becke
Revision ChangesPath
1.3 +4 -2
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java
Index: CookieSpecBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CookieSpecBase.java 9 Dec 2002 12:48:40 - 1.2
+++ CookieSpecBase.java 11 Dec 2002 13:16:09 - 1.3
@@ -501,14 +501,16 @@
private static boolean pathMatch(final String path, final String topmostPath)
{
boolean match = path.startsWith( topmostPath );
-if (match) {
+
+// if there is a match and these values are not exactly the same we have
+// to make sure we're not matcing /foobar and /foo
+if ( match path.length() != topmostPath.length() ) {
if (!topmostPath.endsWith(PATH_DELIM)) {
match = (path.charAt(topmostPath.length()) == PATH_DELIM_CHAR);
}
}
return match;
}
-
/**
* Return an array of {@link Cookie}s that should be submitted with a request
with
1.16 +28 -5
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestCookie.java
Index: TestCookie.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestCookie.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- TestCookie.java 8 Dec 2002 06:09:46 - 1.15
+++ TestCookie.java 11 Dec 2002 13:16:09 - 1.16
@@ -721,7 +721,30 @@
// Expected
}
}
-
+
+/**
+ * Makes sure that a cookie matches with a path of the same value.
+ */
+public void testMatchWithEqualPaths() {
+
+Cookie cookie = new Cookie(.test.com, test, 1, /test, null, false);
+
+try {
+boolean match = cookie.matches(
+test.test.com,
+80,
+/test,
+false,
+new Date()
+);
+
+assertTrue(Cookie paths did not match, match);
+} catch ( Exception e ) {
+e.printStackTrace();
+fail(Unexpected exception: + e);
+}
+
+}
/**
* Tests Netscape specific cookie formatting.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] code style
Hmm. Would be interesting if Maven generated the checkstyle properties into a suggested coding standard for a project :) On Wed, 11 Dec 2002, bob mcwhirter wrote: Either way, I think checkstyle should alert you to any violations. Not familiar with this. I use Maven to perform the check, I suppose? I saw a couple of declarations in project.properties... maven checkstyle xdoc:transform That'll generate the checkstyle report for you. maven site:generate will generate the whole site, including test reports, style reports, metrics, code coverage, etc. Always a good thing to do. -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient HttpMethodBase.java
oglueck 2002/12/11 05:21:43
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
Log:
Fixed bug #15016
Patch contributed by Michael Becke
Revision ChangesPath
1.87 +9 -8
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java
Index: HttpMethodBase.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpMethodBase.java,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -r1.86 -r1.87
--- HttpMethodBase.java 10 Dec 2002 04:05:03 - 1.86
+++ HttpMethodBase.java 11 Dec 2002 13:21:43 - 1.87
@@ -68,7 +68,6 @@
import java.io.UnsupportedEncodingException;
import java.net.MalformedURLException;
import java.net.URL;
-import java.util.Date;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
@@ -966,9 +965,11 @@
return false;
}
-//update the current location with the redirect location
-setPath(redirectUrl.getPath());
-setQueryString(redirectUrl.getQuery());
+//update the current location with the redirect location.
+//avoiding use of URL.getPath() and URL.getQuery() to keep
+//jdk1.2 comliance.
+setPath( URIUtil.getPath( redirectUrl.toString() ) );
+setQueryString( URIUtil.getQuery( redirectUrl.toString() ) );
if (log.isDebugEnabled()) {
log.debug(Redirecting from ' + currentUrl.toExternalForm()
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15016] - HttpMethodBase does not compile on JDK prior to 1.3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15016. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15016 HttpMethodBase does not compile on JDK prior to 1.3 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-email
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2002-12-11/commons-email.html Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/email/target/classes [javac] Compiling 7 source files to /home/rubys/jakarta/jakarta-commons-sandbox/email/target/classes [javac] /home/rubys/jakarta/jakarta-commons-sandbox/email/src/java/org/apache/commons/mail/HtmlEmail.java:66: cannot resolve symbol [javac] symbol : class GenerateUniqueId [javac] location: package util [javac] import org.apache.commons.util.GenerateUniqueId; [javac]^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/email/src/java/org/apache/commons/mail/HtmlEmail.java:208: cannot resolve symbol [javac] symbol : class GenerateUniqueId [javac] location: package util [javac] String cid = org.apache.commons.util.GenerateUniqueId.getIdentifier(); [javac] ^ [javac] 2 errors BUILD FAILED file:///home/rubys/jakarta/jakarta-commons-sandbox/email/build-gump.xml:22: Compile failed; see the compiler error output for details. Total time: 2 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-jelly
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2002-12-11/commons-jelly.html
Buildfile: build.xml
init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/jelly/lib
get-deps:
compile:
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes
[javac] Compiling 342 source files to
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:68:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: package httpclient
[javac] import org.apache.commons.httpclient.HttpMultiClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:64:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: package httpclient
[javac] import org.apache.commons.httpclient.HttpMultiClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:89:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] private HttpMultiClient _httpClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:118:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] public HttpMultiClient getHttpClient() {
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:127:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] public void setHttpClient(HttpMultiClient httpClient) {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:234:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.HttpTagSupport
[javac] private HttpMultiClient getHttpClient() {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java:73:
cannot resolve symbol
[javac] symbol : class ServletException
[javac] location: package servlet
[javac] import javax.servlet.ServletException;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java:74:
cannot resolve symbol
[javac] symbol : class ServletOutputStream
[javac] location: package servlet
[javac] import javax.servlet.ServletOutputStream;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java:75:
package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpServlet;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java:76:
package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpServletRequest;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java:77:
package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpServletResponse;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java:88:
cannot resolve symbol
[javac] symbol : class HttpServlet
[javac] location: class org.apache.commons.jelly.servlet.JellyServlet
[javac] public class JellyServlet extends HttpServlet {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/servlet/JellyServlet.java:100:
cannot resolve symbol
[javac] symbol : class HttpServletRequest
[javac] location: class org.apache.commons.jelly.servlet.JellyServlet
[javac] HttpServletRequest request,
[javac] ^
[javac]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestWebappMethods.java
oglueck 2002/12/11 05:38:25
Modified:httpclient/src/java/org/apache/commons/httpclient/methods
PostMethod.java
httpclient/src/test/org/apache/commons/httpclient
TestWebappMethods.java
Log:
Correctly recycle POST methods.
Contributed by Oleg Kalnichevski
Revision ChangesPath
1.29 +4 -3
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java
Index: PostMethod.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/PostMethod.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- PostMethod.java 9 Dec 2002 09:16:17 - 1.28
+++ PostMethod.java 11 Dec 2002 13:38:24 - 1.29
@@ -560,6 +560,7 @@
requestBody = null;
requestContentLength = CONTENT_LENGTH_AUTO;
buffer = null;
+repeatCount = 0;
parameters.clear();
}
1.8 +52 -17
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestWebappMethods.java
Index: TestWebappMethods.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestWebappMethods.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TestWebappMethods.java29 Oct 2002 09:44:22 - 1.7
+++ TestWebappMethods.java11 Dec 2002 13:38:25 - 1.8
@@ -109,7 +109,7 @@
*/
public void testGetMethod() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
GetMethod method = new GetMethod(/ + context + /params);
method.setUseDisk(false);
try {
@@ -139,7 +139,7 @@
*/
public void testPostMethod() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
PostMethod method = new PostMethod(/ + context + /params);
method.setUseDisk(false);
try {
@@ -169,7 +169,7 @@
*/
public void testHeadMethod() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
HeadMethod method = new HeadMethod(/ + context + /params);
try {
client.executeMethod(method);
@@ -196,7 +196,7 @@
*/
public void testOptionsMethod() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
OptionsMethod method = new OptionsMethod(/ + context + /params);
try {
client.executeMethod(method);
@@ -225,7 +225,7 @@
*/
public void testOptionsStar() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
OptionsMethod method = new OptionsMethod(*);
try {
client.executeMethod(method);
@@ -242,7 +242,7 @@
*/
public void testDeleteMethod() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
DeleteMethod method = new DeleteMethod(/ + context + /params);
try {
client.executeMethod(method);
@@ -269,7 +269,7 @@
*/
public void testPutMethod() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
PutMethod method = new PutMethod(/ + context + /params);
try {
client.executeMethod(method);
@@ -295,7 +295,7 @@
public void testPostBodyNVP() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
PostMethod method = new PostMethod(/ + context + /body);
method.setUseDisk(false);
method.addParameter(quote,It was the best of times, it was the worst of
times.);
@@ -311,7 +311,7 @@
public void testPostBody() throws Exception {
HttpClient client = new HttpClient();
-client.startSession(host, port);
+client.getHostConfiguration().setHost(host, port, http);
Re: [configuration] XmlConfiguration
Nicola Ken Barozzi wrote: Kelvin Tan wrote: On Wed, 04 Dec 2002 14:25:10 +0100, Nicola Ken Barozzi said: In the Ant codebase, in the proposals/embed dir, ther is a task that uses jxpath for configuration. JXPath can make use of more things than just XML, and is thus much more flexible, and has xpath support. I'd take a look at that file and give that a shot for config. h...I'm not too sure what you're getting at. I'm kinda referring to something which adheres the Configuration interface, but for XML files. Repeat: if you use jxpath to make that implementation of the Configuration interface, you get pluggability for free. Or maybe you don't know what jxpath is. Many projects use xml configuration files, and its odd that each project has its own implementation. Isn't that what the configuration sub-project is for (and Commons as a whole), to factor out common components? If you want to make sonething that is used project-wide, then look at what is already there, and factor out a common denominator. Avalon has a Configuration, and will not switch to the Commons easily. 10 other projects also have their implementation and they don't want to switch :- it definitly doesn't make sense to have 10 implemetations for something like reading an xml config file!!! is it really impossible to find a solution which can be used by all projects?? let's join forces to find a way to have one configuration package!!! martin The minus side, of course, is tagging on another lib dependency, dom4j in this case. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [configuration] XmlConfiguration
i think it would be better to invite the 'customers' to work together ... Well, yes, of course. But given that they are reluctant to the idea in the first place or have other things that are more important to them right now, and based upon the assumption that you have a personal itch doing something. Personally, I have this itch to scratch, where I need both XMLization of beans and configuration. The thing is that the configuration should be able to change programmatically as a result of an admin type doing things with the running application. Should I check out JXPath and Betwixed to see if there is something to grab? /O -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] ClassFilterIterator
Actually, I've got one more comment. Not a biggie, but since I'm already here. :-) The constructor of ClassPredicate interprets a null value as equivalent to Object.class. It might be a good idea to shy away from default behaviour, and instead throw a NullPointerException. Or an IllegalArgumentException. Browse archives to see the reasons for and against throwing NPE / IEA when someone is providing an illegal argument that happens to be a null pointer. /O -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [configuration] XmlConfiguration
Ola Berg wrote: i think it would be better to invite the 'customers' to work together ... Well, yes, of course. But given that they are reluctant to the idea in the first place or have other things that are more important to them right now, and based upon the assumption that you have a personal itch doing something. I'm here. Personally, I have this itch to scratch, where I need both XMLization of beans and configuration. The thing is that the configuration should be able to change programmatically as a result of an admin type doing things with the running application. Should I check out JXPath and Betwixed to see if there is something to grab? I think that JXPath is an excellent solution, and have been using it in the new Ant embed proposal. It makes it dead simple to get configuration stuff from basically anywhere using xpath... actually, JXPath is itself the package for Configuration ;-) I know Avalon configuration, Tomcat IIUC uses Digester. We should at least look at what these deliver that Commons Config should deliver too. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [configuration] XmlConfiguration
Dito, Ola. I also don't think it can be possible to find a sensible denominator for configuration. I see several types of usage patterns: 1) Simple properties style (some create hierachies using the dotted strings) 2) [INI] style adding the notion of groups (and better mechanisms for constructed hierarchies) 3) Full featured XML (which is harder to read and edit, but can be programatically syntax checked DTD, Schemas) 4) XML defining Objects (like the Java Serialization, Digester/Betwixt, Castor, Koala XML, etc.). Each of these the come in different styles (capitalization, XML element names, etc.). In my case, I used #4 with the notion of loading on demand and allowing reuse. So we will have to live with *many* configuration implementations. All that commons can do is to present clean examples of some of the above, which then can be resued by other projects. Cheers, Christoph Ola Berg wrote: 10 other projects also have their implementation and they don't want to switch :- it definitly doesn't make sense to have 10 implemetations for something like reading an xml config file!!! is it really impossible to find a solution which can be used by all projects?? let's join forces to find a way to have one configuration package!!! Hint (if you think it is worth it): 1) Check out the 10 implementations, factor out a common denominator API. 2) Merge all features from all implementations so that your thing will be the most featuresque of them all (so that the potential customers won't lose anything in the transition), and thus expanding the API from 1) above. 3) Sell it to them by offering replacement classes that adapts your thing to theirs (a slip-in-replacement). 4) Offer the added functionality on their email lists, pushing the benefits of your thing. Why I don't think that the above will work is that a) the installed base is too big, b) configuration is such a core feature of your product so that you want to retain full release/bugfix/management control over the configuration component and c) The different APIs take different approaches, esp when in the configuration process, and how, the provided String values get converted into real objects. I welcome better config utilities (even though I know that the existing impls are good enough for about any case), but I think that when doing such a thing, considering your answer to point c) is of great importance. I have limited coding possibilities as of now, but I am with you in thinking (feature requests, modelling, opinions etc). I prefer seeing XML config files as a special case of XMLalizing object/bean structures. /O -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- :) Christoph Reck -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI based selection
Ceki Gülcü wrote: I have been a long time critic of commons-logging API for its class loader based approach of selecting the logging implementation. See for example my http://qos.ch/logging/thinkAgain.html document. I think more reliable solutions exist. In particular, you might want to consider the JNDI based solution discussed in http://qos.ch/logging/sc.html. The class loader based _default_ approach is not perfect, but you can plug other factories. I like the JNDI solution, excelent idea. One comment: application isolation is not a voluntary thing. If we want to isolate the loggers you can't allow the application to specify what logger it wants in web.xml and hope they'll not use the same name. Using java:env is a great solution, probably it needs an external config ( server.xml or the logging config file ). Costin I suggest that you begin reading thinkAgain.html first and then read sc.html. You are welcome to use the heretical ideas contained therein to your advantage or alternatively ignore them altogether. Your comments, constructive or otherwise, are welcome. Regards, -- Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] NodeCachingLinkedList license issues?
Rich, can you declare either: a) declare that the implementation was not copied b) supply a reimplementation if it was Otherwise I will be forced (legally) to remove the code from CVS (which I don't really want to do ;-), don't you just love licencing issues) It looks like a lot of it was copied, (but I didn't write it so I don't know for sure) so I will write another implementation. Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][lang] Functors, pre-vote
On Wed, 11 Dec 2002, Stephen Colebourne wrote: Thus the only viable solutions are: Solution (a) functors in [lang] [collections] depends on [lang] Solution (b) functors in [functor] [collections] depends on [functor] Solution (c) functors in [collections] Any more views. Is [functor] viable?? [functor] seems fine. The charter definitely pushes us towards small components, and this is a viable way of managing a library [with its own set of obvious negatives]. I'm all for the functor package as is in Lang being promoted to Functor [yeah, were back to patterns but with a better PROPOSAL]. Does it matter if [functor] and [lang] have circular dependencies? Not that they will. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [CLI]: ParseException:Unrecognized option: -p
I did some thing trying to reverse engineer the parser, but I don't know if the behavior I have are expected. I got the following error trying to run the ls test (from ApplicationTest) with a GnuParser or a BasicParser. org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: --block-size=10 at org.apache.commons.cli.Parser.processOption(Parser.java:253) at org.apache.commons.cli.Parser.parse(Parser.java:170) at org.apache.commons.cli.Parser.parse(Parser.java:114) at org.apache.commons.cli.ApplicationTest.doTestLs(ApplicationTest.java:53 ) at org.apache.commons.cli.ApplicationTest.testLsGnu(ApplicationTest.java:6 3) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja va:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl.java:25) Does all parser support long options? In different ways. BasicParser is a very simple implementation. It doesn't do any processing of the command line arguments e.g. in this case --block-size=10 is treated as one token. Therefore, the parser checks to see if there is an option names --block-size=10. Obviously there isn't thus the exception. GnuParser supports long options but this is the default for Gnu options e.g. -buildfile, it doesn't make sense to have a '--buildfile' as well. PosixParser supports long and short options. So in this case --block-size=10 is burst into two tokens '--block-size' and '10'. The Option 'block-size' can be found and the '10' is added as an argument value. Does this answer your question? -John K -- Guillaume Coté [EMAIL PROTECTED] Tel. : +33.1.41.45.13.87 Fax. : +33.1.41.45.10.50 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - Jakarta Commons CLI http://jakarta.apache.org/commons/cli -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15192] - Property Descriptor Utility Cache needs a way to clear it.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15192. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15192 Property Descriptor Utility Cache needs a way to clear it. --- Additional Comments From [EMAIL PROTECTED] 2002-12-11 21:23 --- Perhaps Struts needs a specific design so that they basic API can be shared accross several deployed web apps. This is possible by adding a method to ActionServlet called setActionClassLoader. Then the Web App extends the ActionServlet and sets thes the ActionClassLoader to his current ClassLoader. All classes that deal with creating objects instances need to be updated. This includes the ActionServlet, PropertiesUtils, and Message Factories. I have done this in my code and can provide more information if need be. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][lang] Functors, pre-vote
On Wednesday, December 11, 2002, at 08:39 PM, Henri Yandell wrote: On Wed, 11 Dec 2002, Stephen Colebourne wrote: Thus the only viable solutions are: Solution (a) functors in [lang] [collections] depends on [lang] Solution (b) functors in [functor] [collections] depends on [functor] Solution (c) functors in [collections] Any more views. Is [functor] viable?? [functor] seems fine. The charter definitely pushes us towards small components, and this is a viable way of managing a library [with its own set of obvious negatives]. I'm all for the functor package as is in Lang being promoted to Functor [yeah, were back to patterns but with a better PROPOSAL]. +1 Does it matter if [functor] and [lang] have circular dependencies? Not that they will. it appears that [functor] will need to depend on [lang] for exception nesting. hopefully, lang will not need to depend on functor. if it does, then maybe it shows that the factoring has gone a bit wrong and we need to think about it again. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [configuration] XmlConfiguration
I haven't been following the XML configuration thread, but I've used the open source Castor XML package for this purpose (www.exolab.org). This package does far more than simple property setting, and can handle marshalling and umarshalling (of xml) of complex object graphs. Features too numerous to mention here. The reason I bring it up, is you may want to look into this project if you're not already aware of it. It may be a good source of ideas. Tom Drake -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 11:13 AM To: Jakarta Commons Developers List Subject: Re: [configuration] XmlConfiguration I use XML configuration in my day job. Here's some info to act as additional requirements: Out requirements were locale based XML configuration, ie. as per resource bundles, thus ProjectResources.xml could be overriden in french by ProjectResources_fr.xml. Our structure allowed four types of data: ITEM key= value= / LIST key= ITEM value= / /LIST MAP key= ITEM key= value= / /MAP XML AnyXML / /XML So yes, there are many many possibilties here. And one solution probably won't work. Stephen 10 other projects also have their implementation and they don't want to switch :- it definitly doesn't make sense to have 10 implemetations for something like reading an xml config file!!! is it really impossible to find a solution which can be used by all projects?? let's join forces to find a way to have one configuration package!!! Martin, the main problem might be that every application has a different idea of how their XML markup should look like. With properties it's easy: foo.bar.baz = blo with XML: 1) property name=foo.bar.baz value=blo/ 2) property name=foo.bar.baz valueblo/value /property 3) package name =foo package name=bar property name=baz valueblo/value /property /package /package 4) property namefoo.bar.baz/name valueblo/value /property And so on. Now find a common denominator. :-) The XMLConfiguration is useless if we can't write a DTD for it. I personally would go for being able to parse 1 and 2. (3 is ugly and 4 is ambigous. What if there is more than one name/ tag?. 1 is nice and compact and 2 allows multi-value properties). I got the code you sent me. Will look into it tonight. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DoubleMetaphone
I just came across the Codec commons project (we're already using HttpClient where I work) while looking for a Base64 encoder/decoder. While looking through the CVSweb, I noticed the Metaphone and SOUNDEX implementations...I've done implementations of DoubleMetaphone (based on public-domain code - I had permission from Ed Parrish to re-implement his code in Java), and Nysiis and would like to offer them to this project. You can find them here: http://www.bgw.org/projects/java/phonetic/ http://www.bgw.org/projects/java/phonetic/DoubleMetaphone.java http://www.bgw.org/projects/java/phonetic/Nysiis.java I'm not currently on commons-dev, so please CC me directly with any discussion. Thank you for your time, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED]http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/digester IDBean.java IDTest1.xml SimpleReadTest.xml TestIDRead.java
rdonkin 2002/12/11 14:12:11
Modified:betwixt/src/java/org/apache/commons/betwixt
ElementDescriptor.java
betwixt/src/java/org/apache/commons/betwixt/digester
XMLIntrospectorHelper.java
betwixt/src/java/org/apache/commons/betwixt/expression
MethodUpdater.java
betwixt/src/java/org/apache/commons/betwixt/io
BeanCreateRule.java BeanReader.java
betwixt/src/test/org/apache/commons/betwixt
TestBeanReader.java
betwixt/src/test/org/apache/commons/betwixt/digester
IDBean.java IDTest1.xml SimpleReadTest.xml
TestIDRead.java
Log:
Big changes for what was a small problem. I think that there was a bad fix to a bug
which had broken an untested part of the system. Note that the xml produced by these
changes differs from that created before. I'm pretty sure that this is how it used to
work but this may break some things.
Revision ChangesPath
1.4 +3 -2
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/ElementDescriptor.java
Index: ElementDescriptor.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/ElementDescriptor.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ElementDescriptor.java1 Jul 2002 18:43:00 - 1.3
+++ ElementDescriptor.java11 Dec 2002 22:12:10 - 1.4
@@ -129,8 +129,9 @@
public String toString() {
return
-ElementDescriptor[qname= + getQualifiedName() + ,class= +
getPropertyType()
-+ ,singular= + getSingularPropertyType() + ];
+ElementDescriptor[qname= + getQualifiedName() + ,pname= +
getPropertyName()
++ ,class= + getPropertyType() + ,singular= +
getSingularPropertyType()
++ ,updater= + getUpdater() + ];
}
/** Creates a codeElementDescriptor/code with namespace URI and qualified
name */
1.10 +15 -5
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java
Index: XMLIntrospectorHelper.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/digester/XMLIntrospectorHelper.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- XMLIntrospectorHelper.java7 Nov 2002 16:15:08 - 1.9
+++ XMLIntrospectorHelper.java11 Dec 2002 22:12:11 - 1.10
@@ -351,16 +351,21 @@
Class[] types = method.getParameterTypes();
if ( types != null types.length == 1 ) {
String propertyName = Introspector.decapitalize(
name.substring(3) );
+if ( log.isTraceEnabled() ) {
+log.trace( name + - + propertyName );
+}
// now lets try find the ElementDescriptor which displays
// a property which starts with propertyName
// and if so, we'll set a new Updater on it if there
// is not one already
-ElementDescriptor descriptor = findGetCollectionDescriptor(
introspector, rootDescriptor, propertyName );
+ElementDescriptor descriptor =
+findGetCollectionDescriptor( introspector,
rootDescriptor, propertyName );
-if ( log.isDebugEnabled() ) {
-log.debug( !! + propertyName + - +
descriptor);
-}
+if ( log.isDebugEnabled() ) {
+log.debug( !! + propertyName + - + descriptor );
+log.debug( !! + name + - +
descriptor.getPropertyName() );
+}
if ( descriptor != null ) {
descriptor.setUpdater( new MethodUpdater( method ) );
@@ -440,7 +445,12 @@
// create the Map of propertyName - descriptor that the PluralStemmer will
choose
Map map = new HashMap();
//String propertyName = rootDescriptor.getPropertyName();
-if (propertyName != null) {
+if ( log.isTraceEnabled() ) {
+log.trace( findPluralDescriptor( + propertyName
++ ):root property name= + rootDescriptor.getPropertyName() );
+}
+
+if (rootDescriptor.getPropertyName() != null) {
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt PersonListBean.java person-list.xml
rdonkin 2002/12/11 14:12:39
Added: betwixt/src/test/org/apache/commons/betwixt
PersonListBean.java person-list.xml
Log:
Big changes for what was a small problem. I think that there was a bad fix to a bug
which had broken an untested part of the system. Note that the xml produced by these
changes differs from that created before. I'm pretty sure that this is how it used to
work but this may break some things.
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/PersonListBean.java
Index: PersonListBean.java
===
/*
* $Header:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/PersonListBean.java,v
1.1 2002/12/11 22:12:39 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2002/12/11 22:12:39 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 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 acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements 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 Group.
*
* 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/.
*
* $Id: PersonListBean.java,v 1.1 2002/12/11 22:12:39 rdonkin Exp $
*/
package org.apache.commons.betwixt;
import java.util.List;
import java.util.ArrayList;
/** pBean to test lists of people/p
*
* @author Robert Burrell Donkin
* @version $Revision: 1.1 $
*/
public class PersonListBean {
private ArrayList people = new ArrayList();
public PersonListBean() {}
public List getPersonList() {
return people;
}
public void addPerson(PersonBean person) {
people.add(person);
}
}
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/person-list.xml
Index: person-list.xml
===
?xml version='1.0' ?
PersonListBean
personList
person
age22/age
nameAthos/name
/person
person
age25/age
namePorthos/name
/person
person
age23/age
nameAramis/name
/person
person
age18/age
nameD'Artagnan/name
/person
Re: [codec] Re: DoubleMetaphone
Definitely. I've got a bunch of codec things that built up while I was away [I've been submitting patches when they've been sitting around for a bit]. I'll add this to the list and try to push them through. Hopefully as codec gains submissions, it can gain a bit of life. Hen Great! I'm glad these contributions will be of use. Is there anything I should do to prepare the code? Javadoc standards? Code formatting standards? Licensing declaration? Whatever? I'm not looking for check-in privileges, just to contribute these modules. Thanks again, Kyle On Wed, 11 Dec 2002, Kyle R . Burton wrote: I just came across the Codec commons project (we're already using HttpClient where I work) while looking for a Base64 encoder/decoder. While looking through the CVSweb, I noticed the Metaphone and SOUNDEX implementations...I've done implementations of DoubleMetaphone (based on public-domain code - I had permission from Ed Parrish to re-implement his code in Java), and Nysiis and would like to offer them to this project. You can find them here: http://www.bgw.org/projects/java/phonetic/ http://www.bgw.org/projects/java/phonetic/DoubleMetaphone.java http://www.bgw.org/projects/java/phonetic/Nysiis.java I'm not currently on commons-dev, so please CC me directly with any discussion. Thank you for your time, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED]http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED]http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [codec] Re: DoubleMetaphone
Straight off the top of my head, just match the format of Metaphone in any obvious ways. Copy the license declaration, javadoc as much as it does, don't do any blatant things it doesn't do code standard wise. Obeying the Sun code standard is usually the easy thing to do. There's probably a webpage to point you to, but I haven't got it to hand atm. Hen On Wed, 11 Dec 2002, Kyle R . Burton wrote: Definitely. I've got a bunch of codec things that built up while I was away [I've been submitting patches when they've been sitting around for a bit]. I'll add this to the list and try to push them through. Hopefully as codec gains submissions, it can gain a bit of life. Hen Great! I'm glad these contributions will be of use. Is there anything I should do to prepare the code? Javadoc standards? Code formatting standards? Licensing declaration? Whatever? I'm not looking for check-in privileges, just to contribute these modules. Thanks again, Kyle On Wed, 11 Dec 2002, Kyle R . Burton wrote: I just came across the Codec commons project (we're already using HttpClient where I work) while looking for a Base64 encoder/decoder. While looking through the CVSweb, I noticed the Metaphone and SOUNDEX implementations...I've done implementations of DoubleMetaphone (based on public-domain code - I had permission from Ed Parrish to re-implement his code in Java), and Nysiis and would like to offer them to this project. You can find them here: http://www.bgw.org/projects/java/phonetic/ http://www.bgw.org/projects/java/phonetic/DoubleMetaphone.java http://www.bgw.org/projects/java/phonetic/Nysiis.java I'm not currently on commons-dev, so please CC me directly with any discussion. Thank you for your time, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED]http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED]http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][lang] Functors, pre-vote
Does it matter if [functor] and [lang] have circular dependencies? Not that they will. it appears that [functor] will need to depend on [lang] for exception nesting. hopefully, lang will not need to depend on functor. if it does, then maybe it shows that the factoring has gone a bit wrong and we need to think about it again. The proposal will be to break the dependency on [lang]. Exceptions will be independent of NestedException, and any other [lang] code (believed to only be SerialisationUtils.clone()) will be copied. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Validator Formsets search by Locale
Hi,
Seem to have run into another issue with the validator. I have a
validator.xml
?xml version=1.0 encoding=UTF-8?
!DOCTYPE form-validation PUBLIC -//Apache Software Foundation//DTD Commons
Validator Rules Configuration 1.0//EN
http://jakarta.apache.org/commons/dtds/validator_1_0.dtd;
!-- Define the Validations for the Logon related forms --
form-validation
global /
formset
form name=logonForm
field property=username depends=required
arg0 key=text.general.username /
/field
field property=password depends=required
arg0 key=text.general.password /
/field
/form
/formset
/form-validation
I.e. its in the default/non specified locale. (BTW The globals are defined
elsewhere and load properly)
So, I use validator successfully on a logon page. If a user comes to the
page and their locale is not set (i.e. no entry under Globals.LOCALE_KEY at
Session scope) that the default locale of en (no country) is set.
Then I find that in the ValidatorResources.java:
public Form get(String language, String country, String variant, Object
formKey)
method, that the call
Vector v = (Vector) hFormSets.get(key);(where key = en)
that the formset is successfully returned, and then the validator form
(logonForm) is successfully found.
However if there is an entry in Globals.LOCALE_KEY, Session scope, and their
locale is set to en_AU, that the call to
Vector v = (Vector) hFormSets.get(key);(where key = en_AU)returns
null,
And hence no validator form can be found (of course, cos there's no formset
to find it in).
So, while its easy for me to fix this in the logon area, simply by removing
the session scope LOCALE_KEY, it does present a problem in other parts of
the application where a value is set.
My understanding that the formsets should be searched for the given form in
order of
*lilanguage + country + variant/li
*lilanguage + country/li
*lilanguage/li
*lidefault locale/li
Where as (from what I see in that method), the formset for the
language,country,variant passed in is found, then it is search for the given
formKey name The more I look at this method the more it looks like a
bug,
Given
!ELEMENT formset (constant*, form+)
!ATTLIST formset language CDATA #IMPLIED
country CDATA #IMPLIED
!ELEMENT form(field+ )
!ATTLIST formname CDATA #REQUIRED
I.e. formsets have language and country, forms do not.
And that the code
key = /// KEYS ARRANGE IN ORDER SPECIFIED ABOVE
formsets = v.elements();
while (formsets.hasMoreElements()) {
o = formsets.nextElement();
if (o != null) {
fs = (FormSet)o;
if ((fs != null) (fs.getForm(formKey) != null)) {
return fs.getForm(formKey);
}
}
}
keeps getting repeated (with the key changing, but the code does not...)
I'm pretty new to the validator stuff so I could definitely be barking up
the wrong tree, please advise if I am, and if so would appreciate input on
how I should set up my formsets (and even my LOCAL keys) to make the search
correctly
Should the code be more like the code in the attached file (again probably
got stuff all messed up in my head)
Thanks
Gary
validatorResource-get-method.java
validatorResource-get-method.java
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15297] New: - [HttpClient] Authenticator() - ability to perform alternate authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15297
[HttpClient] Authenticator() - ability to perform alternate authentication
Summary: [HttpClient] Authenticator() - ability to perform
alternate authentication
Product: Commons
Version: Nightly Builds
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: HttpClient
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
My post to the user group. The developer replied suggesting I enter an
enhancement request.
-Original Message-
From: Gustafson, Vicki [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 12 December 2002 5:03 AM
To: Jakarta Commons Users List
Subject: [HttpClient] Authentication using Basic
Is there a way to specify which authentication scheme you would like the client
to use if several schemes are returned in the www-auth header?
I'm performing a simple post using the httpClient. The server returns a 401 at
which point the httpClient tries to authenticate with the server. The
following header is received:
Attempting to parse authenticate header: 'WWW-Authenticate: Negotiate, NTLM,
Basic realm=XXXwhateverXXX
I need to authenticate using Basic, but the Authenticator class will only try
the most secure scheme: NTLM. Is there a setting or parameter I can set to
force the httpClient to use Basic?
thanks,
Vicki
// determine the most secure request header to add
Header requestHeader = null;
if (challengeMap.containsKey(ntlm)) {
String challenge = (String) challengeMap.get(ntlm);
requestHeader = Authenticator.ntlm(challenge, method, state,
responseHeader);
} else if (challengeMap.containsKey(digest)) {
String challenge = (String) challengeMap.get(digest);
String realm = parseRealmFromChallenge(challenge);
requestHeader = Authenticator.digest(realm, method, state,
responseHeader);
} else if (challengeMap.containsKey(basic)) {
String challenge = (String) challengeMap.get(basic);
String realm = parseRealmFromChallenge(challenge);
requestHeader = Authenticator.basic(realm, state, responseHeader);
} else if (challengeMap.size() == 0) {
throw new HttpException(No authentication scheme found in '
+ authenticateHeader + ');
} else {
throw new UnsupportedOperationException(
Requested authentication scheme + challengeMap.keySet()
+ is unsupported);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
**developer response**
Currently there isn't, however we probably should be more intelligent about
falling back to other authentication schemes based on the type of credentials
provided. Having said this I'm not sure it conforms to the HTTP spec strictly
(which states that the client must use the strongest authentication scheme it
supports, there's a grey area here because if your application doesn't provide
a dialog or similar for the user to enter NTLM credentials it can only support
basic or digest authentication, despite HTTPClient supporting NTLM).
What I'd like to see happen is:
When NTLM authentication is requested as top priority but only
UsernamePasswordCredentials are available instead of NTLMCredentials we fall
back to one of the other schemes. In general this would mean that:
if an authentication scheme is requested and a credentials object of the wrong
type is provided, HTTPClient should assume (probably optionally or only in non-
strict mode) that the requested authentication scheme is not supported and fall
through to other options.
Achieving this would require a reasonably amount of refactoring of the
Authenticator class but shouldn't be impossible. Unfortunately I don't have
time to do it myself at the moment but I'd be happy to help out if you felt
like doing it, otherwise logging an enhancement bug in Bugzilla would be a good
way to record this request until someone has time to actually implement it.
Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] [patch] changes for ArrayListIterator was: Re: [collections] private member access in o.a.c.collections.iterators
Hi Stephen, Rich,
Would it be possible for you to refactor to remove
UnmodifiableArrayListIterator? Thanks ;-)
No prob. Please find attached updated patches files as per your
suggestion. The comments for each file are as per the previous message
except:
- ArrayIterator.patch : changes as before, except that the length
field has been renamed to endIndex, which is a far better reflection
of what the field does. This cannot break any code as the field was
private up to this point.
- ArrayListIterator.java : now directly extends ArrayIterator.
IteratorUtils now has an unmodifiableListIterator(Iterator) method
that wraps iterators to make them unmodifiable. I would prefer to
keep this as the only way to make an unmodifiable iterator.
I believe there is actually a strong case for this class, which I'll
come back to at some point maybe after xmas. But it's gone from the
hierarchy now.
Also, I am very uncomfortable with ArrayListIterator being a subclass
of UnmodifiableArrayListIterator. There is no 'is a' relationship
here, and worse, if I declared a method to take in an
UnmodifiableArrayListIterator it would accept a modifiable one which
would probably not be what I want.
Again, the UnmodifiableArrayListIterator is gone, so this is a bit
academic. But for the hell of it ;) Let's suppose we decided that we
did want to have both an ArrayListIterator and an
UnmodifiableArrayListIterator. The classes are almost identical, apart
from the #set method, which is functinal in ArrayListIterator and
throws an UnsupportedOperationException in UnmodArrayListIterator The
first thing that popped into my head was to have UnmodArrayListIterator
extend ArrayListIterator. I was going to submit the classes in that
state, but as I was reviewing the code, the 'extend' keyword caught my
eye. UnmodArrayListIterator doesn't really extend the functionality of
ArrayListIterator, unless one means 'extend' in the sense of 'restrict'
;) The UnmodArrayListIterator provides *less* functionality, and it is
the ArrayListIterator that extends the functionality that
UnmodArrayListIterator provides.
So, I rearranged the hierarchy, with ArrayListIterator 'extending'
UnmodArrayListIterator to support the #set operation, and I submitted
this.
But after your comments, I do see that there is a problem with the
structure, and it is tied in with the 'is-a' relation, but not in the
quite so obvious way. It is not always important that the 'is-a'
relationship holds. This is the case when the parent class is not
really part of the public interface per se. For instance, ArrayList
extends AbstractList, but it is not the case that ArrayList 'is-a'
AbstractList. But this isn't really a problem when the parent class is
a base implementation that implements an interface type. So, it is ok
to have hiearchies of which this is an (idealized/edited) example:
AbstractList implements --- List
|
--
| |
ArrayListLinkedList
This is ok because the public interfaces use the 'List' type, and the
existence of the AbstractList is not really of interest to the
end-user. Now take the case of the ArrayListIterator and the
UnmodArrayListIterator. It had been my thought that the primary useage
of these classes would be via static methods in IteratorUtils:
IteratorUtils.arrayListIterator(array) : ListIterator
IteratorUtils.unmodifiableArrayListIterator(array) : ListIterator
Since both of these operations return the interface type
('ListIterator'), *initially* it would appear that it doesn't really
matter to the end-user what the hierarchial relationship (if any)
between the two classes is. So, the hierarchial relationship is really
only of 'academic' design interest to the developers of the classes.
Both of these relationships have problems:
UnmodifableArrayListIterator
^
| // violates 'is-a'
|
ArrayListIterator
and also:
ArrayListIterator
^
| // violates 'extends' (maybe)
|
UnmodifableArrayListIterator
I chose the latter design: my reasoning was that it was better to
violate 'is-a', since the relationship was not being made public
(because of the use of the static factory methods), and it is generally
ok to violate 'is-a' in circumstances as per AbstractList just
discussed. However, as Stephen pointed out (thanks!), this is a bad
choice, because: if I declared a method to take in an
UnmodifiableArrayListIterator it would accept a modifiable one which
would probably not be what I want. So, what to do? This might be design
overkill, but I think the best structure is probably as per the List
case:
AbstractArrayListIterator implements --- ListIterator
|
| |
ArrayListIterator UnmodifiableArrayListIterator
where AbstractArrayListIterator would declare the #set method to be
abstract. Anyway! I hadn't meant that to be so verbose ;) Do
Re: [codec] Re: DoubleMetaphone
Straight off the top of my head, just match the format of Metaphone in any obvious ways. Copy the license declaration, javadoc as much as it does, don't do any blatant things it doesn't do code standard wise. - Copied license: check - Added Javadoc comments: check Obeying the Sun code standard is usually the easy thing to do. There's probably a web-page to point you to, but I have not got it to hand atm. I'm not 100% familiar with the Sun code standard...but I've made the two modules as close to Metaphone.java as I can tell in format. One other thing - I modified the two modules to implement the Encoder interface. As I was implementing an equivalent for isMetaphoneEqual() in DoubleMetaphone and Nysiis, I got the feeling that it might be a method declared in the Encoder interface. Maybe a method like: public boolean isEncodeEqual( String s1, String s2 ); Then these encoders would all be interchangeable at the level of the Encoder interface that you've already defined. Though the EncoderComparator does serve a similar purpose now that I'm looking at it's implementation. I originally created these two classes so they could be used as Oracle Java stored procedures in the database. To be supported under Oracle, you have to have a static method that can be invoked by the database -- instead of having to write one to wrap the encode() calls in these two classes, I just added another method to each: sencode(), to indicate a 'static' encode. Then they can be invoked directly from Oracle as Java stored procedures. Just food for thought. I'm no Java guru - can a static method be declared in an interface has having to be implemented in an implementing class? Best regards, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED]http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [codec] Re: DoubleMetaphone
One last annoyance...I put the new classes in a sub-directory of the old ones: http://www.bgw.org/projects/java/phonetic/jakarta-commons-codec/ They already have changed package names for org.apache.commons.codec. Thanks again, Kyle R. Burton -- -- Wisdom and Compassion are inseparable. -- Christmas Humphreys [EMAIL PROTECTED]http://www.voicenet.com/~mortis -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[logging] Adding jndi java:env support
Based on Ceki's email - I think it would be a good idea to add this mechanism in the default logging factory. My proposal is to insert a lookup for java:comp/env/CommonsLoggingFactory at the top of the discovery chain. If such a factory exists, it'll be used to create the logger. If not, we'll continue with the normal mechanism. The big downsize is that we'll add a compile dependency on JNDI ( the code can catch ClassNotFound - and run even if JNDI is not present ). This will allow containers using commons-logging to better enforce isolation between apps. In addition, I think we should add an optional domain name prefix. If such a prefix is set ( for example in java:comp/env/CommonsLoggingDomain) then it'll be added in front of every log name that is created. For example, if the container will set myHost:8080/myApp/ as a prefix, logs created in that app will be named: myHost:8080/myApp/org.apache. As a note, web.xml allows you to define and set a number of jndi entries. This could also be used to allow user-based tuning, but in general the container settings should be able to take preference . Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commons-fileupload
On Tue, 10 Dec 2002, Nan Xiong wrote: Dear commmons developers, Can someone in this mailing list tell me the expected release date for commons-fileupload 1.0? If this is not the right mailing list or address to send these kind of questions, which email addresses will be proper? There isn't really an expected date. See the following for an explanation of the Jakarta approach to releasing software: http://jakarta.apache.org/struts/faqs/helping.html#release The above link is for a Struts page, but the explanation is equally applicable to Commons. That said, what FileUpload is waiting for is unit tests. There are a couple of very basic negative tests, but nobody has got around to creating more comprehensive tests yet. Of course, contributions are always welcome! ;-) -- Martin Cooper Thanks Nan Xiong -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15170] - BeanUtils.setProperty doesn't convert primitive wrappers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170 BeanUtils.setProperty doesn't convert primitive wrappers --- Additional Comments From [EMAIL PROTECTED] 2002-12-12 05:17 --- Created an attachment (id=4134) Ignore the previous patch, it has an error -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15170] - BeanUtils.setProperty doesn't convert primitive wrappers
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15170 BeanUtils.setProperty doesn't convert primitive wrappers --- Additional Comments From [EMAIL PROTECTED] 2002-12-12 05:56 --- Created an attachment (id=4135) Fix NPE in previous patch update. Passes all tests in beanutils -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14591] - Serialization problem with org.apache.commons.validator.ValidatorResult$ResultStatus
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14591 Serialization problem with org.apache.commons.validator.ValidatorResult$ResultStatus --- Additional Comments From [EMAIL PROTECTED] 2002-12-12 06:44 --- My feeling on this is that: To date, all validator rules in Apache source either return a boolean (pass/fail) or a Serializable type (Date, Long, etc). Therefore, in the interest of fixing this problem, I think we should declare that the type of any object returned by a validation rule must implement Serializable, and add Serializable to the subclass. Any objections? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [configuration] XmlConfiguration
Henning P. Schmiedehausen wrote: Martin Poeschl [EMAIL PROTECTED] writes: Hi, 10 other projects also have their implementation and they don't want to switch :- it definitly doesn't make sense to have 10 implemetations for something like reading an xml config file!!! is it really impossible to find a solution which can be used by all projects?? let's join forces to find a way to have one configuration package!!! Martin, the main problem might be that every application has a different idea of how their XML markup should look like. With properties it's easy: foo.bar.baz = blo with XML: 1) property name=foo.bar.baz value=blo/ 2) property name=foo.bar.baz valueblo/value /property 3) package name =foo package name=bar property name=baz valueblo/value /property /package /package 4) property namefoo.bar.baz/name valueblo/value /property And so on. Now find a common denominator. :-) The XMLConfiguration is useless if we can't write a DTD for it. right. we should look which format is used by most of the projects in jakarta land. maybe the target to replace existing code is unreachable :-( but we can offer a working implementation and hopefully new projects will use our stuff and will not start another implementation. martin I personally would go for being able to parse 1 and 2. (3 is ugly and 4 is ambigous. What if there is more than one name/ tag?. 1 is nice and compact and 2 allows multi-value properties). I got the code you sent me. Will look into it tonight. Regards Henning -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
