Re: [all] maven2 pom.xml files of commons
Commons does not have pom.xml for its components. Them pom files you find at the repositories (i.e. ibiblio) are converted by a piece of software from our (Maven 1) project.xml files. This conversion is made automatically. We are able to add some comments in our project.xml files to fix some of the conversion problems. So a couple of examples would be nice. Then I can check to see what the problems might be and if/how we can solve them. Maybe the maven project.xml 2 pom.xml converter may consider maven1 properties that have a direct equivalent in maven2 ? For example, if junit is refered as : dependency idjunit/id version3.8.1/version propertiesscopetest/scope/properties /dependency this scope property has no effect on maven1 but is valid and adds documentation to dependency use. It can be converted to the scope element in a maven2 pom. This can be a way to help the converter when a project is aware of beeing used by maven2 users but doesn't use it itself. Just my 2 cents... Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven2 pom.xml files of commons
On 7/12/06, Nicolas De Loof [EMAIL PROTECTED] wrote: Commons does not have pom.xml for its components. Them pom files you find at the repositories (i.e. ibiblio) are converted by a piece of software from our (Maven 1) project.xml files. This conversion is made automatically. We are able to add some comments in our project.xml files to fix some of the conversion problems. So a couple of examples would be nice. Then I can check to see what the problems might be and if/how we can solve them. Maybe the maven project.xml 2 pom.xml converter may consider maven1 properties that have a direct equivalent in maven2 ? For example, if junit is refered as : dependency idjunit/id version3.8.1/version propertiesscopetest/scope/properties /dependency this scope property has no effect on maven1 but is valid and adds documentation to dependency use. It can be converted to the scope element in a maven2 pom. This can be a way to help the converter when a project is aware of beeing used by maven2 users but doesn't use it itself. Afaik, it does. Just need to add it to all the project.xml's. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421532 - in /jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io: input/CountingInputStream.java output/CountingOutputStream.java
Author: bayard Date: Thu Jul 13 00:54:43 2006 New Revision: 421532 URL: http://svn.apache.org/viewvc?rev=421532view=rev Log: now deprecated Modified: jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.java Modified: jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java?rev=421532r1=421531r2=421532view=diff == --- jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java (original) +++ jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/input/CountingInputStream.java Thu Jul 13 00:54:43 2006 @@ -22,6 +22,8 @@ * A decorating input stream that counts the number of bytes that * have passed through so far. * + * @deprecated now found in Commons IO + * * @author Henri Yandell * @author Marcelo Liberato * @version $Id$ Modified: jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.java?rev=421532r1=421531r2=421532view=diff == --- jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.java (original) +++ jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/output/CountingOutputStream.java Thu Jul 13 00:54:43 2006 @@ -22,6 +22,8 @@ * Used in debugging, it counts the number of bytes that pass * through it. * + * @deprecated now found in Commons IO + * * @author a href=mailto:[EMAIL PROTECTED]Henri Yandell/a * @version $Id$ */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SANDBOX-153) Delimiter should be never recognized as whitespace
Delimiter should be never recognized as whitespace
--
Key: SANDBOX-153
URL: http://issues.apache.org/jira/browse/SANDBOX-153
Project: Commons Sandbox
Type: Bug
Components: CSV
Reporter: Markus Rogg
The CSV-Parser ignores whitespaces at the beginning of a token. If the
delimiter is a tabspace and data has no encapsulator the parser loses the empty
tokens. The parser should never recognize a delimiter as a whitespace. A
possible solution for the class CSVParser is to change the method
isWhitespace(int) :
private boolean isWhitespace(int c) {
return Character.isWhitespace((char) c) (c != strategy.getDelimiter());
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly has an issue affecting its community integration. This issue affects 58 projects, and has been outstanding for 10 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cargo : Cargo provides a Java API to manipulate Java Containers - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - htmlunit : A tool for testing web based applications - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-framework-12 : Cactus Framework (J2EE 1.2) - jakarta-cactus-framework-13 : Cactus Framework (J2EE 1.3) - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-12 : Cactus Servlet Sample (J2EE 1.2) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jaxme2 - jaxmeapi - jaxmejs - jaxmexs - maven : Project Management Tools - maven-bootstrap : Project Management Tools - portals-jetspeed-1 : Enterprise Information Portal - strutstestcase : An extension of the standard JUnit TestCase class that provi... Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-13072006.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 10 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH:
[EMAIL PROTECTED]: Project commons-jelly (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly has an issue affecting its community integration. This issue affects 58 projects, and has been outstanding for 10 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cargo : Cargo provides a Java API to manipulate Java Containers - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-antlr : Commons Jelly - commons-jelly-tags-avalon : Commons Jelly - commons-jelly-tags-bean : Commons Jelly - commons-jelly-tags-beanshell : Commons Jelly - commons-jelly-tags-betwixt : Commons Jelly - commons-jelly-tags-bsf : Commons Jelly - commons-jelly-tags-define : Commons Jelly - commons-jelly-tags-define-test : Commons Jelly - commons-jelly-tags-dynabean : Commons Jelly - commons-jelly-tags-email : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-http : Commons Jelly - commons-jelly-tags-interaction : Commons Jelly - commons-jelly-tags-jetty : Commons Jelly - commons-jelly-tags-jface : Commons Jelly - commons-jelly-tags-jms : Commons Jelly - commons-jelly-tags-jmx : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-junit : Commons Jelly - commons-jelly-tags-log : Commons Jelly - commons-jelly-tags-memory : Commons Jelly - commons-jelly-tags-ojb : Commons Jelly - commons-jelly-tags-quartz : Commons Jelly - commons-jelly-tags-regexp : Commons Jelly - commons-jelly-tags-sql : Commons Jelly - commons-jelly-tags-swing : Commons Jelly - commons-jelly-tags-swt : Commons Jelly - commons-jelly-tags-threads : Commons Jelly - commons-jelly-tags-util : Commons Jelly - commons-jelly-tags-validate : Commons Jelly - commons-jelly-tags-velocity : Commons Jelly - commons-jelly-tags-xml : Commons Jelly - commons-jelly-tags-xml-test : Commons Jelly - commons-jelly-tags-xmlunit : Commons Jelly - geronimo : Apache Geronimo, the J2EE server project of the Apache Softw... - htmlunit : A tool for testing web based applications - jakarta-cactus-documentation : Cactus Documentation - jakarta-cactus-framework-12 : Cactus Framework (J2EE 1.2) - jakarta-cactus-framework-13 : Cactus Framework (J2EE 1.3) - jakarta-cactus-release-12 : Unit test framework for server-side java code - jakarta-cactus-release-13 : Unit test framework for server-side java code - jakarta-cactus-sample-jetty-13 : Cactus Jetty Sample (J2EE 1.3) - jakarta-cactus-sample-servlet-12 : Cactus Servlet Sample (J2EE 1.2) - jakarta-cactus-sample-servlet-13 : Cactus Servlet Sample (J2EE 1.3) - jaxme2 - jaxmeapi - jaxmejs - jaxmexs - maven : Project Management Tools - maven-bootstrap : Project Management Tools - portals-jetspeed-1 : Enterprise Information Portal - strutstestcase : An extension of the standard JUnit TestCase class that provi... Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-13072006.jar] identifier set to project name -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property maven.jar.servletapi. -DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for property maven.jar.jstl. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly/gump_work/build_commons-jelly_commons-jelly.html Work Name: build_commons-jelly_commons-jelly (Type: Build) Work ended in a state of : Failed Elapsed: 10 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly] CLASSPATH:
[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 10 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-WARNING- Overriding Maven properties:
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
-WARNING- No directory
[/usr/local/gump/public/workspace/commons-jelly/target/test-reports]
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13072006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] public CommandLine parseCommandLineOptions(String[] args)
throws ParseException {
[javac]
^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:67:
cannot find symbol
[javac] symbol : class CommandLine
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] CommandLine cmdLine = null;
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:70:
cannot find symbol
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] } catch (ParseException e) {
[javac] ^
[javac]
[EMAIL PROTECTED]: Project commons-jelly-test (in module commons-jelly) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 10 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-test : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for
property maven.jar.servletapi.
-DEBUG- Dependency on jakarta-taglibs-standard exists, no need to add for
property maven.jar.jstl.
-DEBUG- Dependency on xml-xerces exists, no need to add for property
maven.jar.xerces.
-WARNING- Overriding Maven properties:
[/usr/local/gump/public/workspace/commons-jelly/build.properties]
-DEBUG- (Gump generated) Maven Properties in:
/usr/local/gump/public/workspace/commons-jelly/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/usr/local/gump/public/workspace/commons-jelly/project.xml
-DEBUG- Maven project properties in:
/usr/local/gump/public/workspace/commons-jelly/project.properties
-INFO- Project Reports in:
/usr/local/gump/public/workspace/commons-jelly/target/test-reports
-WARNING- No directory
[/usr/local/gump/public/workspace/commons-jelly/target/test-reports]
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-test/gump_work/build_commons-jelly_commons-jelly-test.html
Work Name: build_commons-jelly_commons-jelly-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/commons-jelly]
CLASSPATH:
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13072006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13072006.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/packages/forehead/forehead-1.0-beta-5.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-taglibs/dist/standard/lib/jstl.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13072006.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar
-
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] public CommandLine parseCommandLineOptions(String[] args)
throws ParseException {
[javac]
^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/impl/DynamicBeanTag.java:210:
warning: [deprecation] org.apache.commons.collections.BeanMap in
org.apache.commons.collections has been deprecated
[javac] BeanMap beanMap = new BeanMap(bean);
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:67:
cannot find symbol
[javac] symbol : class CommandLine
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] CommandLine cmdLine = null;
[javac] ^
[javac]
/x1/gump/public/workspace/commons-jelly/src/java/org/apache/commons/jelly/util/CommandLineParser.java:70:
cannot find symbol
[javac] symbol : class ParseException
[javac] location: class org.apache.commons.jelly.util.CommandLineParser
[javac] } catch (ParseException e) {
[javac] ^
[javac]
[jira] Created: (DBCP-194) BasicDataSource.setLogWriter should not do createDataSource
BasicDataSource.setLogWriter should not do createDataSource
---
Key: DBCP-194
URL: http://issues.apache.org/jira/browse/DBCP-194
Project: Commons Dbcp
Type: Bug
Versions: 1.2 Final
Reporter: Kees de Kooter
The code for setLogWriter is:
public void setLogWriter(PrintWriter logWriter) throws SQLException {
createDataSource().setLogWriter(logWriter);
this.logWriter = logWriter;
}
This means that before a custom log writer is set a datasource is created. Any
logging happening while creating the datasource is directed to stdout / stderr.
I think the purpose of setting a log writer is to prevent this, at least that
is what I am trying to achieve.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] splitting ResourceManager interface
Hello, the more I work with the FileResourceManager the more I'm convinced that the ResourceManager interface should be splitted into two interfaces: one for handling the locking and transactional stuff (proposal: TransactionManager) and one for actually handling the resources (as is: ResourceManager). One the one hand the only implementation, the FileResourceManager, simply does too much, i.e. too many concerns are handled in it. On the other hand I extend my local version of the FileResourceManager with more and more methods to emulate a file system access (methods from java.io.File actually). In theory I would need to add these methods to ResourceManager interface to be able to work with interfaces, but it would get bigger and bigger. Instead I wonder if a generic ResourceManager interface (in my new sense as described above) is appropriate at all. Probably it would be more appropriate to rename it to FileResourceManager or introduce FileResourceManager interface extending ResourceManager. The splitting of the current ResourceManager interface would allow to reuse the transaction/locking capability with different ResourceManagers (in my new sense). The splitting should be quite easy IMHO. The concerns are quite good separated in the FileResourceManager. WDYT? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (POOL-83) Support Java 1.5 Generics
Support Java 1.5 Generics - Key: POOL-83 URL: http://issues.apache.org/jira/browse/POOL-83 Project: Commons Pool Type: Improvement Versions: Nightly Builds Reporter: Sam Berlin It would be nice if there was a build that supported Java 1.5's Generics. This probably isn't possible to include in the regular distribution, since Commons-Pool probably wants to maintain compatability with older versions of Java, but generics are highly desirable, especially for a project such as pool. I have spent the day or so adding support to it in our CVS repository (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). I'll attach the patch to generify the code, if you decide that it is possible to include in the main distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-83) Support Java 1.5 Generics
[ http://issues.apache.org/jira/browse/POOL-83?page=all ] Sam Berlin updated POOL-83: --- Attachment: generics.txt Patch for generics in commons-pool. You will have to ignore the first level of the path when applying the patch, as it's generated from our CVS repository. If this is a problem, let me know and I can create a patch with a different directory structure. (Sorry also for marking the priority as major, it really should be minor.) Support Java 1.5 Generics - Key: POOL-83 URL: http://issues.apache.org/jira/browse/POOL-83 Project: Commons Pool Type: Improvement Versions: Nightly Builds Reporter: Sam Berlin Attachments: generics.txt It would be nice if there was a build that supported Java 1.5's Generics. This probably isn't possible to include in the regular distribution, since Commons-Pool probably wants to maintain compatability with older versions of Java, but generics are highly desirable, especially for a project such as pool. I have spent the day or so adding support to it in our CVS repository (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). I'll attach the patch to generify the code, if you decide that it is possible to include in the main distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-83) Support Java 1.5 Generics
[ http://issues.apache.org/jira/browse/POOL-83?page=all ] Sandy McArthur updated POOL-83: --- Priority: Minor (was: Major) Support Java 1.5 Generics - Key: POOL-83 URL: http://issues.apache.org/jira/browse/POOL-83 Project: Commons Pool Type: Improvement Versions: Nightly Builds Reporter: Sam Berlin Priority: Minor Attachments: generics.txt It would be nice if there was a build that supported Java 1.5's Generics. This probably isn't possible to include in the regular distribution, since Commons-Pool probably wants to maintain compatability with older versions of Java, but generics are highly desirable, especially for a project such as pool. I have spent the day or so adding support to it in our CVS repository (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). I'll attach the patch to generify the code, if you decide that it is possible to include in the main distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35046] - [transaction] GenericLockManager constructor ignores LoggerFacade argument
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35046. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35046 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-07-13 17:35 --- This is intended behavior. It is used to have a specific logger for the lock manager. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421670 - in /jakarta/commons/proper/transaction/trunk/src: java/org/apache/commons/transaction/memory/TransactionalMapWrapper.java test/org/apache/commons/transaction/memory/MapWrapperTes
Author: ozeigermann
Date: Thu Jul 13 10:42:52 2006
New Revision: 421670
URL: http://svn.apache.org/viewvc?rev=421670view=rev
Log:
Fix for bug 38545. Transactional map wrapper did not allow for
null values. Bug reported and patch
supplied by Greg Steckman at
http://issues.apache.org/bugzilla/show_bug.cgi?id=38545.
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/TransactionalMapWrapper.java
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/MapWrapperTest.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/TransactionalMapWrapper.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/TransactionalMapWrapper.java?rev=421670r1=421669r2=421670view=diff
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/TransactionalMapWrapper.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/memory/TransactionalMapWrapper.java
Thu Jul 13 10:42:52 2006
@@ -317,7 +317,7 @@
* @see Map#containsKey(java.lang.Object)
*/
public boolean containsKey(Object key) {
-return (get(key) != null);
+ return keySet().contains(key);
}
/**
@@ -529,6 +529,7 @@
Set keySet = new HashSet();
if (!cleared) {
keySet.addAll(wrapped.keySet());
+keySet.removeAll(deletes);
}
keySet.addAll(adds.keySet());
return keySet;
@@ -541,14 +542,12 @@
return null;
}
-Object changed = changes.get(key);
-if (changed != null) {
-return changed;
+if(changes.containsKey(key)){
+return changes.get(key);
}
-Object added = adds.get(key);
-if (added != null) {
-return added;
+if(adds.containsKey(key)){
+return adds.get(key);
}
if (cleared) {
@@ -563,7 +562,7 @@
try {
readOnly = false;
deletes.remove(key);
-if (wrapped.get(key) != null) {
+if (wrapped.containsKey(key)) {
changes.put(key, value);
} else {
adds.put(key, value);
Modified:
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/MapWrapperTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/MapWrapperTest.java?rev=421670r1=421669r2=421670view=diff
==
---
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/MapWrapperTest.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/memory/MapWrapperTest.java
Thu Jul 13 10:42:52 2006
@@ -121,6 +121,37 @@
report(value2, (String) txMap1.get(key1));
}
+public void testContainsKeyWithNullValue() throws Throwable {
+
+logger.info(Checking containsKey returns true when the value is
null);
+
+final Map map1 = new HashMap();
+
+final TransactionalMapWrapper txMap1 = getNewWrapper(map1);
+
+assertTrue(txMap1.isEmpty());
+
+// make sure changes are propagated to wrapped map outside tx
+txMap1.put(key1, null);
+assertTrue(txMap1.containsKey(key1));
+
+// make sure changes are progated to wrapped map after commit
+txMap1.startTransaction();
+txMap1.put(key2, null);
+assertTrue(txMap1.containsKey(key2));
+txMap1.remove(key1);
+assertTrue(map1.containsKey(key1));
+txMap1.commitTransaction();
+assertTrue(txMap1.containsKey(key2));
+assertFalse(txMap1.containsKey(key1));
+
+txMap1.startTransaction();
+assertTrue(txMap1.containsKey(key2));
+txMap1.remove(key2);
+assertFalse(txMap1.containsKey(key2));
+txMap1.commitTransaction();
+}
+
public void testComplex() throws Throwable {
logger.info(Checking advanced and complex transaction features);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (POOL-83) Support Java 1.5 Generics
[ http://issues.apache.org/jira/browse/POOL-83?page=all ] Sandy McArthur resolved POOL-83: Resolution: Later This is on the Pool road map for the 3.0 release which is a ways off. I want it too but I think it's a bit early to force Pool users to Java 5 as a minimum requirement. That and Pool 2.0 is still in the oven. http://wiki.apache.org/jakarta-commons/PoolRoadMap Support Java 1.5 Generics - Key: POOL-83 URL: http://issues.apache.org/jira/browse/POOL-83 Project: Commons Pool Type: Improvement Versions: Nightly Builds Reporter: Sam Berlin Priority: Minor Attachments: generics.txt It would be nice if there was a build that supported Java 1.5's Generics. This probably isn't possible to include in the regular distribution, since Commons-Pool probably wants to maintain compatability with older versions of Java, but generics are highly desirable, especially for a project such as pool. I have spent the day or so adding support to it in our CVS repository (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). I'll attach the patch to generify the code, if you decide that it is possible to include in the main distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38545] - [transaction] TransactionalMapWrapper doesn't work correctly with null values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38545. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38545 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-07-13 17:44 --- Patch applied. Thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421671 - /jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
Author: ozeigermann
Date: Thu Jul 13 10:48:24 2006
New Revision: 421671
URL: http://svn.apache.org/viewvc?rev=421671view=rev
Log:
All lock methods now pass time out to underlying implementation.
Bug reported by Mathieu Baudier!
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
Modified:
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/GenericLockManager.java?rev=421671r1=421670r2=421671view=diff
==
---
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
(original)
+++
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/locking/GenericLockManager.java
Thu Jul 13 10:48:24 2006
@@ -181,7 +181,7 @@
public void lock(Object ownerId, Object resourceId, int targetLockLevel,
boolean reentrant,
long timeoutMSecs) throws LockException {
lock(ownerId, resourceId, targetLockLevel, reentrant ?
GenericLock.COMPATIBILITY_REENTRANT
-: GenericLock.COMPATIBILITY_NONE, false, globalTimeoutMSecs);
+: GenericLock.COMPATIBILITY_NONE, false, timeoutMSecs);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421672 - /jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt
Author: ozeigermann Date: Thu Jul 13 10:48:40 2006 New Revision: 421672 URL: http://svn.apache.org/viewvc?rev=421672view=rev Log: (empty) Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Modified: jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt?rev=421672r1=421671r2=421672view=diff == --- jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt (original) +++ jakarta/commons/proper/transaction/trunk/RELEASE-NOTES.txt Thu Jul 13 10:48:40 2006 @@ -39,6 +39,8 @@ - Fixed issue with deleteResource(..) and createResource(..) of FileResourceManager seen as read-only operations. - Fixed issue with AbstractXAResource. Resources did not get released when prepare(..) returns XA_RDONLY as no commit(..) is triggered by the TransactionManager explicitely. +- TransactionalMapWrapper now properly supports null values. Bug report and fix supplied by Greg Steckman at http://issues.apache.org/bugzilla/show_bug.cgi?id=38545 +- Minor bug reported at http://issues.apache.org/bugzilla/show_bug.cgi?id=39559 has been fixed. KNOWN ISSUES - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39559] - [transaction] Timeout is not passed in org.apache.commons.transaction.locking.GenericLockManager#lock(Object ownerId, Object resourceId, int targetLockLevel, boolean reentr
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39559. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39559 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-07-13 17:47 --- Bug fixed. Thanks for reporting! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (POOL-83) Support Java 1.5 Generics
[ http://issues.apache.org/jira/browse/POOL-83?page=comments#action_12420903 ] Sam Berlin commented on POOL-83: Ahh -- I hadn't noticed the road map. I'll look forward to Pool 3.0 when it arrives. Hopefully you can use this patch as some groundwork for generifying and save some time. If you find folks are interested in a generified version of the current Pool builds, feel free to point them to our repository. Support Java 1.5 Generics - Key: POOL-83 URL: http://issues.apache.org/jira/browse/POOL-83 Project: Commons Pool Type: Improvement Versions: Nightly Builds Reporter: Sam Berlin Priority: Minor Attachments: generics.txt It would be nice if there was a build that supported Java 1.5's Generics. This probably isn't possible to include in the regular distribution, since Commons-Pool probably wants to maintain compatability with older versions of Java, but generics are highly desirable, especially for a project such as pool. I have spent the day or so adding support to it in our CVS repository (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). I'll attach the patch to generify the code, if you decide that it is possible to include in the main distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] splitting ResourceManager interface
Hi, Jörg! My first implementation of FileResourceManager really implemented two interfaces that were close to what you propose. The idea was to have impementations other than to the file system. The ResourceManager interface rather is some sort of relict from older times. No need to worry much about it except for backward compatibility. Why change things in the first place? Just because the FileResourceManager is huge? That is not a bad thing all by itself. Some classed simply get big. Compare it to the String class. It is twice as big. Anyway, if you want to introduce something new, got ahead, but be aware of backward compatibility issues. Oliver P.S.: I think it might be the time for a 1.2 release. What do you think? 2006/7/13, Joerg Heinicke [EMAIL PROTECTED]: Hello, the more I work with the FileResourceManager the more I'm convinced that the ResourceManager interface should be splitted into two interfaces: one for handling the locking and transactional stuff (proposal: TransactionManager) and one for actually handling the resources (as is: ResourceManager). One the one hand the only implementation, the FileResourceManager, simply does too much, i.e. too many concerns are handled in it. On the other hand I extend my local version of the FileResourceManager with more and more methods to emulate a file system access (methods from java.io.File actually). In theory I would need to add these methods to ResourceManager interface to be able to work with interfaces, but it would get bigger and bigger. Instead I wonder if a generic ResourceManager interface (in my new sense as described above) is appropriate at all. Probably it would be more appropriate to rename it to FileResourceManager or introduce FileResourceManager interface extending ResourceManager. The splitting of the current ResourceManager interface would allow to reuse the transaction/locking capability with different ResourceManagers (in my new sense). The splitting should be quite easy IMHO. The concerns are quite good separated in the FileResourceManager. WDYT? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35046] - [transaction] GenericLockManager constructor ignores LoggerFacade argument
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35046. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35046 --- Additional Comments From [EMAIL PROTECTED] 2006-07-13 19:02 --- Jakarta Commons has moved from Bugzilla to JIRA. This issue is now at http://issues.apache.org/jira/browse/TRANSACTION-5 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38545] - [transaction] TransactionalMapWrapper doesn't work correctly with null values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38545. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38545 --- Additional Comments From [EMAIL PROTECTED] 2006-07-13 19:03 --- Jakarta Commons has moved from Bugzilla to JIRA. This issue is now at http://issues.apache.org/jira/browse/TRANSACTION-8 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39559] - [transaction] Timeout is not passed in org.apache.commons.transaction.locking.GenericLockManager#lock(Object ownerId, Object resourceId, int targetLockLevel, boolean reentr
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39559. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39559 --- Additional Comments From [EMAIL PROTECTED] 2006-07-13 19:04 --- Jakarta Commons has moved from Bugzilla to JIRA. This issue is now at http://issues.apache.org/jira/browse/TRANSACTION-6 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (POOL-82) 2 tests failing on JDK 1.4/1.6 on Linux
[ http://issues.apache.org/jira/browse/POOL-82?page=comments#action_12420913 ] Sandy McArthur commented on POOL-82: Both TestObjectPoolFactory and TestKeyedObjectPoolFactory are abstract and are used indirectly by unit test that subclass them such as TestGenericObjectPoolFactory or TestStackObjectPoolFactory. If you use the TestAll classes as your TestCase when launching JUnit it will do the right thing. 2 tests failing on JDK 1.4/1.6 on Linux --- Key: POOL-82 URL: http://issues.apache.org/jira/browse/POOL-82 Project: Commons Pool Type: Bug Environment: JDK 1.6 and 1.4.2 on Debian Linux Reporter: Henri Yandell Might already be known, but figured I'd report it just in case. Testsuite: org.apache.commons.pool.TestObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.724 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() and Testsuite: org.apache.commons.pool.TestKeyedObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.727 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (POOL-82) 2 tests failing on JDK 1.4/1.6 on Linux
[ http://issues.apache.org/jira/browse/POOL-82?page=all ] Sandy McArthur closed POOL-82: -- Resolution: Invalid Assign To: Sandy McArthur Closing, this isn't a real unit test failure. 2 tests failing on JDK 1.4/1.6 on Linux --- Key: POOL-82 URL: http://issues.apache.org/jira/browse/POOL-82 Project: Commons Pool Type: Bug Environment: JDK 1.6 and 1.4.2 on Debian Linux Reporter: Henri Yandell Assignee: Sandy McArthur Might already be known, but figured I'd report it just in case. Testsuite: org.apache.commons.pool.TestObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.724 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() and Testsuite: org.apache.commons.pool.TestKeyedObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.727 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to I set JIRA issues to resolved?
Issues have moved from bugzilla and now I am rather helpless how to set them to fixed. Any ideas? Do I need additional rights? Thanks in advance and cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to I set JIRA issues to resolved?
On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: Issues have moved from bugzilla and now I am rather helpless how to set them to fixed. Any ideas? Do I need additional rights? There should be an Available Workflow Actions section on the left side that contains things like Resolve issue, Close issue. If you don't see that, then yes, you need additional rights. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to I set JIRA issues to resolved?
2006/7/13, Thomas Dudziak [EMAIL PROTECTED]: On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: Issues have moved from bugzilla and now I am rather helpless how to set them to fixed. Any ideas? Do I need additional rights? There should be an Available Workflow Actions section on the left side that contains things like Resolve issue, Close issue. If you don't see that, then yes, you need additional rights. How do I get those additional rights? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to I set JIRA issues to resolved?
On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: How do I get those additional rights? Usually the project owner/admin gives them. Though, for the commons projects there appears to be a specific user Jakarta Commons Developers for administering the projects. You should probably ask Henri about that. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to I set JIRA issues to resolved?
On 7/13/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: How do I get those additional rights? Usually the project owner/admin gives them. Though, for the commons projects there appears to be a specific user Jakarta Commons Developers for administering the projects. You should probably ask Henri about that. Nah, that user is a side-effect of a user pulled over from Bugzilla. We've kept it at the moment for project leads. Some of them anyway. For additional rights you just need to ask. The rules I abide by are that if you're a jakarta committer, I add you to the jakarta-developer group and if you're a jakarta PMC member I add you to the jakarta-admin group. There are three users for you in Jira (ozeigermann, [EMAIL PROTECTED] and [EMAIL PROTECTED]). Which one is your login? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to I set JIRA issues to resolved?
2006/7/13, Henri Yandell [EMAIL PROTECTED]: On 7/13/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: How do I get those additional rights? Usually the project owner/admin gives them. Though, for the commons projects there appears to be a specific user Jakarta Commons Developers for administering the projects. You should probably ask Henri about that. Nah, that user is a side-effect of a user pulled over from Bugzilla. We've kept it at the moment for project leads. Some of them anyway. For additional rights you just need to ask. The rules I abide by are that if you're a jakarta committer, I add you to the jakarta-developer group and if you're a jakarta PMC member I add you to the jakarta-admin group. There are three users for you in Jira (ozeigermann, [EMAIL PROTECTED] and [EMAIL PROTECTED]). Which one is your login? Great. ozeigermann is my new user. I am both jakarta committer and PMC member. Thanks in advance Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (POOL-82) 2 tests failing on JDK 1.4/1.6 on Linux
[ http://issues.apache.org/jira/browse/POOL-82?page=all ] Henri Yandell reopened POOL-82: --- Re-opening (seemed better than starting a thread on commons-dev that wouldn't be hooked up to this). They're unit tests that fail and stop the compile from succeeding. I don't think the issues have to be fixed, but they should stop being unit tests if they're not guarranteed to pass. 2 tests failing on JDK 1.4/1.6 on Linux --- Key: POOL-82 URL: http://issues.apache.org/jira/browse/POOL-82 Project: Commons Pool Type: Bug Environment: JDK 1.6 and 1.4.2 on Debian Linux Reporter: Henri Yandell Assignee: Sandy McArthur Might already be known, but figured I'd report it just in case. Testsuite: org.apache.commons.pool.TestObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.724 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() and Testsuite: org.apache.commons.pool.TestKeyedObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.727 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (POOL-83) Support Java 1.5 Generics
[ http://issues.apache.org/jira/browse/POOL-83?page=all ] Henri Yandell reopened POOL-83: --- This grasshopper advises avoidance of the Resolved-Later feature. Instead assign the fixVersion to the issue to the release it's intended for. If it's a general later, then assign it to the release after this one and keep punting it along as time goes by. Support Java 1.5 Generics - Key: POOL-83 URL: http://issues.apache.org/jira/browse/POOL-83 Project: Commons Pool Type: Improvement Versions: Nightly Builds Reporter: Sam Berlin Priority: Minor Attachments: generics.txt It would be nice if there was a build that supported Java 1.5's Generics. This probably isn't possible to include in the regular distribution, since Commons-Pool probably wants to maintain compatability with older versions of Java, but generics are highly desirable, especially for a project such as pool. I have spent the day or so adding support to it in our CVS repository (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). I'll attach the patch to generify the code, if you decide that it is possible to include in the main distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pool] jira managing
I'll sit down tonight and adjust the [pool] jira to all have fix versions (as I've been doing with some of the other components). I think it'll make it clearer what's going on, but feel free to yell at me if I'm being bad. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-83) Support Java 1.5 Generics
[ http://issues.apache.org/jira/browse/POOL-83?page=all ] Henri Yandell updated POOL-83: -- Fix Version: 3.0 Support Java 1.5 Generics - Key: POOL-83 URL: http://issues.apache.org/jira/browse/POOL-83 Project: Commons Pool Type: Improvement Versions: Nightly Builds Reporter: Sam Berlin Priority: Minor Fix For: 3.0 Attachments: generics.txt It would be nice if there was a build that supported Java 1.5's Generics. This probably isn't possible to include in the regular distribution, since Commons-Pool probably wants to maintain compatability with older versions of Java, but generics are highly desirable, especially for a project such as pool. I have spent the day or so adding support to it in our CVS repository (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). I'll attach the patch to generify the code, if you decide that it is possible to include in the main distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to I set JIRA issues to resolved?
Done. On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: 2006/7/13, Henri Yandell [EMAIL PROTECTED]: On 7/13/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: How do I get those additional rights? Usually the project owner/admin gives them. Though, for the commons projects there appears to be a specific user Jakarta Commons Developers for administering the projects. You should probably ask Henri about that. Nah, that user is a side-effect of a user pulled over from Bugzilla. We've kept it at the moment for project leads. Some of them anyway. For additional rights you just need to ask. The rules I abide by are that if you're a jakarta committer, I add you to the jakarta-developer group and if you're a jakarta PMC member I add you to the jakarta-admin group. There are three users for you in Jira (ozeigermann, [EMAIL PROTECTED] and [EMAIL PROTECTED]). Which one is your login? Great. ozeigermann is my new user. I am both jakarta committer and PMC member. Thanks in advance Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
[ http://issues.apache.org/jira/browse/POOL-75?page=all ] Henri Yandell updated POOL-75: -- Bugzilla Id: (was: 39590) Fix Version: 2.0 [pool] GenericObjectPool not FIFO with respect to borrowing threads --- Key: POOL-75 URL: http://issues.apache.org/jira/browse/POOL-75 Project: Commons Pool Type: Improvement Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Gordon Mohr Assignee: Sandy McArthur Priority: Minor Fix For: 2.0 GenericObjectPool has recently been made FIFO with respect to the managed pool objects -- however, it is still not FIFO with respect to threads requesting those objects. Specifically, because standard non-fair Java synchronization monitors are used, later threads may barge ahead of earlier threads that are already waiting for a pool object to become available. At its extreme, some threads can cycle objects through the pool many times while others wait interminable. Not every application needs FIFO fairness with respect to threads, and such fairness implies an overhead, so it need not be the default behavior, but it would be a valuable option where many threads are sharing a smaller number of pool objects. I can submit a FairGenericObjectPool which achieves thread-fairness; it only requires small changes to GenericObjectPool which allow some subclass overriding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to I set JIRA issues to resolved?
Thanks! 2006/7/13, Henri Yandell [EMAIL PROTECTED]: Done. On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: 2006/7/13, Henri Yandell [EMAIL PROTECTED]: On 7/13/06, Thomas Dudziak [EMAIL PROTECTED] wrote: On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: How do I get those additional rights? Usually the project owner/admin gives them. Though, for the commons projects there appears to be a specific user Jakarta Commons Developers for administering the projects. You should probably ask Henri about that. Nah, that user is a side-effect of a user pulled over from Bugzilla. We've kept it at the moment for project leads. Some of them anyway. For additional rights you just need to ask. The rules I abide by are that if you're a jakarta committer, I add you to the jakarta-developer group and if you're a jakarta PMC member I add you to the jakarta-admin group. There are three users for you in Jira (ozeigermann, [EMAIL PROTECTED] and [EMAIL PROTECTED]). Which one is your login? Great. ozeigermann is my new user. I am both jakarta committer and PMC member. Thanks in advance Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TRANSACTION-5) [transaction] GenericLockManager constructor ignores LoggerFacade argument
[ http://issues.apache.org/jira/browse/TRANSACTION-5?page=all ]
Oliver Zeigermann resolved TRANSACTION-5:
-
Resolution: Invalid
This is intended behavior. It is used to have a specific logger for the lock
manager.
[transaction] GenericLockManager constructor ignores LoggerFacade argument
--
Key: TRANSACTION-5
URL: http://issues.apache.org/jira/browse/TRANSACTION-5
Project: Commons Transaction
Type: Bug
Versions: 1.1.0
Environment: Operating System: All
Platform: All
Reporter: Ky Vong
In the following constructor for GenericLockManager, the LoggerFacade
argument is ignored and a new LoggerFacade is always created. Thus, the
LoggerFacade that I'm passing in is never used. This affects the
subclasses of GenericLockManager as well since they all call this
constructor. Someone probably just did this temporarily for some debugging
and
forgot to set this.logger back to the LoggerFacade argument.
Can this be fixed for 1.1?
Thanks,
Ky Vong
public GenericLockManager(int maxLockLevel, LoggerFacade logger, long
timeoutMSecs,
long checkThreshholdMSecs) throws IllegalArgumentException {
if (maxLockLevel 1)
throw new IllegalArgumentException(The maximum lock level must be
at least 1 (
+ maxLockLevel + was specified));
this.maxLockLevel = maxLockLevel;
this.logger = logger.createLogger(Locking);
this.globalTimeoutMSecs = timeoutMSecs;
this.checkThreshhold = checkThreshholdMSecs;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TRANSACTION-8) [transaction] TransactionalMapWrapper doesn't work correctly with null values
[ http://issues.apache.org/jira/browse/TRANSACTION-8?page=all ] Oliver Zeigermann resolved TRANSACTION-8: - Resolution: Fixed Patch applied. Thanks! [transaction] TransactionalMapWrapper doesn't work correctly with null values - Key: TRANSACTION-8 URL: http://issues.apache.org/jira/browse/TRANSACTION-8 Project: Commons Transaction Type: Bug Environment: Operating System: All Platform: All Reporter: Greg Steckman Priority: Critical Attachments: TransactionalMapWrapper.patch TransactionalMapWrapper has a number of instances of incorrect behavior if a null value is placed into the Map. This is a result of using Map.get(key)!=null (or similar) instead of Map.containsKey(key) to check if the underlying Map has a key/value pair set or not. TransactionalMapWrapper.containsKey(key) also returned incorrect values if the key mapped to a null value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TRANSACTION-6) [transaction] Timeout is not passed in org.apache.commons.transaction.locking.GenericLockManager#lock(Object ownerId, Object resourceId, int targetLockLevel, boolean r
[ http://issues.apache.org/jira/browse/TRANSACTION-6?page=all ]
Oliver Zeigermann resolved TRANSACTION-6:
-
Resolution: Fixed
Bug fixed. Thanks for reporting!
[transaction] Timeout is not passed in
org.apache.commons.transaction.locking.GenericLockManager#lock(Object
ownerId, Object resourceId, int targetLockLevel, boolean reentrant, long
timeoutMSecs)
---
Key: TRANSACTION-6
URL: http://issues.apache.org/jira/browse/TRANSACTION-6
Project: Commons Transaction
Type: Bug
Versions: 1.1 Final
Environment: Operating System: All
Platform: All
Reporter: Mathieu Baudier
The timeOutMSecs argument is not passed in the lock(Object ownerId, Object
resourceId, int targetLockLevel, boolean reentrant, long timeoutMSecs) method
of
GenericLocakManager, as can be seen below:
public void lock(Object ownerId, Object resourceId, int targetLockLevel,
boolean
reentrant,
long timeoutMSecs) throws LockException {
lock(ownerId, resourceId, targetLockLevel, reentrant ?
GenericLock.COMPATIBILITY_REENTRANT
: GenericLock.COMPATIBILITY_NONE, false, globalTimeoutMSecs);
}
globalTimeoutMSecs will therefore be used instead. It is set in the
constructor
init(int maxLockLevel, LoggerFacade logger, long timeoutMSecs,long
checkThreshholdMSecs).
In the case we faced, we were using the init(int maxLockLevel, LoggerFacade
logger) constructor, so the timeout value is always DEFAULT_TIMEOUT (that is
3 ms) and we have no way to configure it externally without changing our
own
code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Commons-Math] FFT Support
On 7/4/06, Phil Steitz [EMAIL PROTECTED] wrote: Hi Remy, The test coverage is still not where we would like to have it and we may want to refine/revise the API. Please have a look and if you have suggestions for improvement or are willing to work on adding more test cases / validation with other packages, thanks in advance. Well now that you mention it the current FastFourierTransformer class is not public for me to use. The transform method is public, but it is also non-static and thus requires an instantiation of the class. However the class is non-instantiable, because the constructor for the class only has package level access. I want to start work on a multi dimensional extension to this class, but it would be somewhat easier if the constructor was made public. Along the same lines, an extension to the API could use a utility class that contains only static versions of the corresponding methods in the FastFourierTransformer class. The original class could be remade with only static methods, but I believe it would be far quicker to make a FourierUtils ( :-) ) class or something. I don't have any experience working with the junit api, but I believe this error could be resolved by altering the programing pattern to have the test classes in an alternate package, which would then be able to detect this simple error at compile time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] Release plan?
Is the aim to have a 1.2 release of transaction at some point? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
[ http://issues.apache.org/jira/browse/TRANSACTION-9?page=comments#action_12420931 ] Oliver Zeigermann commented on TRANSACTION-9: - Peter, is this still a valid request? [transaction] Add full file management capabilities to the FileResourceManager -- Key: TRANSACTION-9 URL: http://issues.apache.org/jira/browse/TRANSACTION-9 Project: Commons Transaction Type: Improvement Environment: Operating System: All Platform: All Reporter: Peter Fassev Priority: Minor Hi, As stated in the doc the FileResourceManager is: A resource manager for streamable objects stored in a file system I agree, that this is a resource manager, but it could be easily extended, to support a full file management system. It will be very helpful to have additional methods like renameResource(), getResourceSize(), getResourceTime(), setResourceTime() etc. This are common file operations, which should be managed by the FileResourceManager. Further it will be very helpful to have (real) support for resource collections (folders). It will be necessary to distinguish between single resources (files) and collections (folders). Together, this features will enable a transactional access to any file based resources - for instance a document repository. Are there plans for such extensions and if not, will they actually fit in the goals of the transaction library? If not, please open the underlying structure, like the inner class TransactionContext, in order to add extensions the file management. For instance, it will be good to have a separate factory method, which creates the context. If you are interested in this proposal, I am ready to contribute to this project. I consider myself as an experienced java developer and I will be glad to help you. Best regards Peter Fassev -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
Excatly! That's just what I was proposing in my last email! Would you want to assist? Hihi Oliver 2006/7/13, Henri Yandell [EMAIL PROTECTED]: Is the aim to have a 1.2 release of transaction at some point? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
The current transaction site is using the old way of building sites. Do you mind if I change it to the new way? -- Dennis Lundberg Oliver Zeigermann wrote: Excatly! That's just what I was proposing in my last email! Would you want to assist? Hihi Oliver 2006/7/13, Henri Yandell [EMAIL PROTECTED]: Is the aim to have a 1.2 release of transaction at some point? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-85) [math] SimpleRegression getSumSquaredErrors
Phil Steitz wrote: I looked at this some more last night and now agree that if you are just computing SSE, scoring the data and running that one sum in a second pass should in general be more accurate. The problem is, as Luc pointed out, the need to store all of the data and I don't see any way around that. That's what I meant by more complex. If there are better stateless formulas, then we should look at them. I don't think there is a stateless formula not subject to numerical problems in certain cases. I am still -0 on adding a separate stateful impl, but could be convinced if others feel differently and someone is willing to volunteer to research, code, doc and write tests for it. I don't think it's worth the effort. The current behaviour should be prominently documented, of course, and if someone can come up with a way to warn unsuspecting users that the result may be somewhat inaccurate in case the bit cancellation is detected, that would be great (I'd like to avoid introducing a logging mechanism). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
No, go ahead! Thanks Oliver 2006/7/13, Dennis Lundberg [EMAIL PROTECTED]: The current transaction site is using the old way of building sites. Do you mind if I change it to the new way? -- Dennis Lundberg Oliver Zeigermann wrote: Excatly! That's just what I was proposing in my last email! Would you want to assist? Hihi Oliver 2006/7/13, Henri Yandell [EMAIL PROTECTED]: Is the aim to have a 1.2 release of transaction at some point? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: Excatly! That's just what I was proposing in my last email! Would you want to assist? Definitely happy to assist with getting the release out there etc. No real itch on transactions themselves, but I want to do what I can to speed up our release cycles. I'll go through jira tonight and do the same thing I'll do for Pool; add version information for all new/old issues. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421712 - in /jakarta/commons/proper/collections/trunk: project.xml src/java/org/apache/commons/collections/keyvalue/MultiKey.java
Author: scolebourne Date: Thu Jul 13 15:05:01 2006 New Revision: 421712 URL: http://svn.apache.org/viewvc?rev=421712view=rev Log: Fix MultiKey spelling COLLECTIONS-216, from Hendrik Maryns Modified: jakarta/commons/proper/collections/trunk/project.xml jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/keyvalue/MultiKey.java Modified: jakarta/commons/proper/collections/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/project.xml?rev=421712r1=421711r2=421712view=diff == --- jakarta/commons/proper/collections/trunk/project.xml (original) +++ jakarta/commons/proper/collections/trunk/project.xml Thu Jul 13 15:05:01 2006 @@ -304,6 +304,9 @@ nameBerin Loritsch/name /contributor contributor + nameHendrik Maryns/name +/contributor +contributor nameStefano Mazzocchi/name /contributor contributor Modified: jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/keyvalue/MultiKey.java URL: http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/keyvalue/MultiKey.java?rev=421712r1=421711r2=421712view=diff == --- jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/keyvalue/MultiKey.java (original) +++ jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/keyvalue/MultiKey.java Thu Jul 13 15:05:01 2006 @@ -1,5 +1,5 @@ /* - * Copyright 2003-2004 The Apache Software Foundation + * Copyright 2003-2004,2006 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. @@ -22,7 +22,7 @@ * A codeMultiKey/code allows multiple map keys to be merged together. * p * The purpose of this class is to avoid the need to write code to handle - * maps of maps. An example might be the need to lookup a filename by + * maps of maps. An example might be the need to look up a file name by * key and locale. The typical solution might be nested maps. This class * can be used instead by creating an instance passing in the key and locale. * p @@ -33,7 +33,7 @@ * MultiKey multiKey = new MultiKey(key, locale); * map.put(multiKey, localizedText); * - * // later retireve the localized text + * // later retrieve the localized text * MultiKey multiKey = new MultiKey(key, locale); * String localizedText = (String) map.get(multiKey); * /pre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421713 - in /jakarta/commons/proper/modeler/trunk: RELEASE-NOTES.txt maven.xml project.properties project.xml
Author: dims
Date: Thu Jul 13 15:06:20 2006
New Revision: 421713
URL: http://svn.apache.org/viewvc?rev=421713view=rev
Log:
updates to project.xml, maven.xml, release notes etc in preparation to make a
release
Modified:
jakarta/commons/proper/modeler/trunk/RELEASE-NOTES.txt
jakarta/commons/proper/modeler/trunk/maven.xml
jakarta/commons/proper/modeler/trunk/project.properties
jakarta/commons/proper/modeler/trunk/project.xml
Modified: jakarta/commons/proper/modeler/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/RELEASE-NOTES.txt?rev=421713r1=421712r2=421713view=diff
==
--- jakarta/commons/proper/modeler/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/modeler/trunk/RELEASE-NOTES.txt Thu Jul 13 15:06:20
2006
@@ -1,7 +1,7 @@
$Id$
Commons Modeler Package
-Version 1.0
+Version 1.2
Release Notes
@@ -11,23 +11,27 @@
This document contains the release notes for this version of the Commons
Modeler package, and highlights changes since the previous version.
-
-NEW FEATURES:
-
-
-This is the initial release of the Commons Modeler package, which supports
-the easy creation and management of Model MBeans that are compatible with
-the Java Management Extensions (JMX) 1.0 specification. It has been tested
-in conjunction with two different JMX implementations:
-
-* The JMX Reference Implementation (version 1.0.1), available at:
- http://java.sun.com/products/JavaManagement/download.html
-
-* The MX4J Open Source Implementation of JMX (version 1.0-beta-3), from:
- http://mx4j.sourceforge.net/
-
+For more information on Jakarta Commons Modeler, see
+o http://jakarta.apache.org/commons/modeler/
BUG REPORTS ADDRESSED:
=
-No bug reports have been filed against Modeler.
+o MODELER-18support for general descriptors
+o MODELER-17[modeler] MbeansSource don't use args at mbeans and operations
+o MODELER-16[modeler] download links broken
+o MODELER-15[modeler] IntrospectionUtils memory leak
+o MODELER-14After setting an Attribute the Notification Listener will not
performed
+o MODELER-13[modeler] BaseModelMBean class setModeledType method should be
setModelerType
+o MODELER-12[modeler] ManagedBean uses the wrong case for ObjectReference
+o MODELER-11[modeler] Null Pointer Exception - Non-Singleton Registry
+o MODELER-10[modeler] DTD violation when using simple wrapping
+o MODELER-9 [modeler] Registry.convertValue doesn't support longs
+o MODELER-8 [modeler] AttributeChangeNotification sent before attribute
changes
+o MODELER-7 sendAttributeChangeNotification on setAttribute
+o MODELER-6 [modeler] wiki page is immutable and out-of-date
+o MODELER-5 [modeler] setServer stack overflow
+o MODELER-4 [modeler] Overloaded operations throw wrong number of
parameters exception
+o MODELER-3 [modeler] maven build fails on os x with test failure.
+o MODELER-2 [modeler] Registry insufficiently synchronized
+o MODELER-1 ClassNotFoundException while using the Notification
\ No newline at end of file
Modified: jakarta/commons/proper/modeler/trunk/maven.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/modeler/trunk/maven.xml?rev=421713r1=421712r2=421713view=diff
==
--- jakarta/commons/proper/modeler/trunk/maven.xml (original)
+++ jakarta/commons/proper/modeler/trunk/maven.xml Thu Jul 13 15:06:20 2006
@@ -1,4 +1,85 @@
+!--
+ Copyright 2001-2004 The Apache Software Foundation
+
+ Licensed under the Apache License, Version 2.0 (the License);
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an AS IS BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+--
project default=java:jar
+ xmlns:ant=jelly:ant
xmlns:j=jelly:core
+ !-- == --
+ !-- Copy into the binary distribution --
+ !-- == --
+ postGoal name=dist:prepare-bin-filesystem
+
+copy todir=${maven.dist.bin.assembly.dir}
+ fileset file='${basedir}/NOTICE.txt'/
+ fileset file=${basedir}/RELEASE-NOTES.txt/
+/copy
+
+ /postGoal
+
+ !-- == --
+ !-- Copy
[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
[ http://issues.apache.org/jira/browse/TRANSACTION-9?page=comments#action_12420952 ] Peter Fassev commented on TRANSACTION-9: Yes, I think it is still a valid request. In the mean time I have done some effort to extended the FileResourceManager, including the TranscationContext. Actually many of the functionality has been overwritten. It supports now transaction secure operations on files and directories including creating, renaming, moving and deleting. Please note, that there is still some job to do, mainly to clean the code and to extend the tests and to write a documentation, but for now it works. At least, it can be used as an example. If you are interested in it, please let me know. [transaction] Add full file management capabilities to the FileResourceManager -- Key: TRANSACTION-9 URL: http://issues.apache.org/jira/browse/TRANSACTION-9 Project: Commons Transaction Type: Improvement Environment: Operating System: All Platform: All Reporter: Peter Fassev Priority: Minor Hi, As stated in the doc the FileResourceManager is: A resource manager for streamable objects stored in a file system I agree, that this is a resource manager, but it could be easily extended, to support a full file management system. It will be very helpful to have additional methods like renameResource(), getResourceSize(), getResourceTime(), setResourceTime() etc. This are common file operations, which should be managed by the FileResourceManager. Further it will be very helpful to have (real) support for resource collections (folders). It will be necessary to distinguish between single resources (files) and collections (folders). Together, this features will enable a transactional access to any file based resources - for instance a document repository. Are there plans for such extensions and if not, will they actually fit in the goals of the transaction library? If not, please open the underlying structure, like the inner class TransactionContext, in order to add extensions the file management. For instance, it will be good to have a separate factory method, which creates the context. If you are interested in this proposal, I am ready to contribute to this project. I consider myself as an experienced java developer and I will be glad to help you. Best regards Peter Fassev -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-172) [collections] List/Set implementation.
[ http://issues.apache.org/jira/browse/COLLECTIONS-172?page=all ] Stephen Colebourne updated COLLECTIONS-172: --- Bugzilla Id: (was: 22826) Fix Version: 3.0 Final Version: (was: 3.0 Alpha 1) [collections] List/Set implementation. -- Key: COLLECTIONS-172 URL: http://issues.apache.org/jira/browse/COLLECTIONS-172 Project: Commons Collections Type: Improvement Environment: Operating System: All Platform: All Reporter: _matthewHawthorne Priority: Minor Fix For: 3.0 Final Attachments: ListSet.java, ListSetTest.java, patch.txt I created a simple class which implements both java.util.List and java.util.Set. In other words, it's a collection which maintains the order in which elements are added, and also does not allow duplicate elements. I'll attach the main and test class. Feel free to improve it. I found a need for this class, and I think others may also. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-103) SoftRefHashMap is all kinds of wonky
[ http://issues.apache.org/jira/browse/COLLECTIONS-103?page=all ] Stephen Colebourne updated COLLECTIONS-103: --- Bugzilla Id: (was: 9571) Fix Version: 2.1 SoftRefHashMap is all kinds of wonky Key: COLLECTIONS-103 URL: http://issues.apache.org/jira/browse/COLLECTIONS-103 Project: Commons Collections Type: Bug Environment: Operating System: All Platform: All Reporter: Paul Jack Fix For: 2.1 Many methods in SoftRefHashMap do not conform the the java.util.Map specification. After you populate a SoftRefHashMap using its put or putAll method, it transforms the values into SoftReferences. The get() method correctly re-translates the SoftReferences back into the actual object values, unless they've been garbage collected. However, the entrySet() collection view does NOT perform this reverse translation; iterating over an entry set gives you Map.Entry with SoftReference values. Since the equals() and hashCode() methods rely on iterating over the entry set, equals() and hashCode() are broken in SoftRefHashMap. Also, it's odd that after I put(key,value), containsValue(value) will return true, yet I won't be able to find the value in the entry set. Also, invoking setValue() on a Map.Entry in the entrySet will correctly update the map with a new value; however, the old value is not returned as per the Map specification. Also, the values() and entrySet() collection views are not backed by the map; alterations to the map are not reflected in any existing values() or entrySet() collection views. Also, containsKey(Object) is wierd. If I put(key,value), and the value is subsequently garbage collected, containsValue(value) will return false, yet containsKey(key) will still return true. Creating a values() collection view creates hard references to the map's values, essentially ruining the point of the class (so long as the values() collection view exists, the map does not function as a memory-aware cache). Finally, iterating over keySet() and entrySet() is wonky. Mappings might have been removed by the garbage collector, but the iterators will still return an object for the mapping. So keySet()'s iterator will return keys for values that aren't there anymore, and entrySet()'s iterator will return Map.Entries with keys that map to null instead of values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (COLLECTIONS-103) SoftRefHashMap is all kinds of wonky
[ http://issues.apache.org/jira/browse/COLLECTIONS-103?page=all ] Stephen Colebourne closed COLLECTIONS-103: -- SoftRefHashMap is all kinds of wonky Key: COLLECTIONS-103 URL: http://issues.apache.org/jira/browse/COLLECTIONS-103 Project: Commons Collections Type: Bug Environment: Operating System: All Platform: All Reporter: Paul Jack Fix For: 2.1 Many methods in SoftRefHashMap do not conform the the java.util.Map specification. After you populate a SoftRefHashMap using its put or putAll method, it transforms the values into SoftReferences. The get() method correctly re-translates the SoftReferences back into the actual object values, unless they've been garbage collected. However, the entrySet() collection view does NOT perform this reverse translation; iterating over an entry set gives you Map.Entry with SoftReference values. Since the equals() and hashCode() methods rely on iterating over the entry set, equals() and hashCode() are broken in SoftRefHashMap. Also, it's odd that after I put(key,value), containsValue(value) will return true, yet I won't be able to find the value in the entry set. Also, invoking setValue() on a Map.Entry in the entrySet will correctly update the map with a new value; however, the old value is not returned as per the Map specification. Also, the values() and entrySet() collection views are not backed by the map; alterations to the map are not reflected in any existing values() or entrySet() collection views. Also, containsKey(Object) is wierd. If I put(key,value), and the value is subsequently garbage collected, containsValue(value) will return false, yet containsKey(key) will still return true. Creating a values() collection view creates hard references to the map's values, essentially ruining the point of the class (so long as the values() collection view exists, the map does not function as a memory-aware cache). Finally, iterating over keySet() and entrySet() is wonky. Mappings might have been removed by the garbage collector, but the iterators will still return an object for the mapping. So keySet()'s iterator will return keys for values that aren't there anymore, and entrySet()'s iterator will return Map.Entries with keys that map to null instead of values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (COLLECTIONS-216) MultiKey's toString method should use Arrays.toString
[ http://issues.apache.org/jira/browse/COLLECTIONS-216?page=all ] Stephen Colebourne closed COLLECTIONS-216: -- Fix Version: 3.3 Resolution: Fixed Spelling fix checked in MultiKey's toString method should use Arrays.toString - Key: COLLECTIONS-216 URL: http://issues.apache.org/jira/browse/COLLECTIONS-216 Project: Commons Collections Type: Improvement Versions: 3.2 Reporter: Hendrik Maryns Priority: Minor Fix For: 3.3 Attachments: MultiKey.diff Some minor comments on MultiKey: - its toString method unnecessarily creates an extra Object. - there are some unnecessary casts - there is a mistake in the javadocs (actually, this mistake, 'lookup', which should be in two words, is prevalent in all of the map API) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (COLLECTIONS-103) SoftRefHashMap is all kinds of wonky
[ http://issues.apache.org/jira/browse/COLLECTIONS-103?page=all ] Stephen Colebourne reopened COLLECTIONS-103: SoftRefHashMap is all kinds of wonky Key: COLLECTIONS-103 URL: http://issues.apache.org/jira/browse/COLLECTIONS-103 Project: Commons Collections Type: Bug Environment: Operating System: All Platform: All Reporter: Paul Jack Fix For: 2.1 Many methods in SoftRefHashMap do not conform the the java.util.Map specification. After you populate a SoftRefHashMap using its put or putAll method, it transforms the values into SoftReferences. The get() method correctly re-translates the SoftReferences back into the actual object values, unless they've been garbage collected. However, the entrySet() collection view does NOT perform this reverse translation; iterating over an entry set gives you Map.Entry with SoftReference values. Since the equals() and hashCode() methods rely on iterating over the entry set, equals() and hashCode() are broken in SoftRefHashMap. Also, it's odd that after I put(key,value), containsValue(value) will return true, yet I won't be able to find the value in the entry set. Also, invoking setValue() on a Map.Entry in the entrySet will correctly update the map with a new value; however, the old value is not returned as per the Map specification. Also, the values() and entrySet() collection views are not backed by the map; alterations to the map are not reflected in any existing values() or entrySet() collection views. Also, containsKey(Object) is wierd. If I put(key,value), and the value is subsequently garbage collected, containsValue(value) will return false, yet containsKey(key) will still return true. Creating a values() collection view creates hard references to the map's values, essentially ruining the point of the class (so long as the values() collection view exists, the map does not function as a memory-aware cache). Finally, iterating over keySet() and entrySet() is wonky. Mappings might have been removed by the garbage collector, but the iterators will still return an object for the mapping. So keySet()'s iterator will return keys for values that aren't there anymore, and entrySet()'s iterator will return Map.Entries with keys that map to null instead of values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (COLLECTIONS-103) SoftRefHashMap is all kinds of wonky
[ http://issues.apache.org/jira/browse/COLLECTIONS-103?page=all ] Stephen Colebourne closed COLLECTIONS-103: -- Resolution: Fixed SoftRefHashMap is all kinds of wonky Key: COLLECTIONS-103 URL: http://issues.apache.org/jira/browse/COLLECTIONS-103 Project: Commons Collections Type: Bug Environment: Operating System: All Platform: All Reporter: Paul Jack Fix For: 2.1 Many methods in SoftRefHashMap do not conform the the java.util.Map specification. After you populate a SoftRefHashMap using its put or putAll method, it transforms the values into SoftReferences. The get() method correctly re-translates the SoftReferences back into the actual object values, unless they've been garbage collected. However, the entrySet() collection view does NOT perform this reverse translation; iterating over an entry set gives you Map.Entry with SoftReference values. Since the equals() and hashCode() methods rely on iterating over the entry set, equals() and hashCode() are broken in SoftRefHashMap. Also, it's odd that after I put(key,value), containsValue(value) will return true, yet I won't be able to find the value in the entry set. Also, invoking setValue() on a Map.Entry in the entrySet will correctly update the map with a new value; however, the old value is not returned as per the Map specification. Also, the values() and entrySet() collection views are not backed by the map; alterations to the map are not reflected in any existing values() or entrySet() collection views. Also, containsKey(Object) is wierd. If I put(key,value), and the value is subsequently garbage collected, containsValue(value) will return false, yet containsKey(key) will still return true. Creating a values() collection view creates hard references to the map's values, essentially ruining the point of the class (so long as the values() collection view exists, the map does not function as a memory-aware cache). Finally, iterating over keySet() and entrySet() is wonky. Mappings might have been removed by the garbage collector, but the iterators will still return an object for the mapping. So keySet()'s iterator will return keys for values that aren't there anymore, and entrySet()'s iterator will return Map.Entries with keys that map to null instead of values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-211) [collections] NullPredicate should have getInstance()
[ http://issues.apache.org/jira/browse/COLLECTIONS-211?page=all ] Stephen Colebourne updated COLLECTIONS-211: --- Bugzilla Id: (was: 27857) Fix Version: 3.1 [collections] NullPredicate should have getInstance() - Key: COLLECTIONS-211 URL: http://issues.apache.org/jira/browse/COLLECTIONS-211 Project: Commons Collections Type: Improvement Versions: 3.0 Environment: Operating System: Windows XP Platform: All Reporter: Torsten Curdt Priority: Minor Fix For: 3.1 For consistency reasons the NotNullPredicate should also have a static factory method getInstance(). It should just return the static object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-140) [collections] NotNullPredicate should have getInstance()
[ http://issues.apache.org/jira/browse/COLLECTIONS-140?page=all ] Stephen Colebourne updated COLLECTIONS-140: --- Bugzilla Id: (was: 27856) Fix Version: 3.1 [collections] NotNullPredicate should have getInstance() Key: COLLECTIONS-140 URL: http://issues.apache.org/jira/browse/COLLECTIONS-140 Project: Commons Collections Type: Improvement Versions: 3.0 Environment: Operating System: Windows XP Platform: All Reporter: Torsten Curdt Priority: Minor Fix For: 3.1 For consistency reasons the NotNullPredicate should also have a static factory method getInstance(). It should just return the static object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-115) Flat3Map doesn't implement Serializable
[ http://issues.apache.org/jira/browse/COLLECTIONS-115?page=all ] Stephen Colebourne updated COLLECTIONS-115: --- Bugzilla Id: (was: 27946) Fix Version: 3.1 Flat3Map doesn't implement Serializable --- Key: COLLECTIONS-115 URL: http://issues.apache.org/jira/browse/COLLECTIONS-115 Project: Commons Collections Type: Bug Versions: 3.0 Environment: Operating System: Linux Platform: All Reporter: Manik Surtani Fix For: 3.1 A very useful hish performance map. Sadly I cannot use it in my J2EE env because it isn't seriabilable and hence cannot be a parameter in any remote calls. Is there a specific reason as to why this isn't Serializable, or was this something that was overlooked? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-103) SoftRefHashMap is all kinds of wonky
[ http://issues.apache.org/jira/browse/COLLECTIONS-103?page=all ] Stephen Colebourne updated COLLECTIONS-103: --- Bugzilla Id: (was: 9571) Version: 2.0 SoftRefHashMap is all kinds of wonky Key: COLLECTIONS-103 URL: http://issues.apache.org/jira/browse/COLLECTIONS-103 Project: Commons Collections Type: Bug Versions: 2.0 Environment: Operating System: All Platform: All Reporter: Paul Jack Fix For: 2.1 Many methods in SoftRefHashMap do not conform the the java.util.Map specification. After you populate a SoftRefHashMap using its put or putAll method, it transforms the values into SoftReferences. The get() method correctly re-translates the SoftReferences back into the actual object values, unless they've been garbage collected. However, the entrySet() collection view does NOT perform this reverse translation; iterating over an entry set gives you Map.Entry with SoftReference values. Since the equals() and hashCode() methods rely on iterating over the entry set, equals() and hashCode() are broken in SoftRefHashMap. Also, it's odd that after I put(key,value), containsValue(value) will return true, yet I won't be able to find the value in the entry set. Also, invoking setValue() on a Map.Entry in the entrySet will correctly update the map with a new value; however, the old value is not returned as per the Map specification. Also, the values() and entrySet() collection views are not backed by the map; alterations to the map are not reflected in any existing values() or entrySet() collection views. Also, containsKey(Object) is wierd. If I put(key,value), and the value is subsequently garbage collected, containsValue(value) will return false, yet containsKey(key) will still return true. Creating a values() collection view creates hard references to the map's values, essentially ruining the point of the class (so long as the values() collection view exists, the map does not function as a memory-aware cache). Finally, iterating over keySet() and entrySet() is wonky. Mappings might have been removed by the garbage collector, but the iterators will still return an object for the mapping. So keySet()'s iterator will return keys for values that aren't there anymore, and entrySet()'s iterator will return Map.Entries with keys that map to null instead of values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-1) [collections] Collections Javadoc warnings with JDK 1.4.2
[ http://issues.apache.org/jira/browse/COLLECTIONS-1?page=all ] Stephen Colebourne updated COLLECTIONS-1: - Bugzilla Id: (was: 23680) Fix Version: 3.0 [collections] Collections Javadoc warnings with JDK 1.4.2 - Key: COLLECTIONS-1 URL: http://issues.apache.org/jira/browse/COLLECTIONS-1 Project: Commons Collections Type: Bug Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Eric Johnson Fix For: 3.0 Attachments: javadoc.patch, javadoc.patch, lastjavadocpatch.patch, test-javadoc.patch Numerous javadoc warnings when doing ant dist target under JDK 1.4.2. Partial patch to follow -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421727 - in /jakarta/commons/proper/collections/trunk: RELEASE-NOTES.html src/java/org/apache/commons/collections/map/DefaultedMap.java
Author: scolebourne
Date: Thu Jul 13 16:09:11 2006
New Revision: 421727
URL: http://svn.apache.org/viewvc?rev=421727view=rev
Log:
COLLECTIONS-215 - DefaultedMap clarify javadoc
Modified:
jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/DefaultedMap.java
Modified: jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html?rev=421727r1=421726r2=421727view=diff
==
--- jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html (original)
+++ jakarta/commons/proper/collections/trunk/RELEASE-NOTES.html Thu Jul 13
16:09:11 2006
@@ -60,6 +60,8 @@
centerh3JAVADOC/h3/center
ul
liIteratorChain - Clarify constructor behaviour/li
+liMuliKey - Spelling [COLLECTIONS-216]/li
+liDefaultedMap - Clarify transformer behaviour [COLLECTIONS-215]/li
/ul
/body
/html
Modified:
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/DefaultedMap.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/DefaultedMap.java?rev=421727r1=421726r2=421727view=diff
==
---
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/DefaultedMap.java
(original)
+++
jakarta/commons/proper/collections/trunk/src/java/org/apache/commons/collections/map/DefaultedMap.java
Thu Jul 13 16:09:11 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2005 The Apache Software Foundation
+ * Copyright 2005-2006 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -96,7 +96,7 @@
* The result will be returned as the result of the map get(key) method.
*
* @param map the map to decorate, must not be null
- * @param factory the factory to use, must not be null
+ * @param factory the factory to use to create entries, must not be null
* @throws IllegalArgumentException if map or factory is null
*/
public static Map decorate(Map map, Factory factory) {
@@ -114,14 +114,14 @@
* will be returned as the result of the map get(key) method.
*
* @param map the map to decorate, must not be null
- * @param factory the factory to use, must not be null
+ * @param transformer the transformer to use as a factory to create
entries, must not be null
* @throws IllegalArgumentException if map or factory is null
*/
-public static Map decorate(Map map, Transformer factory) {
-if (factory == null) {
+public static Map decorate(Map map, Transformer transformer) {
+if (transformer == null) {
throw new IllegalArgumentException(Transformer must not be null);
}
- return new DefaultedMap(map, factory);
+ return new DefaultedMap(map, transformer);
}
//---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421728 - in /jakarta/commons/proper/transaction/trunk: build.xml project.properties xdocs/navigation.xml xdocs/style/basic.xsl xdocs/style/project.css
Author: dennisl
Date: Thu Jul 13 16:11:12 2006
New Revision: 421728
URL: http://svn.apache.org/viewvc?rev=421728view=rev
Log:
Remove the dependency on commons-build (see
http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture)
Sync look and feel with the other components
Removed xdocs target in ant build
Added:
jakarta/commons/proper/transaction/trunk/xdocs/style/project.css (with
props)
Removed:
jakarta/commons/proper/transaction/trunk/xdocs/style/basic.xsl
Modified:
jakarta/commons/proper/transaction/trunk/build.xml
jakarta/commons/proper/transaction/trunk/project.properties
jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml
Modified: jakarta/commons/proper/transaction/trunk/build.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/build.xml?rev=421728r1=421727r2=421728view=diff
==
--- jakarta/commons/proper/transaction/trunk/build.xml (original)
+++ jakarta/commons/proper/transaction/trunk/build.xml Thu Jul 13 16:11:12 2006
@@ -314,26 +314,10 @@
!-- ===
--
!-- Build documentation
--
!-- ===
--
-target name=doc depends=prepare,javadocs,xdocs
+target name=doc depends=prepare,javadocs
description=Generate full documentation /
-target name=xdocs depends=prepare description=Generate
documentation
-style basedir=xdocs destdir=${build.doc} extension=.html
style=xdocs/style/basic.xsl includes=*.xml/
-style basedir=xdocs/file destdir=${build.doc}/file
extension=.html style=xdocs/style/basic.xsl includes=*.xml/
-style basedir=xdocs/locks destdir=${build.doc}/locks
extension=.html style=xdocs/style/basic.xsl includes=*.xml/
-style basedir=xdocs/maps destdir=${build.doc}/maps
extension=.html style=xdocs/style/basic.xsl includes=*.xml/
-copy todir=${build.doc}
-fileset dir=xdocs
-include name=**/*.gif/
-include name=**/*.jpg/
-include name=**/*.png/
-include name=**/*.css/
-include name=**/*.sample/
-/fileset
-/copy
-/target
-
- !--
+ !--
===
Creates the API documentation
===
Modified: jakarta/commons/proper/transaction/trunk/project.properties
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.properties?rev=421728r1=421727r2=421728view=diff
==
--- jakarta/commons/proper/transaction/trunk/project.properties (original)
+++ jakarta/commons/proper/transaction/trunk/project.properties Thu Jul 13
16:11:12 2006
@@ -7,8 +7,7 @@
maven.javadoc.author=false
maven.javadoc.links=http://java.sun.com/products/jdk/1.4/docs/api
-maven.xdoc.jsl=../commons-build/commons-site.jsl
-maven.xdoc.date=bottom
+maven.xdoc.date=left
maven.xdoc.poweredby.image=maven-feather.png
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/commons/charter.html
Modified: jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml?rev=421728r1=421727r2=421728view=diff
==
--- jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml (original)
+++ jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml Thu Jul 13
16:11:12 2006
@@ -1,31 +1,31 @@
?xml version=1.0 encoding=ISO-8859-1?
-!DOCTYPE org.apache.commons.menus SYSTEM
'../../../jakarta-commons/commons-build/menus/menus.dtd'
+!DOCTYPE org.apache.commons.menus SYSTEM
'http://jakarta.apache.org/commons/build/maven-build.dtd'
project name=Commons#xA0;Transaction
titleCommons#xA0;Transaction/title
body
+links
+ item name=Jakarta Commons
href=http://jakarta.apache.org/commons//
+/links
+
menu name=Commons#xA0;Transaction
-item name=Overview href=/index.html /
-item name=Transactional Maps href=/maps/index.html
- item name=Map Wrapper comparision
href=/maps/wrappers-comparision.html/
-/item
-item name=Locking href=/locks/index.html
- item name=Introduction href=/locks/tutorial.html/
- item name=Preference Locks href=/locks/preference.html/
- item name=Transaction Concepts href=/locks/concepts.html/
- item name=Deadlocks href=/locks/deadlock.html/
-/item
-item
svn commit: r421729 - in /jakarta/commons/proper/transaction/trunk: project.properties project.xml
Author: dennisl Date: Thu Jul 13 16:13:21 2006 New Revision: 421729 URL: http://svn.apache.org/viewvc?rev=421729view=rev Log: Remove unused reports and report configuration properties Modified: jakarta/commons/proper/transaction/trunk/project.properties jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/project.properties URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.properties?rev=421729r1=421728r2=421729view=diff == --- jakarta/commons/proper/transaction/trunk/project.properties (original) +++ jakarta/commons/proper/transaction/trunk/project.properties Thu Jul 13 16:13:21 2006 @@ -1,5 +1,3 @@ -maven.checkstyle.properties = checkstyle.xml - # uncomment the next line to work in offline mode (no jar download no linkcheck) #maven.mode.online= maven.changelog.factory=org.apache.maven.svnlib.SvnChangeLogFactory @@ -27,5 +25,3 @@ maven.junit.fork=true maven.junit.sysproperties=org.xml.sax.driver org.xml.sax.driver=org.apache.xerces.parsers.SAXParser - -clover.excludes=**/Test*.java Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.xml?rev=421729r1=421728r2=421729view=diff == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Thu Jul 13 16:13:21 2006 @@ -1,7 +1,6 @@ ?xml version=1.0 encoding=ISO-8859-1 ? project pomVersion3/pomVersion - !-- extend../commons-build/project.xml/extend -- nameTransaction/name groupIdcommons-transaction/groupId artifactIdcommons-transaction/artifactId @@ -180,7 +179,6 @@ reports reportmaven-changelog-plugin/report -reportmaven-changes-plugin/report reportmaven-developer-activity-plugin/report reportmaven-file-activity-plugin/report reportmaven-javadoc-plugin/report - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (COLLECTIONS-215) Javadoc in DefaultedMap very inconsistent
[ http://issues.apache.org/jira/browse/COLLECTIONS-215?page=all ] Stephen Colebourne closed COLLECTIONS-215: -- Fix Version: 3.3 Resolution: Won't Fix Assign To: Stephen Colebourne I can't make the changes you propose as they would be backwards incompatible. The class was coded this way in an effort to improve performance, but that was a bad idea. But its too late to fix now. I have enhanced the javadoc though. Javadoc in DefaultedMap very inconsistent - Key: COLLECTIONS-215 URL: http://issues.apache.org/jira/browse/COLLECTIONS-215 Project: Commons Collections Type: Improvement Versions: 3.2 Reporter: Hendrik Maryns Assignee: Stephen Colebourne Fix For: 3.3 Attachments: DefaultedMap.diff The javadocs in DefaultedMap is very inconsistent. It speaks of factory when a transformer is meant, it speaks of transformer when value is meant and that sort of stuff. Besides, it would be much cleaner to declare 'value' of type Transformer, and create a transformer every time, except when one is passed (the instanceof checks are wrong anyway), (I'd rename it to transformer, too). Even nicer would be to split up the constructor(s) into one that takes a value, and one that takes a Transformer, no instanceof checks needed, much cleaner code, generification is almost trivial :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r421734 - in /jakarta/commons/proper/transaction/trunk: project.xml xdocs/downloads.xml xdocs/index.xml xdocs/navigation.xml xdocs/releases.xml
Author: dennisl
Date: Thu Jul 13 16:36:02 2006
New Revision: 421734
URL: http://svn.apache.org/viewvc?rev=421734view=rev
Log:
Rename xdocs/downloads.xml to xdocs/releases.xml
Fix broken links
Added:
jakarta/commons/proper/transaction/trunk/xdocs/releases.xml
- copied, changed from r421707,
jakarta/commons/proper/transaction/trunk/xdocs/downloads.xml
Removed:
jakarta/commons/proper/transaction/trunk/xdocs/downloads.xml
Modified:
jakarta/commons/proper/transaction/trunk/project.xml
jakarta/commons/proper/transaction/trunk/xdocs/index.xml
jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml
Modified: jakarta/commons/proper/transaction/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.xml?rev=421734r1=421733r2=421734view=diff
==
--- jakarta/commons/proper/transaction/trunk/project.xml (original)
+++ jakarta/commons/proper/transaction/trunk/project.xml Thu Jul 13 16:36:02
2006
@@ -29,14 +29,14 @@
/licenses
gumpRepositoryIdjakarta/gumpRepositoryId
- issueTrackingUrlhttp://issues.apache.org/jira//issueTrackingUrl
+
issueTrackingUrlhttp://issues.apache.org/jira/browse/${pom.artifactId.substring(8).toUpperCase()}/issueTrackingUrl
siteAddressminotaur.apache.org/siteAddress
siteDirectory/www/jakarta.apache.org/commons/${pom.artifactId.substring(8)}//siteDirectory
distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons/${pom.artifactId.substring(8)}//distributionDirectory
repository
connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/connection
-
urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk/url
+
urlhttp://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk//url
/repository
mailingLists
@@ -44,13 +44,13 @@
nameCommons Dev List/name
subscribe[EMAIL PROTECTED]/subscribe
unsubscribe[EMAIL PROTECTED]/unsubscribe
- archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL
PROTECTED]/archive
+
archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-dev//archive
/mailingList
mailingList
nameCommons User List/name
subscribe[EMAIL PROTECTED]/subscribe
unsubscribe[EMAIL PROTECTED]/unsubscribe
- archivehttp://mail-archives.apache.org/eyebrowse/[EMAIL
PROTECTED]/archive
+
archivehttp://mail-archives.apache.org/mod_mbox/jakarta-commons-user//archive
/mailingList
/mailingLists
Modified: jakarta/commons/proper/transaction/trunk/xdocs/index.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/xdocs/index.xml?rev=421734r1=421733r2=421734view=diff
==
--- jakarta/commons/proper/transaction/trunk/xdocs/index.xml (original)
+++ jakarta/commons/proper/transaction/trunk/xdocs/index.xml Thu Jul 13
16:36:02 2006
@@ -60,7 +60,7 @@
section name=Releases
p
- See the a href=downloads.htmldownloads/a page for information on
obtaining releases.
+ See the a href=releases.htmlreleases/a page for information on
obtaining releases.
/p
/section
Modified: jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml?rev=421734r1=421733r2=421734view=diff
==
--- jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml (original)
+++ jakarta/commons/proper/transaction/trunk/xdocs/navigation.xml Thu Jul 13
16:36:02 2006
@@ -11,7 +11,7 @@
item name=Overview href=/index.html /
item name=Download
href=http://jakarta.apache.org/site/downloads/downloads_commons-transaction.cgi/
item name=Javadoc href=/apidocs/index.html/
- item name=Downloads href=downloads.html/
+ item name=Releases href=releases.html/
/menu
menu name=Documentation
item name=Transactional Maps href=/maps/index.html
Copied: jakarta/commons/proper/transaction/trunk/xdocs/releases.xml (from
r421707, jakarta/commons/proper/transaction/trunk/xdocs/downloads.xml)
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/xdocs/releases.xml?p2=jakarta/commons/proper/transaction/trunk/xdocs/releases.xmlp1=jakarta/commons/proper/transaction/trunk/xdocs/downloads.xmlr1=421707r2=421734rev=421734view=diff
==
--- jakarta/commons/proper/transaction/trunk/xdocs/downloads.xml (original)
+++ jakarta/commons/proper/transaction/trunk/xdocs/releases.xml Thu Jul 13
16:36:02 2006
@@ -10,17 +10,14 @@
section name=Releases
pThe following releases are
svn commit: r421737 - /jakarta/commons/proper/transaction/trunk/project.xml
Author: dennisl Date: Thu Jul 13 16:37:53 2006 New Revision: 421737 URL: http://svn.apache.org/viewvc?rev=421737view=rev Log: Add dependency on maven-xdoc-plugin Modified: jakarta/commons/proper/transaction/trunk/project.xml Modified: jakarta/commons/proper/transaction/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/project.xml?rev=421737r1=421736r2=421737view=diff == --- jakarta/commons/proper/transaction/trunk/project.xml (original) +++ jakarta/commons/proper/transaction/trunk/project.xml Thu Jul 13 16:37:53 2006 @@ -157,6 +157,20 @@ version2.0.2/version /dependency !-- /these two are required by maven -- + +dependency + groupIdmaven/groupId + artifactIdmaven-xdoc-plugin/artifactId + version1.9.2/version + urlhttp://maven.apache.org/maven-1.x/reference/plugins/xdoc//url + typeplugin/type + properties + comment + lt;stronggt;Site Onlylt;/stronggt; - v1.9.2 (minimum) + /comment + optionaltrue/optional + /properties +/dependency /dependencies build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Release plan?
On 7/13/06, Henri Yandell [EMAIL PROTECTED] wrote: On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote: Excatly! That's just what I was proposing in my last email! Would you want to assist? Definitely happy to assist with getting the release out there etc. No real itch on transactions themselves, but I want to do what I can to speed up our release cycles. I don't have an itch/need for transaction either but am also happy to help with build/site issues that normally get raised with release candidates, if you want. Is maven the primary build mechanism (i.e. the one you use for release)? Also what is the minimum JDK version for transaction? Niall I'll go through jira tonight and do the same thing I'll do for Pool; add version information for all new/old issues. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-11) [pool] GenericObjectPool.Evictor._cancelled should to be declared as volatile
[ http://issues.apache.org/jira/browse/POOL-11?page=all ] Henri Yandell updated POOL-11: -- Bugzilla Id: (was: 37321) Fix Version: 1.3 [pool] GenericObjectPool.Evictor._cancelled should to be declared as volatile - Key: POOL-11 URL: http://issues.apache.org/jira/browse/POOL-11 Project: Commons Pool Type: Bug Environment: Operating System: All Platform: All Reporter: Sandy McArthur (from Bugzilla import) Priority: Minor Fix For: 1.3 In GenericObjectPool line 1121 the field _cancelled should to be declared as volatile. My understanding of the JLS is that Threads are allowed to make a local copy of shared variables and since _cancled is used by a a Thread to control termination of the run() method and appears to only ever be updated by other threads calling the cancle() method which means the update to _cancled may go unnoticed for a good long while. That said, every JVM I've used was implemented in a way that would detect a change to _cancled in a reasonable amount of time but that behavior shouldn't be depended on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-8) [pool] Compilation under 1.5: enum keyword
[ http://issues.apache.org/jira/browse/POOL-8?page=all ] Henri Yandell updated POOL-8: - Bugzilla Id: (was: 29912) Fix Version: 1.3 [pool] Compilation under 1.5: enum keyword -- Key: POOL-8 URL: http://issues.apache.org/jira/browse/POOL-8 Project: Commons Pool Type: Bug Versions: 1.2 Environment: Operating System: other Platform: Other Reporter: Dirk Verbeeck Fix For: 1.3 Mail from Greg Billock on commons-dev -- I recently compiled commons-pool under JDK1.5 without a problem except for two files: /src/java/org/apache/commons/pool/impl/StackKeyedObjectPool.java /src/java/org/apache/commons/pool/impl/StackObjectPool.java These two files use the new 1.5 keyword 'enum' in an enumeration. A shallow fix is to simply rename the variable to 'enm' or something. A deeper fix might be to use iterator() method. I'm happy to contribute a patch which enables clean 1.5 compilation, but assuming the shallow fix is desired, it is pretty straightforward. Please email me directly if you (Dirk?) would like the diffs. Thanks for the pooling classes! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-6) [pool] Number of tested objects in eviction runs of GenericObjectPool
[ http://issues.apache.org/jira/browse/POOL-6?page=all ] Henri Yandell updated POOL-6: - Bugzilla Id: (was: 33265) Fix Version: 1.3 [pool] Number of tested objects in eviction runs of GenericObjectPool - Key: POOL-6 URL: http://issues.apache.org/jira/browse/POOL-6 Project: Commons Pool Type: Bug Versions: 1.2 Environment: Operating System: All Platform: All Reporter: Thomas Schürger Priority: Minor Fix For: 1.3 Attachments: GenericObjectPool-maxNumTestsPerEvictionRun.patch Hi, if numTestsPerEvictionRun is set to n and there are less than n idle objects in the pool, the evictor thread will still make n tests on these objects in a round-robin manner, i.e. idle objects can be tested more than once per eviction run. As this also includes validity tests if testWhileIdle is enbabled and validity tests may be time-consuming, this is a rather unwanted behavior. Instead of testing getNumTests() objects, the pool should test min(_pool.size(),getNumTests()) objects per eviction run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-5) [pool] GenericObjectPool: TestWhileIdle is mutually exclusive with MinEvictableIdleTimeMillis
[ http://issues.apache.org/jira/browse/POOL-5?page=all ] Henri Yandell updated POOL-5: - Bugzilla Id: (was: 31900) Fix Version: 1.3 [pool] GenericObjectPool: TestWhileIdle is mutually exclusive with MinEvictableIdleTimeMillis - Key: POOL-5 URL: http://issues.apache.org/jira/browse/POOL-5 Project: Commons Pool Type: Bug Versions: 1.2 Environment: Operating System: All Platform: All Reporter: Eric Simmerman Fix For: 1.3 Attachments: GenericObjectPools-TestWhileIdle-with-MinEvictableIdleTimeMillis.patch If a GenericObjectPool is configured with a postive MinEvictableIdleTimeMillis value, then idle validations are not performed even if TestWhileIdle is true. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-4) GenericObjectPool: Negative _maxActive doesn't allow growth
[ http://issues.apache.org/jira/browse/POOL-4?page=all ]
Henri Yandell updated POOL-4:
-
Bugzilla Id: (was: 13649)
Fix Version: 1.1
GenericObjectPool: Negative _maxActive doesn't allow growth
---
Key: POOL-4
URL: http://issues.apache.org/jira/browse/POOL-4
Project: Commons Pool
Type: Bug
Versions: 1.0.1
Environment: Operating System: other
Platform: Other
Reporter: John Rayburn
Fix For: 1.1
setMaxActive documents that:
The cap on the total number of active instances from my pool.
Use a negative value for an infinite number of instances.
However, the code (see below) when _maxActive is negative, acts as if the
pool
is empty, not that infinite resources should be allowed:
if(_maxActive 0 _numActive _maxActive) {
Object obj = _factory.makeObject();
pair = new ObjectTimestampPair(obj);
} else {
// the pool is exhausted
switch(_whenExhaustedAction) {
case WHEN_EXHAUSTED_GROW:
Object obj = _factory.makeObject();
pair = new ObjectTimestampPair(obj);
break;
case WHEN_EXHAUSTED_FAIL:
throw new NoSuchElementException();
case WHEN_EXHAUSTED_BLOCK:
try {
if(_maxWait = 0) {
wait();
} else {
wait(_maxWait);
}
} catch(InterruptedException e) {
// ignored
}
if(_maxWait 0 ((System.currentTimeMillis() -
starttime) = _maxWait)) {
throw new NoSuchElementException(Timeout
waiting for idle object);
} else {
continue; // keep looping
}
default:
throw new IllegalArgumentException
(whenExhaustedAction + _whenExhaustedAction + not recognized.);
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-3) [pool] GenericObjectPool WHEN_EXHAUSTED_BLOCK behvior could wait almost twice as long as desired
[ http://issues.apache.org/jira/browse/POOL-3?page=all ] Henri Yandell updated POOL-3: - Bugzilla Id: (was: 37337) Fix Version: 1.3 [pool] GenericObjectPool WHEN_EXHAUSTED_BLOCK behvior could wait almost twice as long as desired Key: POOL-3 URL: http://issues.apache.org/jira/browse/POOL-3 Project: Commons Pool Type: Bug Environment: Operating System: All Platform: All Reporter: Sandy McArthur (from Bugzilla import) Priority: Minor Fix For: 1.3 Very minor bug: On lines 797 of GenericObjectPool and lines 809 of GenericKeyedObjectPool the code is such that if the pool is exhausted and the thread waits and is notified shortly before _maxWait time has elapsed then then the thread may end up waiting for another period of _maxWait. Combined with the previous wait the thread could have actually waited almost twice the desired time. The correct behavior would be to do the math and wait a lesser amount adjusted for the previous wait interval. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (POOL-2) [pool] clean up some JavaDoc warnings
[ http://issues.apache.org/jira/browse/POOL-2?page=all ] Henri Yandell updated POOL-2: - Bugzilla Id: (was: 34934) Fix Version: 1.3 [pool] clean up some JavaDoc warnings - Key: POOL-2 URL: http://issues.apache.org/jira/browse/POOL-2 Project: Commons Pool Type: Bug Versions: 1.2 Environment: Operating System: other Platform: Other Reporter: Dirk Verbeeck Priority: Trivial Fix For: 1.3 Attachments: StackObjectPool.java.javadoc.patch From Sandy McArthur 2005-05-13 23:26 While I was editing this file I figued I'd run IDEA's inspection tools and it identified some JavaDoc warnings. This is a patch to fix them. It adds a period to two javadoc comments and a @throws clause to another. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (POOL-82) 2 tests failing on JDK 1.4/1.6 on Linux
[ http://issues.apache.org/jira/browse/POOL-82?page=comments#action_12420994 ] Henri Yandell commented on POOL-82: --- I'm doing maven clean jar by the way - in case you're referring to the Ant build with TestAll. 2 tests failing on JDK 1.4/1.6 on Linux --- Key: POOL-82 URL: http://issues.apache.org/jira/browse/POOL-82 Project: Commons Pool Type: Bug Environment: JDK 1.6 and 1.4.2 on Debian Linux Reporter: Henri Yandell Assignee: Sandy McArthur Might already be known, but figured I'd report it just in case. Testsuite: org.apache.commons.pool.TestObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.724 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestObjectPoolFactory has no public constructor TestCase(String name) or TestCase() and Testsuite: org.apache.commons.pool.TestKeyedObjectPoolFactory Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.727 sec Testcase: warning(junit.framework.TestSuite$1): FAILED Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.commons.pool.TestKeyedObjectPoolFactory has no public constructor TestCase(String name) or TestCase() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TRANSACTION-1) [transaction] FileResourceManager fails on Xids because of toString() usage for directory names
[ http://issues.apache.org/jira/browse/TRANSACTION-1?page=all ] Henri Yandell updated TRANSACTION-1: Bugzilla Id: (was: 37379) Fix Version: 1.2 [transaction] FileResourceManager fails on Xids because of toString() usage for directory names --- Key: TRANSACTION-1 URL: http://issues.apache.org/jira/browse/TRANSACTION-1 Project: Commons Transaction Type: Bug Versions: 1.1 Environment: Operating System: other Platform: Other Reporter: Jörg Heinicke Fix For: 1.2 Attachments: FileResourceManager.java.patch, FileResourceManager.java.patch, FileResourceManager.patch.txt As mentioned at http://marc.theaimsgroup.com/?l=jakarta-commons-devm=113101671215483w=4 the FileResourceManager has a limitation due to the usage of toString() on the transaction IDs used for the directories: String baseDir = workDir + / + txId; String changeDir = baseDir + / + WORK_CHANGE_DIR; new File(changeDir).mkdirs(); In some environments you don't have influence on the created IDs like in JTA. The FileResourceManager fails on the then wrongly named directories. Therefore I introduced a getTransactionBaseDir(txId). The algorithm for it is quite easy and more or less copied from generatedUniqueTxId(). Don't know if it is good or if it works in every case, maybe a more solid algorithm might be needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TRANSACTION-10) [transaction] Migrating to commons-logging
[ http://issues.apache.org/jira/browse/TRANSACTION-10?page=comments#action_12420995 ] Henri Yandell commented on TRANSACTION-10: -- This sounds to me like it was a WONTFIX. Jörg/Oliver? [transaction] Migrating to commons-logging -- Key: TRANSACTION-10 URL: http://issues.apache.org/jira/browse/TRANSACTION-10 Project: Commons Transaction Type: Improvement Versions: 1.1 Environment: Operating System: All Platform: Other Reporter: Esteban Sancho Priority: Minor Attachments: CommonsLoggerFacade.java Hi folks, Might I suggest to migrate from LoggerFacade to commons-logging? The reasons would be: 1) It's a commons package 2) Easier integration on almost every project 3) The API user shouldn't have to take care about the logging strategy. I think the API would be much easier to use. I'm asking this because it was pretty hard for me to debug a problem using this package with Jotm. At last, it was a bug in Jotm but I needed to almost rewrite the logging strategy to find it. I made my own branch (backward incompatible) to debug the problem and then restablished the original package. Please let me know your thoughts and I'd be glad to help in the task. Thanks, Esteban -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
[ http://issues.apache.org/jira/browse/TRANSACTION-9?page=comments#action_12420996 ] Henri Yandell commented on TRANSACTION-9: - Oliver - is this a 1.2 feature or something longer term (ie: 1.3)? [transaction] Add full file management capabilities to the FileResourceManager -- Key: TRANSACTION-9 URL: http://issues.apache.org/jira/browse/TRANSACTION-9 Project: Commons Transaction Type: Improvement Environment: Operating System: All Platform: All Reporter: Peter Fassev Priority: Minor Hi, As stated in the doc the FileResourceManager is: A resource manager for streamable objects stored in a file system I agree, that this is a resource manager, but it could be easily extended, to support a full file management system. It will be very helpful to have additional methods like renameResource(), getResourceSize(), getResourceTime(), setResourceTime() etc. This are common file operations, which should be managed by the FileResourceManager. Further it will be very helpful to have (real) support for resource collections (folders). It will be necessary to distinguish between single resources (files) and collections (folders). Together, this features will enable a transactional access to any file based resources - for instance a document repository. Are there plans for such extensions and if not, will they actually fit in the goals of the transaction library? If not, please open the underlying structure, like the inner class TransactionContext, in order to add extensions the file management. For instance, it will be good to have a separate factory method, which creates the context. If you are interested in this proposal, I am ready to contribute to this project. I consider myself as an experienced java developer and I will be glad to help you. Best regards Peter Fassev -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VALIDATOR-196) GenericValidator#matchRegexp
GenericValidator#matchRegexp Key: VALIDATOR-196 URL: http://issues.apache.org/jira/browse/VALIDATOR-196 Project: Commons Validator Type: Bug Versions: 1.3.1 Environment: Windows 2000 ; J2SDK 1.4.2 ; Eclipse 3.1.2 Reporter: lutianxiang GenericValidator.matchRegexp(as*^%dfasd1314213,[a-zA-Z0-9]*); User this method cannot get FALSE value In this method Source like this... . return matcher.match(/ + regexp + /, value); should be .. return matcher.match(// + regexp + //, value); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-82) [collections] Map.debugPrint improvements
[ http://issues.apache.org/jira/browse/COLLECTIONS-82?page=all ] Henri Yandell updated COLLECTIONS-82: - Bugzilla Id: (was: 20740) Version: 2.1 (was: 1.0.1 Final) [collections] Map.debugPrint improvements - Key: COLLECTIONS-82 URL: http://issues.apache.org/jira/browse/COLLECTIONS-82 Project: Commons Collections Type: Bug Versions: 2.1 Environment: Operating System: other Platform: Other Reporter: Max Rydahl Andersen Attachments: MapUtils patch1, MapUtils patch2, TestMapUtils patch1, patch.txt, patch.txt debugPrint and verbosePrint in MapUtils makes a cast of the key to a string (instead of calling toString() on it) which makes it impossible to use for debug printin maps with keys other than strings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-5) [codec] Hex converts illegal characters to 255
[ http://issues.apache.org/jira/browse/CODEC-5?page=all ] Henri Yandell updated CODEC-5: -- Bugzilla Id: (was: 28455) Fix Version: 1.3 [codec] Hex converts illegal characters to 255 -- Key: CODEC-5 URL: http://issues.apache.org/jira/browse/CODEC-5 Project: Commons Codec Type: Bug Versions: 1.2 Environment: Operating System: other Platform: Other Reporter: Gary Gregory Fix For: 1.3 List: jakarta-commons-dev Subject:[codec] Proposal for improvement Hex codec From: Tom van den Berge tom.vandenberge () bibit ! com Date: 2004-04-15 8:49:31 Message-ID: 407E4C9B.5070701 () bibit ! com [Download message RAW] I'm using the Hex codec to decode e.g. the string qq. What surprises me is that this obviously illegal hex value is decoded into one byte value 255. In fact all non-hex 'character-pairs' are decoded to value 255. Wouldn't it be better to throw a DecoderException if illegal characters are passed in? The current implementation decodes values that is is actually not able to decode, which is wrong. Cheers, Tom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-2) Provide a package.html for org/apache/commons/codec/net
[ http://issues.apache.org/jira/browse/CODEC-2?page=all ] Henri Yandell updated CODEC-2: -- Bugzilla Id: (was: 22403) Fix Version: 1.2 Provide a package.html for org/apache/commons/codec/net --- Key: CODEC-2 URL: http://issues.apache.org/jira/browse/CODEC-2 Project: Commons Codec Type: Bug Versions: 1.2 Environment: Operating System: other Platform: Other Reporter: Tim O'Brien Fix For: 1.2 The net subpackage does not have adequate JavaDoc. A package.html needs to be created which acts as a usage guide for the codec in that package. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-1) [CODEC] IndexOutOfBoundsException when encoding non-ASCII characters
[ http://issues.apache.org/jira/browse/CODEC-1?page=all ] Henri Yandell updated CODEC-1: -- Bugzilla Id: (was: 21633) Fix Version: 1.2 [CODEC] IndexOutOfBoundsException when encoding non-ASCII characters - Key: CODEC-1 URL: http://issues.apache.org/jira/browse/CODEC-1 Project: Commons Codec Type: Bug Versions: Nightly Builds Environment: Operating System: other Platform: Other Reporter: Michael Becke Fix For: 1.2 Attachments: urlCodec.patch URLCodec causes an IndexOutOfBoundsException in BitSet when encoding non-ASCII characters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-4) [codec] ClassCastException in Hex.decode(Object) fixed.
[ http://issues.apache.org/jira/browse/CODEC-4?page=all ] Henri Yandell updated CODEC-4: -- Bugzilla Id: (was: 24360) Fix Version: 1.2 [codec] ClassCastException in Hex.decode(Object) fixed. --- Key: CODEC-4 URL: http://issues.apache.org/jira/browse/CODEC-4 Project: Commons Codec Type: Bug Versions: 1.1 Environment: Operating System: All Platform: All Reporter: Gary Gregory Fix For: 1.2 You get a ClassCastException in Hex.decode(Object) if you pass in a String object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-3) Soundex encoding bugs
[ http://issues.apache.org/jira/browse/CODEC-3?page=all ] Henri Yandell updated CODEC-3: -- Bugzilla Id: (was: 24471) Fix Version: 1.2 Soundex encoding bugs - Key: CODEC-3 URL: http://issues.apache.org/jira/browse/CODEC-3 Project: Commons Codec Type: Bug Versions: 1.1 Environment: Operating System: All Platform: All Reporter: Gary Gregory Fix For: 1.2 Soundex encoding bugs: (1) The HW rule is not applied. (2) hyphens and apostrophes are not ignored. Fixed in CVS. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-20) [codec] URLCodec.decode() corrupts characters 127 in unencoded strings
[ http://issues.apache.org/jira/browse/CODEC-20?page=all ] Henri Yandell updated CODEC-20: --- Bugzilla Id: (was: 31161) Fix Version: 1.4 Looks like this issue is probably ready for closing with the result being the added unit test to show that Codec can't do much here. [codec] URLCodec.decode() corrupts characters 127 in unencoded strings Key: CODEC-20 URL: http://issues.apache.org/jira/browse/CODEC-20 Project: Commons Codec Type: Bug Versions: 1.3 Environment: Operating System: Linux Platform: PC Reporter: Hannes Wallnoefer Fix For: 1.4 Attachments: codec.patch If URLCodec.decode() is called with a String that contains unencoded characters in the 128-255 range, these characters are corrupted. The reason for this is in the way characters that don't need decoding are passed from the source to the target string: int b = bytes[i]; (...) buffer.write(b); If a character code is 127, it results in integer b being in the -128..-1 range, and when it's lowest byte is written to the buffer it's something else than the original one. I think the fix would be to add 256 to b if b is less than zero. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-51) 2 Test failures in SoundexTest
[ http://issues.apache.org/jira/browse/CODEC-51?page=all ] Henri Yandell updated CODEC-51: --- Fix Version: 1.4 Unit tests should pass or not be included for a release (imo). Marking as a fix for 1.4. 2 Test failures in SoundexTest -- Key: CODEC-51 URL: http://issues.apache.org/jira/browse/CODEC-51 Project: Commons Codec Type: Bug Environment: Debian Linux, JDK 1.4.2 and 1.6 Reporter: Henri Yandell Fix For: 1.4 Testsuite: org.apache.commons.codec.language.SoundexTest Tests run: 25, Failures: 2, Errors: 0, Time elapsed: 0.907 sec Testcase: testUsMappingOWithDiaeresis(org.apache.commons.codec.language.SoundexTest): FAILED expected:?000 but was: junit.framework.ComparisonFailure: expected:?000 but was: at org.apache.commons.codec.language.SoundexTest.testUsMappingOWithDiaeresis(SoundexTest.java:349) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testUsMappingEWithAcute(org.apache.commons.codec.language.SoundexTest): FAILED expected:?000 but was: junit.framework.ComparisonFailure: expected:?000 but was: at org.apache.commons.codec.language.SoundexTest.testUsMappingEWithAcute(SoundexTest.java:364) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-36) [codec] Support of Base 64 Encoding with URL and Filename Safe Alphabet
[ http://issues.apache.org/jira/browse/CODEC-36?page=all ] Henri Yandell updated CODEC-36: --- Bugzilla Id: (was: 31961) Fix Version: 1.4 Lining up for 1.4 - though I think we can punt it to 1.5 if nobody offers a patch and there's no itch to fix a minor. [codec] Support of Base 64 Encoding with URL and Filename Safe Alphabet --- Key: CODEC-36 URL: http://issues.apache.org/jira/browse/CODEC-36 Project: Commons Codec Type: Improvement Environment: Operating System: other Platform: All Reporter: Alain Gilbert Priority: Minor Fix For: 1.4 The default Base64 alphabet is not safe to use for URL query parameters since the '+' character is converted to a ' ' (space) when the parameter value is retrieved from the request (ServeltRequest.getParameter(String) and .getParameterValues(String)). It is possible to post-process the result of Base64.encodeBase64 but I would rather prefer to specify an alternate alphabet or call another method. Refer to http://www.ietf.org/rfc/rfc3548.txt section 4 for more information. Regards, Alain Gilbert -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CODEC-40) [codec] Patch to add crypto-compatible BigInteger encoding support to Base64
[ http://issues.apache.org/jira/browse/CODEC-40?page=all ] Henri Yandell updated CODEC-40: --- Bugzilla Id: (was: 38657) Fix Version: 1.4 Consider for 1.4. [codec] Patch to add crypto-compatible BigInteger encoding support to Base64 Key: CODEC-40 URL: http://issues.apache.org/jira/browse/CODEC-40 Project: Commons Codec Type: Improvement Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Chris Black Priority: Minor Fix For: 1.4 Attachments: addCryptoIntegerCoding There are crypto standards that require large integers for keys to be encoded in base64 with some special caveats (no sign bit, padding, etc). One of the standards that requires this is the w3c's XML-Signature standard. This patch adds this support along with junit tests. This code is taken from the Apache XML Security project's own Base64 class and changed to be more readable and add junit tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CODEC-48) [codec] Document how to print a QPDecoderStream with QCodec?
[ http://issues.apache.org/jira/browse/CODEC-48?page=comments#action_12421018 ] Henri Yandell commented on CODEC-48: Anything need to happen on this issue, or can it be resolved WONTFIX? [codec] Document how to print a QPDecoderStream with QCodec? Key: CODEC-48 URL: http://issues.apache.org/jira/browse/CODEC-48 Project: Commons Codec Type: Improvement Versions: 1.3 Environment: Operating System: other Platform: Other Reporter: Ralf Hauser Priority: Minor Attachments: mimeInput.eml when just using sun's implemention and for example accessing a mime body part of type text/x-vcard I get an object of type com.sun.mail.util.QPDecoderStream this seems to cause troubles for many people as per the above url. My stream claims to be 2k long, but when I do a reset, I get java.lang.NullPointerException at java.io.FilterInputStream.reset(FilterInputStream.java:204) at java.io.FilterInputStream.reset(FilterInputStream.java:204) I hope the apache implementation can help me here. If so, please document in http://jakarta.apache.org/commons/codec/apidocs/org/apache/commons/codec/net/QCodec.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SCXML-12) [scxml] if statement fails within another one
[ http://issues.apache.org/jira/browse/SCXML-12?page=all ] Rahul Akolkar resolved SCXML-12: Resolution: Invalid Assign To: Rahul Akolkar Sorry, my reply to your initial post [1] was incorrect. elseif ... / and else/ are partitions, not containers (note the bodyless tags), see the section on if from the latest WD [2]. The current processing is therefore in accordance with the WD, please re-open with a test case if you still think there is something to be addressed in this regard. (long URLs, may get fragmented; second one may become obsolete over time) [1] http://marc.theaimsgroup.com/?l=jakarta-commons-userm=115148557002292w=2 [2] http://www.w3.org/TR/scxml/#N109D0 [scxml] if statement fails within another one - Key: SCXML-12 URL: http://issues.apache.org/jira/browse/SCXML-12 Project: Commons SCXML Type: Bug Environment: all Reporter: Nestor Urquiza Assignee: Rahul Akolkar if statement fails within another one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
