Re: hello to u all
I would like to know - what shell I do in order to contribute to the Common project? First of all, a warm welcome, share and enjoy! :-) Then a suggestion on one way to help out: a) Use one, some, or all of the components (as per the latest release) in RealCode of your own. b) Get impressed of what the components can do, or what the documentation tells you. c) Get irritated over what some component cannot do, or what the documentation doesn't tell you. d) Check out the latest CVS version of the component and see if it is fixed there. e) If not: tell people on the list that you intend to fix it, or at least point the annoyance out. ...and you're into it! I guess that a) (use the stuff) is the important point. /O -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14384] - ValidatorResources.get-method not working properly
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=14384. 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=14384 ValidatorResources.get-method not working properly --- Additional Comments From [EMAIL PROTECTED] 2002-11-08 13:09 --- Created an attachment (id=3775) Patch of the get-method -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/junit suite.jelly
jstrachan2002/11/08 10:35:06
Modified:jelly/src/test/org/apache/commons/jelly/junit suite.jelly
Log:
enhanced test case to demonstrate that XPath should not find elements in a document
with a namespace URI but no prefix - unless the XPath expression has a prefix.
This is a very common XPath gotcha.
Revision ChangesPath
1.5 +5 -1
jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/junit/suite.jelly
Index: suite.jelly
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/junit/suite.jelly,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- suite.jelly 8 Nov 2002 18:27:52 - 1.4
+++ suite.jelly 8 Nov 2002 18:35:06 - 1.5
-54,7 +54,11
test:assert test=${ex != null}We should have created an
exception/test:assert
- The exception was: ${ex.message}
+j:catch var=ex
+ test:assert xpath=$doc/foo/barThis should always fail, since foo
is not in the empty namespace/test:assert
+ /j:catch
+
+ test:assert test=${ex != null}We should have created an
exception/test:assert
/test:case
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/dbcp/src/test/org/apache/commons/dbcp/jdbc2pool TestJdbc2PoolDataSource.java
rwaldhoff2002/11/08 10:51:07
Modified:dbcp build.xml maven.xml
dbcp/doc test.jocl
dbcp/src/java/org/apache/commons/dbcp/cpdsadapter
ConnectionImpl.java
PoolablePreparedStatementStub.java
PooledConnectionImpl.java
dbcp/src/test/org/apache/commons/dbcp TestAll.java
TestJOCLed.java TestManual.java
TesterStatement.java
dbcp/src/test/org/apache/commons/dbcp/jdbc2pool
TestJdbc2PoolDataSource.java
Added: dbcp/src/test testpool.jocl
dbcp/src/test/org/apache/commons/dbcp
TestConnectionPool.java
Log:
refactor/cleanup test suite a bit
apply generic tests to more configurations
fix a couple of bugs that revealed
Revision ChangesPath
1.16 +6 -1 jakarta-commons/dbcp/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/dbcp/build.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- build.xml 5 Sep 2002 23:38:49 - 1.15
+++ build.xml 8 Nov 2002 18:51:06 - 1.16
@@ -239,6 +239,11 @@
debug=true
deprecation=true
optimize=true/
+ copy todir=${dest.classes} filtering=no
+fileset dir=${source.src.test} defaultexcludes=no
+ include name=testpool.jocl/
+/fileset
+ /copy
/target
!-- # --
1.2 +9 -2 jakarta-commons/dbcp/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/jakarta-commons/dbcp/maven.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- maven.xml 23 Jul 2002 16:43:14 - 1.1
+++ maven.xml 8 Nov 2002 18:51:06 - 1.2
@@ -1,4 +1,11 @@
-project default=java:jar
- xmlns:j=jelly:core
+project default=java:jar xmlns:j=jelly:core
+
+postGoal name=test:compile
+ copy todir=target/test-classes
+fileset dir=src/test
+ include name=testpool.jocl/
+/fileset
+ /copy
+/postGoal
/project
1.2 +2 -2 jakarta-commons/dbcp/doc/test.jocl
Index: test.jocl
===
RCS file: /home/cvs/jakarta-commons/dbcp/doc/test.jocl,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- test.jocl 14 Apr 2001 17:16:57 - 1.1
+++ test.jocl 8 Nov 2002 18:51:07 - 1.2
@@ -19,10 +19,10 @@
/object
object class=org.apache.commons.pool.impl.GenericKeyedObjectPoolFactory
object class=org.apache.commons.pool.KeyedPoolableObjectFactory
null=true/
- int value=5/
+ int value=10/
byte value=1/
long value=2000/
- int value=5/
+ int value=10/
boolean value=true/
boolean value=true/
long value=1/
1.2 +3 -2
jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java
Index: ConnectionImpl.java
===
RCS file:
/home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ConnectionImpl.java 5 Aug 2002 06:42:01 - 1.1
+++ ConnectionImpl.java 8 Nov 2002 18:51:07 - 1.2
@@ -3,7 +3,7 @@
/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001 The Apache Software Foundation. All rights
+ * Copyright (c) 2001-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -170,6 +170,7 @@
public void close()
throws SQLException
{
+assertOpen();
isClosed = true;
pooledConnection.notifyListeners();
}
1.2 +8 -8
jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PoolablePreparedStatementStub.java
Index: PoolablePreparedStatementStub.java
===
RCS file:
/home/cvs/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PoolablePreparedStatementStub.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PoolablePreparedStatementStub.java5 Aug 2002 06:42:01 - 1.1
+++ PoolablePreparedStatementStub.java8 Nov 2002 18:51:07 - 1.2
@@ -1,5 +1,5 @@
/*
DO NOT REPLY [Bug 14394] New: - Excessive exceptions log under security manager
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=14394. 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=14394 Excessive exceptions log under security manager Summary: Excessive exceptions log under security manager Product: Commons Version: 1.5 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm currently forced to use BeanUtils/Struts under the J2EE-RI server, which by default has much a stricter security policy than Tomcat etc. To my surprise, this resulted in an initial 400+kB of logs generated, filled with AccessControlExceptions including stack traces, and always the same. Apparently during Struts parsing it's config file using Digester, and thus BeanUtils. However, the problem does *not* at all hurt the functionality of the application. IMHO, the exception should just be logged once (on first encounter). There could be a static boolean variable to indicated the situation for further invocations. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: installing jakarta code Was: using commons components and logging
So you suggest that we no longer create zips/tar.gz's and just put jars on a Maven repository and tell everyone that to use a library they must build with Maven? I think Maven could help with this, or a similar tool, but in a different way. When the tool creates our distribution, it also creates an ant file which contains the dependencies that are needed and can be run. ant -f get_dependencies.xml this sucks each dependency down [no project.xml remember, it's just a part of the tar.gz] and puts them in a directory called 'dependencies' or 'lib' or something. It can happily use the maven biblio, though that implies that a much faster build - maven repo turn around is needed. What I'm looking for are ideas that will work with the existing structure and not revolutions :) So, how can we re-package our current code so that user's don't plough every-time into the dependency hunt. Hen On Sat, 9 Nov 2002 [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote on 08/11/2002 01:28:26 PM: There has got to be a better way for us to handle installs and cross-dependencies, withing Commons and within Jakarta projects. It has to be the number one problem that users have. Hence the development of Maven. Hen -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: installing jakarta code Was: using commons components and logging
-Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 08, 2002 3:55 PM To: Jakarta Commons Developers List Subject: Re: installing jakarta code Was: using commons components and logging So you suggest that we no longer create zips/tar.gz's and just put jars on a Maven repository and tell everyone that to use a library they must build with Maven? Maven will generate the zips/tar.gz's, so others can still download the full distribution. Having [lang] mavenized would not force other projects to mavenize just to use the [lang] library. I think Maven could help with this, or a similar tool, but in a different way. When the tool creates our distribution, it also creates an ant file which contains the dependencies that are needed and can be run. ant -f get_dependencies.xml this sucks each dependency down [no project.xml remember, it's just a part of the tar.gz] and puts them in a directory called 'dependencies' or 'lib' or something. It can happily use the maven biblio, though that implies that a much faster build - maven repo turn around is needed. What I'm looking for are ideas that will work with the existing structure and not revolutions :) So, how can we re-package our current code so that user's don't plough every-time into the dependency hunt. I believe Maven provides a great solution to this issue. The site that Maven generates does contain a list of a project release's dependencies (not that [lang] has any, but this is a nice standard place for a project to publish it's dependency list). Personally I'd love to see all of commons migrate toward Maven, for this very reason. It provides standard documentation and a standard way to build projects. And for a project like [lang], Maven is not all that revolutionary. I Mavenized a similar commons-type project at my work with very little effort. And the bang for the buck was incredible. Hen On Sat, 9 Nov 2002 [EMAIL PROTECTED] wrote: Henri Yandell [EMAIL PROTECTED] wrote on 08/11/2002 01:28:26 PM: There has got to be a better way for us to handle installs and cross-dependencies, withing Commons and within Jakarta projects. It has to be the number one problem that users have. Hence the development of Maven. Hen -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: installing jakarta code Was: using commons components and logging
On Fri, 8 Nov 2002, Steven Caswell wrote: -Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] So you suggest that we no longer create zips/tar.gz's and just put jars on a Maven repository and tell everyone that to use a library they must build with Maven? Maven will generate the zips/tar.gz's, so others can still download the full distribution. Having [lang] mavenized would not force other projects to mavenize just to use the [lang] library. That's the rub. Full distribution. I want something downloads the dependencies as well, not just the lang distro but also anything that lang is dependent on. Maybe this means a better page than the current download page where users just click from a list, something where you select something to download and after you click on that it takes you to a page which lists the dependencies and says 'do you have all of these?'. What I'm looking for are ideas that will work with the existing structure and not revolutions :) So, how can we re-package our current code so that user's don't plough every-time into the dependency hunt. I believe Maven provides a great solution to this issue. The site that Maven generates does contain a list of a project release's dependencies (not that [lang] has any, but this is a nice standard place for a project to publish it's dependency list). Personally I'd love to see all of commons migrate toward Maven, for this very reason. It provides standard documentation and a standard way to build projects. It still is far away in this respect though. The site has no standardised download ability. [I'd love to add such a thing, and hope that a thread like this could decide what that standardised downloading is.] And for a project like [lang], Maven is not all that revolutionary. I Mavenized a similar commons-type project at my work with very little effort. And the bang for the buck was incredible. Agreed. Lang is mavenised, I use maven at work now accross the board. Gotta learn reactor though still. However, Maven isn't really the solution here. We have to assume that our users are not using Maven. Thus we need to offer a download/install process which handles the dependency issue without forcing them to enter the maven-user world. The fact that thigns like Collections are not wanting to be dependent on another project [ie Lang] because it confuses the user is a sign that somethign is very wrong. Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/jrcs/src/java/org/apache/commons/jrcs/rcs Archive.java
juanco 2002/11/08 13:29:34
Modified:jrcs/src/java/org/apache/commons/jrcs/rcs Archive.java
Log:
Added method to retreive log message associated with a given revision.
Submitted by:Kyrre Kristiansen [[EMAIL PROTECTED]]
Reviewed by: [EMAIL PROTECTED]
Revision ChangesPath
1.4 +30 -1
jakarta-commons-sandbox/jrcs/src/java/org/apache/commons/jrcs/rcs/Archive.java
Index: Archive.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jrcs/src/java/org/apache/commons/jrcs/rcs/Archive.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Archive.java 8 Oct 2002 19:06:24 - 1.3
+++ Archive.java 8 Nov 2002 21:29:34 - 1.4
@@ -1194,6 +1194,35 @@
return (Node[]) result.toArray(new Node[result.size()]);
}
+
+
+/** Returns the log message associated with the given revision.
+ * @param version - the version to get the log message for
+ * @return the log message for the version.
+ * @exception - if the version does not exist for the archive.
+ */
+public String getLog(Version version)
+throws NodeNotFoundException
+{
+Node node = this.findNode(version);
+if (node == null)
+{
+throw new NodeNotFoundException(There's no version + version);
+}
+return node.getLog();
+}
+
+/** Returns the log message associated with the given revision.
+ * @param version - the version to get the log message for
+ * @return the log message for the version.
+ * @exception - if the version does not exist for the archive.
+ */
+public String getLog(String vernum)
+throws InvalidVersionNumberException, NodeNotFoundException
+{
+return getLog(new Version(vernum));
+}
+
}
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io - New directory
mvdb2002/11/08 13:45:12 jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [jdbc] JdbcUtil etc
-Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 08, 2002 1:17 PM To: Jakarta Commons Developers List Subject: [jdbc] JdbcUtil etc Does anyone know of a good apache-style license set of classes for helping with JDBC stuff? I'm thinking of things like: 1) A JdbcUtils which helps with closing rs, stat, conn. That simplifies MetaData work, that has a ResultSetIterator [yes I know BeanUtils has one of these, it's misplaced I think]. 2) A sequence-number handler. Something that is very generic and configurable at runtime. The code is out there it seems, but stuck inside things like object-bridge and other large projects. 3) Possibly a continuation of the ResultSetIterator. A java.util.Collection structure for viewing a JDBC connection. 4) An empty Driver wrapper set for people wanting to make quick hacks to their driver. For example, Oracle's latest driver has some crap with Timestamp. Easiest solution for me would be to take Commons JDBC Standard Wrapper Driver, extend ResultSet and convert an oracle.sql.Timestamp to java.sql.Timestamp without anyone noticing. 5) ?? Does such a thing exist? Should it exist? Should it be in sql? [I think not, unless the current sql wants a new name :) sql seems to be concerned with other things] Should ti be called jdbc? I've got some bits that I can start with, so am happy to make a proposal in sandbox, but thought I'd check no one has invented the wheel before. I don't know of anything that already exists, and I've looked around Jakarta a little bit to find one. I'd love to see a jdbc subproject. I've got a few things I could throw in as well. So I'm +1 that such a thing should exist, +1 for calling it jdbc and +1 for separating this kind of stuff from the current sql project (I agree, the sql project is different stuff). Hen -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [jdbc] JdbcUtil etc
On Fri, 8 Nov 2002, Steven Caswell wrote: I don't know of anything that already exists, and I've looked around Jakarta a little bit to find one. I'd love to see a jdbc subproject. I've got a few things I could throw in as well. So I'm +1 that such a thing should exist, +1 for calling it jdbc and +1 for separating this kind of stuff from the current sql project (I agree, the sql project is different stuff). Works for me as a sanity check :) I'm not insane! woo. maybe. I'll write a proposal and add a jdbc project with some initial code tonight/this w/e. You okay to be an initial committer on it? Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/io SAXContentHandler.java TestSAXBeanWriter.java
mvdb2002/11/08 14:09:01
Modified:betwixt/src/java/org/apache/commons/betwixt/io
SAXBeanWriter.java
Added: betwixt/src/test/org/apache/commons/betwixt/io
SAXContentHandler.java TestSAXBeanWriter.java
Log:
The SAXBeanWriter was incorrectly creating xml content, esp. body text was
misplaced. Fixed this and added a SAXContentHanlder and TestSaxBeanWriter.
Many thanks go to Harald Dietrich (contact at hdietrich.net) for providing the test
cases and a use scenario.
I removed the dependency on XMLSerializer (for people using Crimson ;) and made
another ContentHandler to prove it is working.
(the code with XMLSerializer also works though). I also removed a failure taking
place on the #text node, since those nodes cannot be avoided (thnx jt..)
Revision ChangesPath
1.4 +32 -35
jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/SAXBeanWriter.java
Index: SAXBeanWriter.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io/SAXBeanWriter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SAXBeanWriter.java19 Jul 2002 00:54:55 - 1.3
+++ SAXBeanWriter.java8 Nov 2002 22:09:01 - 1.4
@@ -61,26 +61,10 @@
*/
package org.apache.commons.betwixt.io;
-import java.beans.IntrospectionException;
-import java.io.BufferedWriter;
-import java.io.IOException;
-import java.io.OutputStream;
-import java.io.OutputStreamWriter;
-import java.io.Writer;
-import java.util.Iterator;
-import java.util.HashMap;
+import java.util.Stack;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-
-import org.apache.commons.betwixt.AttributeDescriptor;
-import org.apache.commons.betwixt.ElementDescriptor;
-import org.apache.commons.betwixt.XMLBeanInfo;
-import org.apache.commons.betwixt.XMLIntrospector;
-import org.apache.commons.betwixt.expression.Context;
-import org.apache.commons.betwixt.expression.Expression;
-import org.apache.commons.betwixt.io.id.SequentialIDGenerator;
-
import org.xml.sax.ContentHandler;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.AttributesImpl;
@@ -100,10 +84,15 @@
/** Where the output goes */
private ContentHandler contentHandler;
/** Log used for logging (Doh!) */
-private Log log = LogFactory.getLog( BeanWriter.class );
+private Log log = LogFactory.getLog( SAXBeanWriter.class );
private String lastElementName;
+/**
+ * Place holder for elements that are started.
+ */
+private Stack elementStack;
+
private AttributesImpl attributes;
private boolean elementWaiting = false;
@@ -141,12 +130,15 @@
/** Express an element tag start using given qualified name */
protected void expressElementStart(String qualifiedName) throws SAXException {
-// make sure any previous elements have been sent
-sendElementStart();
-// ok prepare for new one
-elementWaiting = true;
+if (elementStack == null) {
+elementStack = new Stack();
+}
+if (elementWaiting) {
+sendElementStart();
+}
attributes = new AttributesImpl();
-lastElementName = qualifiedName;
+elementStack.push(qualifiedName);
+elementWaiting = true;
}
protected void expressTagClose() {
@@ -156,8 +148,10 @@
/** Express an element end tag using given qualifiedName */
protected void expressElementEnd(String qualifiedName) throws SAXException {
-// make sure that we sent the last element to be handled
-sendElementStart();
+if (elementWaiting) {
+elementWaiting = false;
+sendElementStart();
+}
// can't handle namespaces yet
contentHandler.endElement(,,qualifiedName);
}
@@ -165,7 +159,8 @@
/** Express an empty element end */
protected void expressElementEnd() throws SAXException {
// last element name must be correct since there haven't been any tag in
between
-contentHandler.endElement(,,lastElementName);
+String lastElement = (String) elementStack.peek();
+contentHandler.endElement(,,lastElement);
}
/** Express body text */
@@ -173,6 +168,10 @@
// FIX ME
// CHECK UNICODE-CHAR CONVERSION!
// THIS WILL QUITE POSSIBLY BREAK FOR NON-ROMAN
+if (elementWaiting) {
+elementWaiting = false;
+sendElementStart();
+}
char[] body = text.toCharArray();
contentHandler.characters(body,
DO NOT REPLY [Bug 14263] - BeanReader returns no object when used with SAXParser
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=14263. 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=14263 BeanReader returns no object when used with SAXParser [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-11-08 22:16 --- I will put this on worksforme. If you can come with a reproducable testcase again which failes, then reopen it. You can always contact the mailinglist to further narrow down your problem. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14262] - SAXBeanWriter produces invalid XML
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=14262. 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=14262 SAXBeanWriter produces invalid XML [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-08 22:18 --- Fixed in cvs.. Harald can you please confirm this works ok for you? Notes : The SAXBeanWriter was incorrectly creating xml content, esp. body text was misplaced. Fixed this and added a SAXContentHanlder and TestSaxBeanWriter. Many thanks go to Harald Dietrich (contact at hdietrich.net) for providing the test cases and a use scenario. I removed the dependency on XMLSerializer (for people using Crimson ;) and made another ContentHandler to prove it is working. (the code with XMLSerializer also works though). I also removed a failure taking place on the #text node, since those nodes cannot be avoided (thnx jt..) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/proposal HOW-TO-USE.txt
bayard 2002/11/08 14:24:38 Added: proposal HOW-TO-USE.txt Log: Added a quick piece of documentation telling people how to run the proposal generator. Just so they don't have to go hunting into build.xml and realise it's not a template like the other classes etc. Revision ChangesPath 1.1 jakarta-commons-sandbox/proposal/HOW-TO-USE.txt Index: HOW-TO-USE.txt === The Proposal project is used to generate out new proejcts in the commons-sandbox. It is run by invoking: ant -Dpackage=name_of_project where name_of_project is replaced with your project name. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestMethodsRedirectNoHost.java
jsdever 2002/11/08 14:25:08
Modified:httpclient/src/java/org/apache/commons/httpclient
HttpMethodBase.java
httpclient/src/test/org/apache/commons/httpclient
TestMethodsRedirectNoHost.java
Log:
Fix HttpUrlException being thrown incorrectly on redirects.
Reported by Danny Burkes.
Revision ChangesPath
1.77 +8 -7
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.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- HttpMethodBase.java 31 Oct 2002 07:45:34 - 1.76
+++ HttpMethodBase.java 8 Nov 2002 22:25:07 - 1.77
-904,7 +904,7
URL currentUrl = null;
try {
-currentUrl = new URL(conn.getProtocol(),
+currentUrl = new URL(conn.getProtocol().toLowerCase(),
conn.getHost(), conn.getPort(), );
redirectUrl = new URL(location);
} catch (MalformedURLException e) {
-914,6 +914,7
return false;
} else { //location is incomplete, use current values for defaults
try {
+log.debug(Redirect URL is not absolute - parsing as relative);
redirectUrl = new URL(currentUrl, location);
} catch (MalformedURLException ex) {
log.warn(Redirected location ' + location
-959,8 +960,8
throws HttpException {
log.trace(enter HttpMethodBase.checkValidRedirect(HttpConnection, URL));
-String oldProtocol = currentUrl.getProtocol().toLowerCase();
-String newProtocol = redirectUrl.getProtocol().toLowerCase();
+String oldProtocol = currentUrl.getProtocol();
+String newProtocol = redirectUrl.getProtocol();
if (! oldProtocol.equals(newProtocol)) {
throw new HttpException(Redirect from protocol + oldProtocol
+ to + newProtocol + is not supported);
1.2 +17 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestMethodsRedirectNoHost.java
Index: TestMethodsRedirectNoHost.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestMethodsRedirectNoHost.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestMethodsRedirectNoHost.java31 Oct 2002 07:45:35 - 1.1
+++ TestMethodsRedirectNoHost.java8 Nov 2002 22:25:08 - 1.2
-126,6 +126,19
assertEquals(/newfile, method.getPath());
}
+public void testRedirectIgnoreCase() throws Exception {
+addRedirectResponse(HtTP://localhost/newfile;);
+addOkResponse();
+conn.open();
+
+HttpMethod method = new SimpleHttpMethod(/oldfile);
+method.setFollowRedirects(true);
+method.execute(new HttpState(), conn);
+Header locationHeader = method.getResponseHeader(Location);
+assertEquals(200, method.getStatusCode());
+assertEquals(/newfile, method.getPath());
+
+}
public void testPostRedirect() throws Exception {
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [jdbc] JdbcUtil etc
Given all the recent issues about our responsibilities wrt legal issues, I think that using a Sun Trademark (is it a trademark?) for one of our released products could cause problems. If jdbc is preferred, I think that it should be checked with our official PMC (Jakarta) or the board. For beans, the solution was to call it beanutil, so perhaps we should call it jdbcutil. Stephen from:Henri Yandell [EMAIL PROTECTED] date:Fri, 08 Nov 2002 22:05:53 to: [EMAIL PROTECTED], [EMAIL PROTECTED] subject: RE: [jdbc] JdbcUtil etc On Fri, 8 Nov 2002, Steven Caswell wrote: I don't know of anything that already exists, and I've looked around Jakarta a little bit to find one. I'd love to see a jdbc subproject. I've got a few things I could throw in as well. So I'm 1 that such a thing should exist, 1 for calling it jdbc and 1 for separating this kind of stuff from the current sql project (I agree, the sql project is different stuff). Works for me as a sanity check :) I'm not insane! woo. maybe. I'll write a proposal and add a jdbc project with some initial code tonight/this w/e. You okay to be an initial committer on it? Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [jdbc] JdbcUtil etc
DbUtils? On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote: Given all the recent issues about our responsibilities wrt legal issues, I think that using a Sun Trademark (is it a trademark?) for one of our released products could cause problems. If jdbc is preferred, I think that it should be checked with our official PMC (Jakarta) or the board. For beans, the solution was to call it beanutil, so perhaps we should call it jdbcutil. Stephen from:Henri Yandell [EMAIL PROTECTED] date:Fri, 08 Nov 2002 22:05:53 to: [EMAIL PROTECTED], [EMAIL PROTECTED] subject: RE: [jdbc] JdbcUtil etc On Fri, 8 Nov 2002, Steven Caswell wrote: I don't know of anything that already exists, and I've looked around Jakarta a little bit to find one. I'd love to see a jdbc subproject. I've got a few things I could throw in as well. So I'm 1 that such a thing should exist, 1 for calling it jdbc and 1 for separating this kind of stuff from the current sql project (I agree, the sql project is different stuff). Works for me as a sanity check :) I'm not insane! woo. maybe. I'll write a proposal and add a jdbc project with some initial code tonight/this w/e. You okay to be an initial committer on it? Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [jdbc] JdbcUtil etc
On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote: For beans, the solution was to call it beanutil, so perhaps we should call it jdbcutil. Looking at the Sun website, the JDBC acronym is clearly trademarked on its webpage so we need another name. I'll ask the question on General as do we even know if jdbcutil is ok? [Beans isn't trademarked, JavaBeans is]. Looking at it, and thinking in the usual stop-start way, we have a jdbc2pool project, so assuming that is okay, then jdbcutils is okay [to match beanutils]. Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [jdbc] JdbcUtil etc
5)
public static Long readLong(ResultSet rs, int index) throws SQLException {
Long result = new Long(rs.getLong(index));
if (rs.wasNull()) {
return null;
} else {
return result;
}
}
public static void setLong(PreparedStatement pstmt, int index, Long value) throws
SQLException {
if (value == null) {
pstmt.setNull(index, Types.NUMBER);
} else {
pstmt.setLong(index, value.longValue();
}
}
And similar methods for the rest of supported types?
Regards
Tomek Pik
[EMAIL PROTECTED]
Hen
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [jdbc] JdbcUtil etc
-Original Message-
From: Henri Yandell [mailto:bayard;generationjava.com]
Sent: Friday, November 08, 2002 2:42 PM
To: Jakarta Commons Developers List
Subject: RE: [jdbc] JdbcUtil etc
On Fri, 8 Nov 2002 [EMAIL PROTECTED] wrote:
Given all the recent issues about our responsibilities wrt legal
issues, I think that using a Sun Trademark (is it a trademark?) for
one of our released products could cause problems. If jdbc is
preferred, I think that it should be checked with our official PMC
(Jakarta) or the board.
For beans, the solution was to call it beanutil, so perhaps
we should
call it jdbcutil.
Looking at the Sun website, the JDBC acronym is clearly
trademarked on its
webpage so we need another name.
[A friend suggested JDBS... He's had some bad times with JDBC :) ]
I'll ask the question on General as do we even know if jdbcutil is ok?
[Beans isn't trademarked, JavaBeans is].
In its early days, Vincent Massol had trouble with Cactus. It was originally
called J2EEUnit, but he had to change the name because of the J2EE part. So
I'd say that makes jdbcutil unworkable too. ;-{
--
Martin Cooper
Hen
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: installing jakarta code Was: using commons components and logging
-Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Friday, November 08, 2002 5:04 PM To: Steven Caswell Cc: 'Henri Yandell' Subject: RE: installing jakarta code Was: using commons components and logging On Fri, 8 Nov 2002, Steven Caswell wrote: Confused the user how? I guess I don't understand how using a library like lang can cause heartburn for a project like Collections. I've never had a problem adding another jar to the classpath. Seems to me that the user (which, we should keep in mind, are supposedly intelligent developers) should easily understand an additional dependency. As long as it is documented in a clear manner. Maybe that's the nub. Without really sitting down with users to find out why they didn't install XXX library, it's hard to tell. But I can quite happily goto the Jakarta front page, click on a news item or click on Binary Releases, and download the zip without realising. That is a good point. I've had on blinders thinking more along the lines of the initial installation of a project, but your point About getting a later release is well taken. Unless I explicitly look at the docs, I may miss an important dependency. And today Maven doesn't really help this situation. Especially as I expect to have an INSTALL.txt or README.txt [or html] which tells me what I need. We tend to put it on the website, which a lot of people probably don't bother to check. So, maybe Maven could be generating out an INSTALL.txt as part of its build or some such. Or maybe the current download method of using the default Apache directory is wrong, we need a lot of index.html's throughout the build/ directory. Could get real messy. Or we have an xml file in the releases directory called requires.xml which an Apache module reads, shows a custom Apache directory-page to remind people where to go to get the requirements. I like that idea, it's not java, but neither is Jakarta's site. What do you think? [Maven can still generate this xml file out as part of the build] I think this would be a reasonable short-term solution. I'd really Like to see things move toward a neutral (i.e., project-comprehension-tool-agnostic) xml description of dependencies that could be used by Maven or whatever to Figure out what else needs to be gotten and go get it. Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/dbutils/src/java - New directory
bayard 2002/11/08 15:41:47 jakarta-commons-sandbox/dbutils/src/java - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache - New directory
bayard 2002/11/08 15:47:19 jakarta-commons-sandbox/dbutils/src/java/org/apache - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/dbutils/src/test/org/apache/commons - New directory
bayard 2002/11/08 15:47:19 jakarta-commons-sandbox/dbutils/src/test/org/apache/commons - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons - New directory
bayard 2002/11/08 15:47:19 jakarta-commons-sandbox/dbutils/src/java/org/apache/commons - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils - New directory
bayard 2002/11/08 15:47:19 jakarta-commons-sandbox/dbutils/src/java/org/apache/commons/dbutils - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/dbutils/src/test/org/apache - New directory
bayard 2002/11/08 15:47:19 jakarta-commons-sandbox/dbutils/src/test/org/apache - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
