[jira] Commented: (DBCP-191) [dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
[
https://issues.apache.org/jira/browse/DBCP-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514825
]
Michael Heuer commented on DBCP-191:
Attached is a patch that allows commons-dbcp and its tests to compile under
maven with jdk 1.6/JDBC 4.0.
A couple of potential gotchas:
- boolean isClosed() is now a public method on DelegatingStatement, was
protected
- several JDBC interfaces now implement java.sql.Wrapper, which contains
generics language features
and to-dos:
- questionable implemention of boolean Wrapper.isWrapperFor(Class? iface)
and T T Wrapper.unwrap(ClassT iface) in some classes (e.g. BasicDataSource
has a dataSource but is it considered a wrapper?)
- conditional compilation for /* JDBC_4_ANT_KEY... */ tags via the ant build
- create a separate svn branch?
[dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
--
Key: DBCP-191
URL: https://issues.apache.org/jira/browse/DBCP-191
Project: Commons Dbcp
Issue Type: Improvement
Environment: $ java -version
java version 1.6.0-rc
Java(TM) SE Runtime Environment (build 1.6.0-rc-b87)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b87, mixed mode, sharing)
$ java -version
java version 1.6.0-rc
Java(TM) SE Runtime Environment (build 1.6.0-rc-b89)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b89, mixed mode, sharing)
Reporter: Michael Heuer
Priority: Minor
Fix For: 1.3
Just a heads up, [dbcp] does not compile under the latest unreleased jdk 1.6
/ JDBC 4.0, even with maven.compile.source and maven.compile.target
properties set to something appropriate.
$ maven java:compile
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
java:prepare-filesystem:
[mkdir] Created dir: working/commons-dbcp/target/classes
java:compile:
[echo] Compiling to working/commons-dbcp/target/classes
[echo]
==
NOTE: Targetting JVM 1.6, classes
will not run on earlier JVMs
==
[javac] Compiling 39 source files to working/commons-dbcp/target/classes
working/commons-dbcp/src/java/org/apache/commons/dbcp/BasicDataSource.java:43:
org.apache.commons.dbcp.BasicDataSource is not abstract and does not
override abstract method
TcreateQueryObject(java.lang.ClassT,javax.sql.DataSource) in
javax.sql.DataSource
public class BasicDataSource implements DataSource {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java:
40: org.apache.commons.dbcp.cpdsadapter.ConnectionImpl is not abstract and
does not override abstract method
createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection
class ConnectionImpl implements Connection {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PooledConnectionImpl.java:42:
org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl is not abstract and
does not override abstract method
removeStatementEventListener(javax.sql.StatementEventListener) in
javax.sql.PooledConnection
class PooledConnectionImpl
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingConnection.java:50:
org.apache.commons.dbcp.DelegatingConnection is not abstract and does not
override abstract method createStruct(java.lang.String,java.lang.Object[]) in
java.sql.Connection
public class DelegatingConnection extends AbandonedTrace
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java:85:
org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS is not abstract and
does not override abstract method getQueryObjectGenerator() in
javax.sql.CommonDataSource
public class DriverAdapterCPDS
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:45:
org.apache.commons.dbcp.DelegatingStatement is not abstract and does not
override abstract method isPoolable() in java.sql.Statement
public class DelegatingStatement extends AbandonedTrace implements Statement {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:130:
isClosed() in org.apache.commons.dbcp.DelegatingStatement cannot implement
isClosed() in java.sql.Statement; attempting to assign weaker access
privileges; was public
protected boolean isClosed() {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingPreparedStatement.java:49:
org.apache.commons.dbcp.DelegatingPreparedStatement is not abstract and does
not override abstract method setCharacterStream(int,java.io.Reader,long) in
java.sql.PreparedStatement
public class DelegatingPreparedStatement
[jira] Updated: (DBCP-191) [dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
[
https://issues.apache.org/jira/browse/DBCP-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Heuer updated DBCP-191:
---
Attachment: patch.txt
patch against nightly for 23 July 2007, or in other words
$ svn co --revision '{2007-07-23}' ...
...
$ svn diff . patch.txt
[dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
--
Key: DBCP-191
URL: https://issues.apache.org/jira/browse/DBCP-191
Project: Commons Dbcp
Issue Type: Improvement
Environment: $ java -version
java version 1.6.0-rc
Java(TM) SE Runtime Environment (build 1.6.0-rc-b87)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b87, mixed mode, sharing)
$ java -version
java version 1.6.0-rc
Java(TM) SE Runtime Environment (build 1.6.0-rc-b89)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b89, mixed mode, sharing)
Reporter: Michael Heuer
Priority: Minor
Fix For: 1.3
Attachments: patch.txt
Just a heads up, [dbcp] does not compile under the latest unreleased jdk 1.6
/ JDBC 4.0, even with maven.compile.source and maven.compile.target
properties set to something appropriate.
$ maven java:compile
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
java:prepare-filesystem:
[mkdir] Created dir: working/commons-dbcp/target/classes
java:compile:
[echo] Compiling to working/commons-dbcp/target/classes
[echo]
==
NOTE: Targetting JVM 1.6, classes
will not run on earlier JVMs
==
[javac] Compiling 39 source files to working/commons-dbcp/target/classes
working/commons-dbcp/src/java/org/apache/commons/dbcp/BasicDataSource.java:43:
org.apache.commons.dbcp.BasicDataSource is not abstract and does not
override abstract method
TcreateQueryObject(java.lang.ClassT,javax.sql.DataSource) in
javax.sql.DataSource
public class BasicDataSource implements DataSource {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java:
40: org.apache.commons.dbcp.cpdsadapter.ConnectionImpl is not abstract and
does not override abstract method
createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection
class ConnectionImpl implements Connection {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PooledConnectionImpl.java:42:
org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl is not abstract and
does not override abstract method
removeStatementEventListener(javax.sql.StatementEventListener) in
javax.sql.PooledConnection
class PooledConnectionImpl
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingConnection.java:50:
org.apache.commons.dbcp.DelegatingConnection is not abstract and does not
override abstract method createStruct(java.lang.String,java.lang.Object[]) in
java.sql.Connection
public class DelegatingConnection extends AbandonedTrace
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java:85:
org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS is not abstract and
does not override abstract method getQueryObjectGenerator() in
javax.sql.CommonDataSource
public class DriverAdapterCPDS
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:45:
org.apache.commons.dbcp.DelegatingStatement is not abstract and does not
override abstract method isPoolable() in java.sql.Statement
public class DelegatingStatement extends AbandonedTrace implements Statement {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:130:
isClosed() in org.apache.commons.dbcp.DelegatingStatement cannot implement
isClosed() in java.sql.Statement; attempting to assign weaker access
privileges; was public
protected boolean isClosed() {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingPreparedStatement.java:49:
org.apache.commons.dbcp.DelegatingPreparedStatement is not abstract and does
not override abstract method setCharacterStream(int,java.io.Reader,long) in
java.sql.PreparedStatement
public class DelegatingPreparedStatement extends DelegatingStatement
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/PoolablePreparedStatement.java:40:
org.apache.commons.dbcp.PoolablePreparedStatement is not abstract and does
not override abstract method setCharacterStream(int,java.io.Reader,long) in
java.sql.PreparedStatement
public class PoolablePreparedStatement extends DelegatingPreparedStatement
implements PreparedStatement {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter
[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508232
]
Michael Heuer commented on SCXML-47:
the same problem exists in AbstractStateMachine itself, see SCXML-48
Provide a state machine support class to allow for delegation.
--
Key: SCXML-47
URL: https://issues.apache.org/jira/browse/SCXML-47
Project: Commons SCXML
Issue Type: Improvement
Affects Versions: 0.6
Reporter: Michael Heuer
Priority: Minor
Fix For: 0.7
Attachments: additional-tests.tar.gz, state-machine-support-src.tar.gz
This is not completely thought out yet, but if folks like the idea I might
persue it further.
I would like to use AbstractStateMachine but cannot extend from it:
class B extends A /*, AbstractStateMachine */ {
// copy source from AbstractStateMachine here
}
I propose here a StateMachineSupport class that provides for use by
subclassing and for use by delegation. The constructors are a little messy,
but in the end I have
public class StateMachineSupport {
// use by subclassing
protected StateMachineSupport(...) {
}
// use by delegation
public StateMachineSupport(Object delegator, ...) {
}
// ... methods from AbstractStateMachine
}
public abstract class AbstractStateMachine extends StateMachineSupport {
protected AbstractStateMachine(...) {
super(...);
}
}
// use by subclassing
class ConcreteStateMachine extends AbstractStateMachine {
ConcreteStateMachine() {
super(...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
// use by delegation
class DelegatingStateMachine extends SomethingElse {
StateMachineSupport delegate;
DelegatingStateMachine() {
delegate = new StateMachineSupport(this, ...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
StateMachineSupport.java, AbstractStateMachine2.java,
StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCXML-48) Cannot create more than one subclass of AbstractStateMachine
Cannot create more than one subclass of AbstractStateMachine
Key: SCXML-48
URL: https://issues.apache.org/jira/browse/SCXML-48
Project: Commons SCXML
Issue Type: Bug
Reporter: Michael Heuer
Attachments: abstract-state-machine-test-src.tar.gz
Similar to the issue described in SCXML-47, the following test case will fail:
public void testMoreThanOneScxmlDocument() throws Exception {
URL fooScxmlDocument = getClass().getResource(foo.xml);
URL barScxmlDocument = getClass().getResource(bar.xml);
Foo foo = new Foo(fooScxmlDocument);
Bar bar = new Bar(barScxmlDocument);
assertTrue(fooCalled);
// bar's initialstate bar never called, since bar's
AbstractStateMachine has
// static reference to stateMachine for foo.xml
assertTrue(barCalled);
}
private class Foo extends AbstractStateMachine {
public Foo(final URL scxmlDocument) {
super(scxmlDocument);
}
public void foo() {
fooCalled = true;
}
}
private class Bar extends AbstractStateMachine {
public Bar(final URL scxmlDocument) {
super(scxmlDocument);
}
public void bar() {
barCalled = true;
}
}
with simple SCXML files
foo.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 initialstate=foo
state id=foo/
/scxml
bar.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 initialstate=bar
state id=bar/
/scxml
[junit] Running org.apache.commons.scxml.env.EnvTestSuite
org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
java.lang.NoSuchMethodException:
org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
at java.lang.Class.getDeclaredMethod(Class.java:1937)
at
org.apache.commons.scxml.env.AbstractStateMachine.invoke(AbstractStateMachine.java:212)
at
org.apache.commons.scxml.env.AbstractStateMachine$EntryListener.onEntry(AbstractStateMachine.java:269)
Testsuite: org.apache.commons.scxml.env.EnvTestSuite
Tests run: 21, Failures: 2, Errors: 0, Time elapsed: 0.391 sec
Testcase:
testMoreThanOneScxmlDocument(org.apache.commons.scxml.env.AbstractStateMachineTest):
FAILED
junit.framework.AssertionFailedError
at
org.apache.commons.scxml.env.AbstractStateMachineTest.testMoreThanOneScxmlDocument(AbstractStateMachineTest.java:60)
Testcase: testStopWatch(org.apache.commons.scxml.env.StopWatchTest):FAILED
expected:reset but was:foo
junit.framework.ComparisonFailure: expected:reset but was:foo
at
org.apache.commons.scxml.env.StopWatchTest.testStopWatch(StopWatchTest.java:56)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-48) Cannot create more than one subclass of AbstractStateMachine
[
https://issues.apache.org/jira/browse/SCXML-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Heuer updated SCXML-48:
---
Attachment: abstract-state-machine-test-src.tar.gz
unit test for AbstractStateMachine as described
Cannot create more than one subclass of AbstractStateMachine
Key: SCXML-48
URL: https://issues.apache.org/jira/browse/SCXML-48
Project: Commons SCXML
Issue Type: Bug
Reporter: Michael Heuer
Attachments: abstract-state-machine-test-src.tar.gz
Similar to the issue described in SCXML-47, the following test case will fail:
public void testMoreThanOneScxmlDocument() throws Exception {
URL fooScxmlDocument = getClass().getResource(foo.xml);
URL barScxmlDocument = getClass().getResource(bar.xml);
Foo foo = new Foo(fooScxmlDocument);
Bar bar = new Bar(barScxmlDocument);
assertTrue(fooCalled);
// bar's initialstate bar never called, since bar's
AbstractStateMachine has
// static reference to stateMachine for foo.xml
assertTrue(barCalled);
}
private class Foo extends AbstractStateMachine {
public Foo(final URL scxmlDocument) {
super(scxmlDocument);
}
public void foo() {
fooCalled = true;
}
}
private class Bar extends AbstractStateMachine {
public Bar(final URL scxmlDocument) {
super(scxmlDocument);
}
public void bar() {
barCalled = true;
}
}
with simple SCXML files
foo.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0
initialstate=foo
state id=foo/
/scxml
bar.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0
initialstate=bar
state id=bar/
/scxml
[junit] Running org.apache.commons.scxml.env.EnvTestSuite
org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
java.lang.NoSuchMethodException:
org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
at java.lang.Class.getDeclaredMethod(Class.java:1937)
at
org.apache.commons.scxml.env.AbstractStateMachine.invoke(AbstractStateMachine.java:212)
at
org.apache.commons.scxml.env.AbstractStateMachine$EntryListener.onEntry(AbstractStateMachine.java:269)
Testsuite: org.apache.commons.scxml.env.EnvTestSuite
Tests run: 21, Failures: 2, Errors: 0, Time elapsed: 0.391 sec
Testcase:
testMoreThanOneScxmlDocument(org.apache.commons.scxml.env.AbstractStateMachineTest):
FAILED
junit.framework.AssertionFailedError
at
org.apache.commons.scxml.env.AbstractStateMachineTest.testMoreThanOneScxmlDocument(AbstractStateMachineTest.java:60)
Testcase: testStopWatch(org.apache.commons.scxml.env.StopWatchTest):FAILED
expected:reset but was:foo
junit.framework.ComparisonFailure: expected:reset but was:foo
at
org.apache.commons.scxml.env.StopWatchTest.testStopWatch(StopWatchTest.java:56)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Heuer updated SCXML-47:
---
Attachment: additional-tests.tar.gz
failing unit test as described
Provide a state machine support class to allow for delegation.
--
Key: SCXML-47
URL: https://issues.apache.org/jira/browse/SCXML-47
Project: Commons SCXML
Issue Type: Improvement
Affects Versions: 0.6
Reporter: Michael Heuer
Priority: Minor
Fix For: 0.7
Attachments: additional-tests.tar.gz, state-machine-support-src.tar.gz
This is not completely thought out yet, but if folks like the idea I might
persue it further.
I would like to use AbstractStateMachine but cannot extend from it:
class B extends A /*, AbstractStateMachine */ {
// copy source from AbstractStateMachine here
}
I propose here a StateMachineSupport class that provides for use by
subclassing and for use by delegation. The constructors are a little messy,
but in the end I have
public class StateMachineSupport {
// use by subclassing
protected StateMachineSupport(...) {
}
// use by delegation
public StateMachineSupport(Object delegator, ...) {
}
// ... methods from AbstractStateMachine
}
public abstract class AbstractStateMachine extends StateMachineSupport {
protected AbstractStateMachine(...) {
super(...);
}
}
// use by subclassing
class ConcreteStateMachine extends AbstractStateMachine {
ConcreteStateMachine() {
super(...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
// use by delegation
class DelegatingStateMachine extends SomethingElse {
StateMachineSupport delegate;
DelegatingStateMachine() {
delegate = new StateMachineSupport(this, ...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
StateMachineSupport.java, AbstractStateMachine2.java,
StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507958
]
Michael Heuer commented on SCXML-47:
I have discovered a problem with StateMachineSupport as designed, due to its
static reference to stateMachine.
The following test case will fail:
public void testMoreThanOneScxmlDocument() throws Exception {
URL fooScxmlDocument = getClass().getResource(foo.xml);
URL barScxmlDocument = getClass().getResource(bar.xml);
Foo foo = new Foo(fooScxmlDocument);
Bar bar = new Bar(barScxmlDocument);
assertTrue(fooCalled);
// bar's initialstate bar never called, since bar's
StateMachineSupport has
//static reference to stateMachine for foo.xml
assertTrue(barCalled);
}
private class Foo {
private StateMachineSupport delegate;
public Foo(final URL scxmlDocument) {
delegate = new StateMachineSupport(this, scxmlDocument);
}
public void foo() {
fooCalled = true;
}
}
private class Bar {
private StateMachineSupport delegate;
public Bar(final URL scxmlDocument) {
delegate = new StateMachineSupport(this, scxmlDocument);
}
public void bar() {
barCalled = true;
}
}
with simple SCXML files
foo.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 initialstate=foo
state id=foo/
/scxml
bar.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 initialstate=bar
state id=bar/
/scxml
java.lang.NoSuchMethodException:
org.apache.commons.scxml.env.StateMachineSupportTest$Bar.foo()
at java.lang.Class.getDeclaredMethod(Class.java:1937)
at
org.apache.commons.scxml.env.StateMachineSupport.invoke(StateMachineSupport.java:249)
I believe the way to make this work is to have StateMachineSupport accept a
reference to an instance of SCXML in its constructor or otherwise and to not
reuse StateMachineSupport in AbstractStateMachine.
Sorry for not providing better unit tests in the first place.
Provide a state machine support class to allow for delegation.
--
Key: SCXML-47
URL: https://issues.apache.org/jira/browse/SCXML-47
Project: Commons SCXML
Issue Type: Improvement
Affects Versions: 0.6
Reporter: Michael Heuer
Priority: Minor
Fix For: 0.7
Attachments: additional-tests.tar.gz, state-machine-support-src.tar.gz
This is not completely thought out yet, but if folks like the idea I might
persue it further.
I would like to use AbstractStateMachine but cannot extend from it:
class B extends A /*, AbstractStateMachine */ {
// copy source from AbstractStateMachine here
}
I propose here a StateMachineSupport class that provides for use by
subclassing and for use by delegation. The constructors are a little messy,
but in the end I have
public class StateMachineSupport {
// use by subclassing
protected StateMachineSupport(...) {
}
// use by delegation
public StateMachineSupport(Object delegator, ...) {
}
// ... methods from AbstractStateMachine
}
public abstract class AbstractStateMachine extends StateMachineSupport {
protected AbstractStateMachine(...) {
super(...);
}
}
// use by subclassing
class ConcreteStateMachine extends AbstractStateMachine {
ConcreteStateMachine() {
super(...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
// use by delegation
class DelegatingStateMachine extends SomethingElse {
StateMachineSupport delegate;
DelegatingStateMachine() {
delegate = new StateMachineSupport(this, ...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
StateMachineSupport.java, AbstractStateMachine2.java,
StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505864
]
Michael Heuer commented on SCXML-47:
ICLA faxed yesterday; original sent in the mail today
Provide a state machine support class to allow for delegation.
--
Key: SCXML-47
URL: https://issues.apache.org/jira/browse/SCXML-47
Project: Commons SCXML
Issue Type: Improvement
Affects Versions: 0.6
Reporter: Michael Heuer
Priority: Minor
Fix For: 0.7
Attachments: state-machine-support-src.tar.gz
This is not completely thought out yet, but if folks like the idea I might
persue it further.
I would like to use AbstractStateMachine but cannot extend from it:
class B extends A /*, AbstractStateMachine */ {
// copy source from AbstractStateMachine here
}
I propose here a StateMachineSupport class that provides for use by
subclassing and for use by delegation. The constructors are a little messy,
but in the end I have
public class StateMachineSupport {
// use by subclassing
protected StateMachineSupport(...) {
}
// use by delegation
public StateMachineSupport(Object delegator, ...) {
}
// ... methods from AbstractStateMachine
}
public abstract class AbstractStateMachine extends StateMachineSupport {
protected AbstractStateMachine(...) {
super(...);
}
}
// use by subclassing
class ConcreteStateMachine extends AbstractStateMachine {
ConcreteStateMachine() {
super(...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
// use by delegation
class DelegatingStateMachine extends SomethingElse {
StateMachineSupport delegate;
DelegatingStateMachine() {
delegate = new StateMachineSupport(this, ...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
StateMachineSupport.java, AbstractStateMachine2.java,
StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-46) Provide a SCXMLListener abstract adapter class.
[ https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Heuer updated SCXML-46: --- Attachment: SCXMLAdapterTest.java Provide a SCXMLListener abstract adapter class. --- Key: SCXML-46 URL: https://issues.apache.org/jira/browse/SCXML-46 Project: Commons SCXML Issue Type: Improvement Reporter: Michael Heuer Priority: Trivial Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java Might also want to add + suite.addTest(SCXMLAdapterTest.suite()); to SCXMLTestSuite.java, line 54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-46) Provide a SCXMLListener abstract adapter class.
[ https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Heuer updated SCXML-46: --- Attachment: SCXMLAdapter.java Provide a SCXMLListener abstract adapter class. --- Key: SCXML-46 URL: https://issues.apache.org/jira/browse/SCXML-46 Project: Commons SCXML Issue Type: Improvement Reporter: Michael Heuer Priority: Trivial Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java Might also want to add + suite.addTest(SCXMLAdapterTest.suite()); to SCXMLTestSuite.java, line 54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCXML-46) Provide a SCXMLListener abstract adapter class.
Provide a SCXMLListener abstract adapter class. --- Key: SCXML-46 URL: https://issues.apache.org/jira/browse/SCXML-46 Project: Commons SCXML Issue Type: Improvement Reporter: Michael Heuer Priority: Trivial Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java Might also want to add + suite.addTest(SCXMLAdapterTest.suite()); to SCXMLTestSuite.java, line 54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-244) Proposal to support generic multi-key maps with keys of different types
[ https://issues.apache.org/jira/browse/COLLECTIONS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505370 ] Michael Heuer commented on COLLECTIONS-244: --- Fair enough, what you describe is unwieldy. Implementing these interfaces using the decorator pattern as done previously might not necessarily make the most sense. Most often in my use cases I am working with large sparse n-dimensional matrices, where keys come from different objects. Providing an API for these matrices as multi-maps with ...MapIterator and get(key..)/put(key...) methods allows clients to access the values without creating new composite key and/or entry objects with each call. Proposal to support generic multi-key maps with keys of different types --- Key: COLLECTIONS-244 URL: https://issues.apache.org/jira/browse/COLLECTIONS-244 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: Generics Reporter: Michael Heuer Priority: Minor Attachments: multi-map.tar.gz MultiKeyMap as designed can only accept keys of the same type, if made to support generics, i.e. MultiKeyMapMultiKeyString,Integer map = ...; map.put(foo, bar, 10); // not possible //MultiKeyMapMultiKeyString,Integer,Double map = ...; Attached is a proposal that may support multi-key maps with keys of different types. I do not believe varying numbers of typed keys can be supported in a single interface, thus this proposal includes BinaryKeyK1,K2 BinaryKeyMapK1,K2,V extends MapBinaryKeyK1,K2,V TertiaryKeyK1,K2,K3 TertiaryKeyMapK1,K2,K3,V extends MapTertiaryKeyK1,K2,K3,V QuaternaryKeyK1,K2,K3,K4 QuaternaryKeyMapK1,K2,K3,K4,V extends MapQuaternaryKeyK1,K2,K3,K4,V To prevent unnecessary object creation, I also propose to support MapIterator-style iterators: BinaryKeyMapIteratorK1,K2,V extends IteratorV TertiaryKeyMapIteratorK1,K2,K3,V extends IteratorV QuaternaryKeyMapIteratorK1,K2,K3,K4,V extends IteratorV Current multi-map MapIterator support is implemented as IteratorK1 but I find that IteratorV makes more sense here. It is not possible to support MapIteratorK,V without object creation, e.g. MapIteratorBinaryKeyK1,K2,V must create BinaryKey objects for each call to next(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCXML-47) Provide a state machine support class to allow for delegation.
Provide a state machine support class to allow for delegation.
--
Key: SCXML-47
URL: https://issues.apache.org/jira/browse/SCXML-47
Project: Commons SCXML
Issue Type: Improvement
Reporter: Michael Heuer
Priority: Minor
This is not completely thought out yet, but if folks like the idea I might
persue it further.
I would like to use AbstractStateMachine but cannot extend from it:
class B extends A /*, AbstractStateMachine */ {
// copy source from AbstractStateMachine here
}
I propose here a StateMachineSupport class that provides for use by subclassing
and for use by delegation. The constructors are a little messy, but in the end
I have
public class StateMachineSupport {
// use by subclassing
protected StateMachineSupport(...) {
}
// use by delegation
public StateMachineSupport(Object delegator, ...) {
}
// ... methods from AbstractStateMachine
}
public abstract class AbstractStateMachine extends StateMachineSupport {
protected AbstractStateMachine(...) {
super(...);
}
}
// use by subclassing
class ConcreteStateMachine extends AbstractStateMachine {
ConcreteStateMachine() {
super(...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
// use by delegation
class DelegatingStateMachine extends SomethingElse {
StateMachineSupport delegate;
DelegatingStateMachine() {
delegate = new StateMachineSupport(this, ...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
StateMachineSupport.java, AbstractStateMachine2.java,
StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Heuer updated SCXML-47:
---
Attachment: state-machine-support-src.tar.gz
Provide a state machine support class to allow for delegation.
--
Key: SCXML-47
URL: https://issues.apache.org/jira/browse/SCXML-47
Project: Commons SCXML
Issue Type: Improvement
Reporter: Michael Heuer
Priority: Minor
Attachments: state-machine-support-src.tar.gz
This is not completely thought out yet, but if folks like the idea I might
persue it further.
I would like to use AbstractStateMachine but cannot extend from it:
class B extends A /*, AbstractStateMachine */ {
// copy source from AbstractStateMachine here
}
I propose here a StateMachineSupport class that provides for use by
subclassing and for use by delegation. The constructors are a little messy,
but in the end I have
public class StateMachineSupport {
// use by subclassing
protected StateMachineSupport(...) {
}
// use by delegation
public StateMachineSupport(Object delegator, ...) {
}
// ... methods from AbstractStateMachine
}
public abstract class AbstractStateMachine extends StateMachineSupport {
protected AbstractStateMachine(...) {
super(...);
}
}
// use by subclassing
class ConcreteStateMachine extends AbstractStateMachine {
ConcreteStateMachine() {
super(...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
// use by delegation
class DelegatingStateMachine extends SomethingElse {
StateMachineSupport delegate;
DelegatingStateMachine() {
delegate = new StateMachineSupport(this, ...stopwatch.xml);
}
public void reset() { ... }
public void running() { ... }
public void paused() { ... }
public void stopped() { ... }
}
StateMachineSupport.java, AbstractStateMachine2.java,
StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[collections] or [beanutils] BeanComparatorChain
Hello, Might there be interest in a BeanComparatorChain, that is a Comparator implementation that maintains an o.a.c.collections.c.ComparatorChain of o.a.c.beanutils.BeanComparators? class BeanComparatorChainT implements ComparatorT BeanComparatorChain(); BeanComparatorChain(String[]); BeanComparatorChain(ListString); int compare(T, T); ListString getProperties(); void addProperty(String); void removeProperty(String); void moveToFront(String); void moveToBack(String); void moveForward(String); void moveBack(String); void swap(String, String); boolean isAscending(String); boolean isDescending(String); void setAscending(String); void setDescending(String); void toggle(String); where the Strings are beanutils property expressions. I am asking before submitting to JIRA, since I may need to re-license it to do so. Thanks, michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-327) Overview doc for version 2.3 still specifies version 2.2
Overview doc for version 2.3 still specifies version 2.2 Key: LANG-327 URL: https://issues.apache.org/jira/browse/LANG-327 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Reporter: Michael Heuer Priority: Minor The link to the current release javadocs http://jakarta.apache.org/commons/lang/api-release/index.html reads Lang 2.3 API This document is the API specification for the Apache Jakarta Commons Lang Library, version 2.2. Appears as if src/java/org/apache/commons/lang/overview.html was not updated for the 2.3 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons DBCP 1.2.2 (reprise)
On Sun, 25 Mar 2007, Phil Steitz wrote: I have fixed the JRockit test compatibility issue raised during the first DBCP 1.2.2 release vote and would like to kick off a new release vote based on RC3, with links provided below. Since RC2, the following changes have been made; * Fixed JRockit test compatibility issue (tested with Linux versions of jrockit-R27.1.0-jdk1.5.0_08, jrockit-R27.1.0-jdk1.4.2_12, and jrockit-jdk1.5.0_06) * Added a note to release notes and README calling out the lack of JDK 1.6 / JDBC 4.0 support * Fixed 'Built-By' manifest attribute The release zips/tarballs are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/ Please note that, despite the release names, these distributions are *not* official apache releases, so should be used only for inspection/verification during the duration of this VOTE. Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/RELEASE-NOTES.txt http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/docs/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/docs/ The svn tag is DBCP_1_2_2-RC3. Assuming a successful VOTE, I will copy the tag to DBCP_1_2_2 and move the distributions above to the mirrors. Votes, please. The vote will close end of day (GMT) 28-March-2007. Thanks! Phil Should there be a footnote in configuration.html describing the potential deadlock if minIdle is set to 0 [#DBCP-44]? Non-binding +1 otherwise. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-244) Proposal to support generic multi-key maps with keys of different types
Proposal to support generic multi-key maps with keys of different types --- Key: COLLECTIONS-244 URL: https://issues.apache.org/jira/browse/COLLECTIONS-244 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: Generics Reporter: Michael Heuer Priority: Minor Attachments: multi-map.tar.gz MultiKeyMap as designed can only accept keys of the same type, if made to support generics, i.e. MultiKeyMapMultiKeyString,Integer map = ...; map.put(foo, bar, 10); // not possible //MultiKeyMapMultiKeyString,Integer,Double map = ...; Attached is a proposal that may support multi-key maps with keys of different types. I do not believe varying numbers of typed keys can be supported in a single interface, thus this proposal includes BinaryKeyK1,K2 BinaryKeyMapK1,K2,V extends MapBinaryKeyK1,K2,V TertiaryKeyK1,K2,K3 TertiaryKeyMapK1,K2,K3,V extends MapTertiaryKeyK1,K2,K3,V QuaternaryKeyK1,K2,K3,K4 QuaternaryKeyMapK1,K2,K3,K4,V extends MapQuaternaryKeyK1,K2,K3,K4,V To prevent unnecessary object creation, I also propose to support MapIterator-style iterators: BinaryKeyMapIteratorK1,K2,V extends IteratorV TertiaryKeyMapIteratorK1,K2,K3,V extends IteratorV QuaternaryKeyMapIteratorK1,K2,K3,K4,V extends IteratorV Current multi-map MapIterator support is implemented as IteratorK1 but I find that IteratorV makes more sense here. It is not possible to support MapIteratorK,V without object creation, e.g. MapIteratorBinaryKeyK1,K2,V must create BinaryKey objects for each call to next(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COLLECTIONS-244) Proposal to support generic multi-key maps with keys of different types
[ https://issues.apache.org/jira/browse/COLLECTIONS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Heuer updated COLLECTIONS-244: -- Attachment: multi-map.tar.gz Proposal to support generic multi-key maps with keys of different types --- Key: COLLECTIONS-244 URL: https://issues.apache.org/jira/browse/COLLECTIONS-244 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: Generics Reporter: Michael Heuer Priority: Minor Attachments: multi-map.tar.gz MultiKeyMap as designed can only accept keys of the same type, if made to support generics, i.e. MultiKeyMapMultiKeyString,Integer map = ...; map.put(foo, bar, 10); // not possible //MultiKeyMapMultiKeyString,Integer,Double map = ...; Attached is a proposal that may support multi-key maps with keys of different types. I do not believe varying numbers of typed keys can be supported in a single interface, thus this proposal includes BinaryKeyK1,K2 BinaryKeyMapK1,K2,V extends MapBinaryKeyK1,K2,V TertiaryKeyK1,K2,K3 TertiaryKeyMapK1,K2,K3,V extends MapTertiaryKeyK1,K2,K3,V QuaternaryKeyK1,K2,K3,K4 QuaternaryKeyMapK1,K2,K3,K4,V extends MapQuaternaryKeyK1,K2,K3,K4,V To prevent unnecessary object creation, I also propose to support MapIterator-style iterators: BinaryKeyMapIteratorK1,K2,V extends IteratorV TertiaryKeyMapIteratorK1,K2,K3,V extends IteratorV QuaternaryKeyMapIteratorK1,K2,K3,K4,V extends IteratorV Current multi-map MapIterator support is implemented as IteratorK1 but I find that IteratorV makes more sense here. It is not possible to support MapIteratorK,V without object creation, e.g. MapIteratorBinaryKeyK1,K2,V must create BinaryKey objects for each call to next(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status of the Sandbox?
J?rg Schaible wrote: Henri Yandell wrote on Monday, February 19, 2007 5:58 AM: I'm interested in knowing where things are with each of the non-dormant sandboxes. ie) Convince me why I shouldn't be proposing that a component be moved to dormant. -- [snip] id - J?rg seems to be working on this. Any plans J?rg? Due to lack of time currently in maintaining mode i.e. I am anwering questions, but it is on my TODO list ... - J?rg When you have time might you be able to take a look at JIRA issues SANDBOX-24, SANDBOX-68, and SANBOX-146? They're all somewhat stuck waiting for a second (or third) opinion. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Lang 2.3 (RC3)
MacOSX 10.4.8 G4, ant 1.6.5, maven 1.0.2 jdk 1.3.1_16 ant ok, maven fails (as below) jdk 1.4.2_09 ant maven jdk 1.4.2_12 ant maven jdk 1.5.0_06 ant maven jdk 1.5.0_07 ant maven jdk 1.6.0-dp ant maven michael On Sun, 11 Feb 2007, Gary Gregory wrote: +1. Tested with: - Windows XP SP2 + current patches - Ant 1.6.5: ant clean dist test - Maven 1.0.2: maven clean site:generate - Sun Java 1.3.1_15 :ant ok - Sun Java 1.4.2_13: ant maven - Sun Java 1.5.0_10: ant maven - Sun Java 1.5.0_11: ant maven - Sun Java 1.6.0: ant ok Maven failures: - Sun Java 1.3.1_15 :ant ok, maven fails with a class file version 48.0 issue) - Sun Java 1.6.0: ank ok, maven fails with: xdoc:i18n-validation: [echo] Validation of the locale entries BUILD FAILED File.. C:\Documents and Settings\ggregory\.maven\cache\maven-xdoc-plugin-1.10\plugin.jelly Element... j:arg Line.. 666 Column 70 [Ljava.lang.Object; Total time: 5 minutes 26 seconds Finished at: Sun Feb 11 06:58:32 PST 2007 Thank you, Gary -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 12:51 PM To: Jakarta Commons Developers List Subject: [VOTE] Lang 2.3 (RC3) Here's the 3rd release candidate for Lang 2.3: http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc3/ Clirr, Jardiff + Site included. [ ] +1 [ ] -1 Difference from RC2 is that the sources and javadoc jars now have LICENSE/NOTICE files and the test for LANG-312 is commented out as it's still an open bug (and fails on some platforms). The pom.xml is NOT in the src bundle, because I forgot and I don't want to do all that again :) I'll make that change in svn now so it'll be in a future RC if one happens. 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]
[jira] Commented: (DBUTILS-27) [dbutils] QueryRunner.count(String, ...) methods for SELECT COUNT(...) sql
[
http://issues.apache.org/jira/browse/DBUTILS-27?page=comments#action_12447121 ]
Michael Heuer commented on DBUTILS-27:
--
Feel free to mark this as WONTFIX. With the 1.1 release, the method
QueryRunner.prepareConnection() is protected, so I can just include a subclass
of QueryRunner in my own code.
[dbutils] QueryRunner.count(String, ...) methods for SELECT COUNT(...) sql
---
Key: DBUTILS-27
URL: http://issues.apache.org/jira/browse/DBUTILS-27
Project: Commons DbUtils
Issue Type: Improvement
Environment: Operating System: All
Platform: All
Reporter: Michael Heuer
Priority: Minor
Fix For: 1.2
Attachments: count.java, count.java, diff.txt
Found that I was repeating the same bit of code over and over again when
executing SELECT COUNT(...)
sql queries with QueryRunner, so I thought I might code this up into a set of
static methods for possible
inclusion in commons-dbutils.
e.g.
Connection conn;
String sql = select count(*) from tablename where column0 = ? and column1 =
?;
from:
int count = 0;
Object result = QueryRunner.query(conn, sql, new Object[] { foo, bar },
new ScalarHandler());
if (result != null) {
count = ((Integer) result).intValue();
}
to:
int count = QueryRunner.count(conn, sql, new Object[] { foo, bar });
See attached diff.txt.
--
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: [collections] Generics the collection subpackage
On Sat, 28 Oct 2006, Stephen Colebourne wrote: First analysis of the collection subpackage of [collections] for the generics branch. - BoundedCollection should be deleted/renamed to Bounded new Bounded interface would not implement Collection, allowing it to be implemented by Maps as well as Collections - UnmodifiableBoundedCollection should be deleted Just use the isFull/maxSize methods on CollectionUtils or similar - AbstractSerializedCollectionDecorator should be deleted Serialization can now be rolled up into the base decorator This simplifies a lot of code It wasn't done originally due to back-compat - TransformedCollection will need some thinking about to generify, as a transformer can change object types - Consider adding a Decorator interface This would provide a single method decorated() that obtains the collection that has been decorated. Whilst useful, this is also potentially dangerous exposure of state. - Consider adding a Container interface This would be a base super interface for Collection and Map (but obviously we can't hack the JDK. - Consider whether UnmodifiableCollection should be deleted as it duplicates the JDK. Stephen Might I propose - Consider deprecating or removing functor interfaces from collections in favor of those in [functor], or - Rename functor interfaces and update method signatures in collections to match those in [functor], specifically Closure -- Procedure, Transformer -- Function or Functor, Factory -- Generator - Add TertiaryXxx, QuaternaryXxx, and NaryXxx (using varargs, e.g. E xxx(E... e)) interfaces michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-197) Incorrect parameter descriptions for maxIdle and minIdle, at http://jakarta.apache.org/commons/dbcp/configuration.html
Incorrect parameter descriptions for maxIdle and minIdle, at http://jakarta.apache.org/commons/dbcp/configuration.html -- Key: DBCP-197 URL: http://issues.apache.org/jira/browse/DBCP-197 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Reporter: Michael Heuer Priority: Minor Attachments: diff.txt The parameter descriptions for maxIdle and minIdle incorrectly refer to active connections: Parameter Default Description initialSize 0 The initial number of connections that are created when the pool is started. maxActive 8 The maximum number of active connections that can be allocated from this pool at the same time, or negative for no limit. maxIdle 8 The maximum number of active connections that can remain idle in the pool, without extra ones being released, or zero for no limit. minIdle 0 The minimum number of active connections that can remain idle in the pool, without extra ones being created, or zero to create none. A connection cannot be both active and idle by definition. svn diff attached. -- 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: (LANG-270) [lang] minor javadoc improvements for StringUtils.stripXxx() methods
[lang] minor javadoc improvements for StringUtils.stripXxx() methods Key: LANG-270 URL: http://issues.apache.org/jira/browse/LANG-270 Project: Commons Lang Type: Improvement Versions: 2.1 Reporter: Michael Heuer Priority: Trivial Attachments: diff.txt Minor javadoc improvements for StringUtils.stripToNull(String) and StringUtils.stripToEmpty(String) methods; see attached svn diff. -- 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: (LANG-270) [lang] minor javadoc improvements for StringUtils.stripXxx() methods
[ http://issues.apache.org/jira/browse/LANG-270?page=all ] Michael Heuer updated LANG-270: --- Attachment: diff.txt [lang] minor javadoc improvements for StringUtils.stripXxx() methods Key: LANG-270 URL: http://issues.apache.org/jira/browse/LANG-270 Project: Commons Lang Type: Improvement Versions: 2.1 Reporter: Michael Heuer Priority: Trivial Attachments: diff.txt Minor javadoc improvements for StringUtils.stripToNull(String) and StringUtils.stripToEmpty(String) methods; see attached svn diff. -- 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: (DBCP-191) [dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
[dbcp] does not compile under the latest unreleased jdk 1.6 / JDBC 4.0
--
Key: DBCP-191
URL: http://issues.apache.org/jira/browse/DBCP-191
Project: Commons Dbcp
Type: Improvement
Environment: $ java -version
java version 1.6.0-rc
Java(TM) SE Runtime Environment (build 1.6.0-rc-b87)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b87, mixed mode, sharing)
$ java -version
java version 1.6.0-rc
Java(TM) SE Runtime Environment (build 1.6.0-rc-b89)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b89, mixed mode, sharing)
Reporter: Michael Heuer
Priority: Minor
Just a heads up, [dbcp] does not compile under the latest unreleased jdk 1.6 /
JDBC 4.0, even with maven.compile.source and maven.compile.target properties
set to something appropriate.
$ maven java:compile
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
java:prepare-filesystem:
[mkdir] Created dir: working/commons-dbcp/target/classes
java:compile:
[echo] Compiling to working/commons-dbcp/target/classes
[echo]
==
NOTE: Targetting JVM 1.6, classes
will not run on earlier JVMs
==
[javac] Compiling 39 source files to working/commons-dbcp/target/classes
working/commons-dbcp/src/java/org/apache/commons/dbcp/BasicDataSource.java:43:
org.apache.commons.dbcp.BasicDataSource is not abstract and does not override
abstract method TcreateQueryObject(java.lang.ClassT,javax.sql.DataSource)
in javax.sql.DataSource
public class BasicDataSource implements DataSource {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/ConnectionImpl.java:
40: org.apache.commons.dbcp.cpdsadapter.ConnectionImpl is not abstract and
does not override abstract method
createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection
class ConnectionImpl implements Connection {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PooledConnectionImpl.java:42:
org.apache.commons.dbcp.cpdsadapter.PooledConnectionImpl is not abstract and
does not override abstract method
removeStatementEventListener(javax.sql.StatementEventListener) in
javax.sql.PooledConnection
class PooledConnectionImpl
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingConnection.java:50:
org.apache.commons.dbcp.DelegatingConnection is not abstract and does not
override abstract method createStruct(java.lang.String,java.lang.Object[]) in
java.sql.Connection
public class DelegatingConnection extends AbandonedTrace
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java:85:
org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS is not abstract and does
not override abstract method getQueryObjectGenerator() in
javax.sql.CommonDataSource
public class DriverAdapterCPDS
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:45:
org.apache.commons.dbcp.DelegatingStatement is not abstract and does not
override abstract method isPoolable() in java.sql.Statement
public class DelegatingStatement extends AbandonedTrace implements Statement {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingStatement.java:130:
isClosed() in org.apache.commons.dbcp.DelegatingStatement cannot implement
isClosed() in java.sql.Statement; attempting to assign weaker access
privileges; was public
protected boolean isClosed() {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/DelegatingPreparedStatement.java:49:
org.apache.commons.dbcp.DelegatingPreparedStatement is not abstract and does
not override abstract method setCharacterStream(int,java.io.Reader,long) in
java.sql.PreparedStatement
public class DelegatingPreparedStatement extends DelegatingStatement
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/PoolablePreparedStatement.java:40:
org.apache.commons.dbcp.PoolablePreparedStatement is not abstract and does not
override abstract method setCharacterStream(int,java.io.Reader,long) in
java.sql.PreparedStatement
public class PoolablePreparedStatement extends DelegatingPreparedStatement
implements PreparedStatement {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/cpdsadapter/PoolablePreparedStatementStub.java:33:
isClosed() in org.apache.commons.dbcp.DelegatingStatement cannot implement
isClosed() in java.sql.Statement; attempting to assign weaker access
privileges; was public
class PoolablePreparedStatementStub extends PoolablePreparedStatement {
^
working/commons-dbcp/src/java/org/apache/commons/dbcp/datasources/PerUserPoolDataSource.java:51:
org.apache.commons.dbcp.datasources.PerUserPoolDataSource is not abstract and
does not override abstract method
TcreateQueryObject(java.lang.ClassT
[jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[ http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12415690 ] Michael Heuer commented on COLLECTIONS-110: --- Perhaps a key reason that collections isn't generified is that I don't use JDK1.5 in my day job. That is unfortunate -- a lot of developers do. Every time I start to try and get my head around them, I realise just how confusing and messy they are. Reams of rules, exceptions to rules, strange corner cases, unexpected consequences... Might you be able to write test cases for some of these concerns? [collections] Support parametized classes with commons.collections. --- Key: COLLECTIONS-110 URL: http://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Type: Bug Environment: Operating System: other Platform: Other Reporter: Colbert Philippe It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- 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: (POOL-81) Correct PoolUtils javadoc for pool vs. keyedPool
Correct PoolUtils javadoc for pool vs. keyedPool Key: POOL-81 URL: http://issues.apache.org/jira/browse/POOL-81 Project: Commons Pool Type: Improvement Versions: 1.3 Final Reporter: Michael Heuer PoolUtils javadoc contains some mismatched pool vs. keyedPool references. See attached diff.txt. -- 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-81) Correct PoolUtils javadoc for pool vs. keyedPool
[ http://issues.apache.org/jira/browse/POOL-81?page=all ] Michael Heuer updated POOL-81: -- Attachment: diff.txt svn diff Correct PoolUtils javadoc for pool vs. keyedPool Key: POOL-81 URL: http://issues.apache.org/jira/browse/POOL-81 Project: Commons Pool Type: Improvement Versions: 1.3 Final Reporter: Michael Heuer Attachments: diff.txt PoolUtils javadoc contains some mismatched pool vs. keyedPool references. See attached diff.txt. -- 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: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
[ http://issues.apache.org/jira/browse/COLLECTIONS-110?page=comments#action_12415432 ] Michael Heuer commented on COLLECTIONS-110: --- Wanted to add that there is a second more complete project on sourceforge than the one referred to above: http://collections.sf.net Not sure what to think of the re-branding done on their project home page, however. [collections] Support parametized classes with commons.collections. --- Key: COLLECTIONS-110 URL: http://issues.apache.org/jira/browse/COLLECTIONS-110 Project: Commons Collections Type: Bug Environment: Operating System: other Platform: Other Reporter: Colbert Philippe It's time to create a parallel version of commons.collections to support parametized classes of each container class and abstract class. It's not that hard. There is a 23 PDF document on Sun Java website describing in detail how it should be done and what to watch out for. I already converted a few classes from commons.collection privately for my own needs. Once you get the hang of it, it's a rather quick process. I am even willing to volunteer my time to do some more but I need the collaboration of some of the original programmers to watch over things. -- 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: Collections-events
Bryce L Nordgren wrote: I also believe that Michael Heuer may have released something related on java.net? Cool. I'll go looking for it too. Sorry for chiming in late, my stuff is in cvs at java.net but was never released. I would be willing to help revive collections-events if there is interest. Even more so if it can happen with generics support. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release collections v3.2
A few minor site/doc things: - it would be nice if the [bugzilla id]s in the web release notes were links to the bugzilla report, e.g. http://issues.apache.org/bugzilla/show_bug.cgi?id=[bugzilla id] - StaticBucketMap - containsKey -- StaticBucketMap.containsKey in release notes - present/past tense should be updated in history.html, for example Collections 3.0 represents should be Collections 3.0 represented, similar for 2.1.1 and 3.1 - remove references to deprecated classes (BeanMap, MultiHashMap) in collections package.html? - class javadoc for BoundedFifoBuffer and UnboundedFifoBuffer should read the same: UnboundedFifoBuffer is a very efficient implementation of Buffer. BoundedFifoBuffer is a very efficient implemention of Buffer bound in size that does not alter the size of the buffer at runtime. - StringValueTransformer class javadoc: Transformer implementation that returns String.valueOf input objects. - consistency for class javadoc in keyvalue package -- references to Map.Entry/MapEntry/Map Entry should all the be same - it's -- its in list package.html Sorry if I'm being too nit-picky ... :) [X] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... (non-binding) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
Sandy McArthur wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. With the advent of maven (and the maven ant tasks to a lesser extent) and its central repository, I have found I almost never need to go through that exercise any more. A bit of doc something like... p To include commons-xxx as dependency for your maven 2.x project (and transitively, commons-xxx's dependencies) use the following in your codepom.xml/code: source dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx/artifactId version1.0/version scopecompile/scope /dependency /source /p p To include commons-xxx as a dependency for your maven 1.x project use the following in your codeproject.xml/code: source dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx/artifactId version1.0/version /dependency !-- dependencies for commons-xxx -- dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx-dependency0/artifactId version2.5/version /dependency dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx-dependency1/artifactId version3.0/version /dependency /source /p (and a similar example using the maven ant tasks) ...would be quite useful to have on a download page, and could probably be generated via the maven 1.x or 2.x dependency plugin. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Release tests for Commons IO 1.2 RC5
Stephen Colebourne wrote: All. Please test RC5 or your SVN copy. It should fix the OS X issues, but obviously I can't actually test that... RC5 tests fine for me, jdks 1.4 and 1.5 on Mac OS X 10.4.5. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons IO 1.2 (based on RC3)
Henri Yandell wrote: Sigs, hashes both worked fine (using KEYS from io download). Maven fails on the unpacked source zip. JDK 1.4 on OS X. The errors are in: [junit] Running org.apache.commons.io.FileSystemUtilsTestCase [junit] Tests run: 21, Failures: 1, Errors: 0, Time elapsed: 0.311 sec [junit] [ERROR] TEST org.apache.commons.io.FileSystemUtilsTestCase FAILED [junit] Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase [junit] Tests run: 5, Failures: 1, Errors: 0, Time elapsed: 0.531 sec [junit] [ERROR] TEST org.apache.commons.io.FileUtilsCleanDirectoryTestCase FAILED Hen RC4 fails with jdk 1.4.2 and 1.5 on OSX: [junit] [ERROR] TEST org.apache.commons.io.FileSystemUtilsTestCase FAILED [junit] Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase [junit] Tests run: 5, Failures: 1, Errors: 0, Time elapsed: 0.517 sec [junit] [ERROR] TEST org.apache.commons.io.FileUtilsCleanDirectoryTestCase FAILED $ java -version java version 1.4.2_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232) Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode) $ java -version java version 1.5.0_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-72) Java HotSpot(TM) Client VM (build 1.5.0_05-44, mixed mode, sharing) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] LineIterator suggestions [was: LineIterator finalize]
Stephen Colebourne wrote: snip I also put closeQuietly back into the tests. Without the try-finally and closeQuietly, a test failure was hidden by other errors. This emphasises the value of the usage pattern to me. (non-binding) +1 to retaining closeQuietly. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Collections 3.2/4.0
Stephen Colebourne wrote: Plan for collections 3.2 Agree contents (notably, I'd like to remove BoundedBuffer) Check bugs Build and release in single jar format Plan for collections 4.0 Break collections into smaller jars (either as one project or multiple) Remove deprecations (maybe to a deprecated jar) Looking ahead a bit further, at what point might the following issues being addressed, if at all? - bringing external jdk1.5/generics project(s) back to commons - deprecating [collections] functor in favor of [functor] project - resolving Collection contract violations in Bag interface - AbstractHashedMap design improvements (Bugzilla Bug 27231) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] Moving forward
Stephen Colebourne wrote: Henri Yandell wrote: On the compatibility interface; I'd rather just drop it and spend that effort on migration documentation. Does raise the question of whether the cli2 package name ever becomes cli. Having it as cli2 does avoid any surprises; things flat out won't work. Or [commons-commandline], a completely 'new' commons project. +1 michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [id] Review before 1.0 (Summary)
On Fri, 20 Jan 2006, Phil Steitz wrote: On 1/17/06, J?rg Schaible [EMAIL PROTECTED] wrote: Stephen Colebourne wrote on Monday, January 16, 2006 11:13 PM: J?rg Schaible wrote: The release plan is available now: http://wiki.apache.org/jakarta-commons/id/1.0ReleasePlan Looks good, though we may actually want to keep PrefixXXXGeneratorIdentifiers. See below. Refactor PrefixXXXGeneratorIdentifier implementations This should be done with great care. id generation is very performance and sync sensitive in many systems. I am sure, Phil will take care of it, if he starts refactoring. But basically there is not much difference by just decorating an arbitrary StringIdentifierGenerator and prefixing the resulting id compared to the current implementations - and the AbstractStringIdentifierGenerator could implement a protected nextStringBufferIdentifier method. Talking about transformation is another issue though ... I have started working on this. What I had in mind was just a simple facility for creating composite identifiers created by concatenating results of an array of generators. This does add overhead for the prefix identifiers, so we may actually want to keep these. Synchronization is a separate issue. I will commit some code this weekend to look at. Phil, could you create a bugzilla entry for this? I might have something to contribute. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [id] Review before 1.0 (Summary)
J?rg Schaible wrote:
8/ Prefix generators
We have 3 generators, that add a prefix to the generated id. All 3 classes
to mainly the same for 3 different StringIdentifierGenerators.
Proposal: Since we have a lot more StringIdentifierGenrators (e.g. the
UUIDIdentifierGenerators a StringIdentifiers too), I would refactore this 3
classes into a wrapper in a separate package o.a.c.id.wrapper and delegate
to an arbitrary StringIdentifierGenerator implementation:
class PrefixStringIdentifierGenerator implements StringIdentifierGenerator {
PrefixStringIdentifierGenerator(StringIdentifierGenerator delegee) {
this.delegee = delegee;
}
...
}
How about a single class CompoundStringIdentifierGenerator that can use
the delegate as any one of prefix, middle, postfix?
And may I add
10/ Serial generators implement Serializable?
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[id] semantic web identifiers?
Hello, Might there be interest in adding support for semantic web style identifiers? Currently one might use one of the PrefixedXxx serial generators to create String identifiers, and create e.g. URIs from those Strings in a second step, but I think it would be desireable to generate e.g. URIs directly: URIGenerator java.net.URI nextURI(); URLGenerator java.net.URL nextURL(); QNameGenerator javax.xml.namespace.QName nextQName(); See: RDF URI-based Vocabulary and Node Identification http://www.w3.org/TR/rdf-concepts/#section-URI-Vocabulary Namespaces in XML http://www.w3.org/TR/REC-xml-names/ XML Schema Part 2: Datatypes Second Edition http://www.w3.org/TR/xmlschema-2/#QName michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RE-VOTE] Release Commons Math 1.1
--- [X] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- (non-binding) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons math 1.1
--- [X] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- (non-binding) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] New commons proper component - collections-functors
robert burrell donkin wrote: On Tue, 2005-11-29 at 15:09 +, Tim Roberts wrote: +1 I support creating a functors library (but not necessarily called collections-functors). Rational: I think functors are a powerful approach to software design, under represented (in java) and non-standardised. I would like to see functors (sandbox) integrated and have a common interface set (and would like to help with such an undertaking). In addition to reducing the size of collections developers would, IMO, like to be able to use functors separately from collections. i'm beginning to suspect that there are number of secret functor users out there... a lack of community prevented the functor component progressing from the sandbox. perhaps times have changed and there may be now enough momentum. would need a committer with enough time as well as enough interested developers... opinions? I think maybe you stated that backward -- the fact that the functor component was in the common sandbox may have prevented [functor] from gathering a community. How can a sandbox component gather users without a release? There is a lot of functor-related activity out there: Functor Objects (Wiki) http://c2.com/cgi/wiki?FunctorObject Blocks In Java (Wiki) http://c2.com/cgi/wiki?BlocksInJava jga - Generic Algorithms for Java http://jga.sourceforge.net Colt Project http://dsd.lbl.gov/~hoschek/colt More functor interfaces http://www.dishevelled.org/functor michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] any objections?
On Sat, 12 Nov 2005, Phil Steitz wrote: On 11/12/05, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2005-11-12 at 13:44 +, Stephen Colebourne wrote: robert burrell donkin wrote: has anyone run a long stress test? if not, i'm willing to code up something and set it running on my debian box for a few days. i'd appreciate a second pair of eyes on the code (to avoid mistakes). My attempt at one is attached to bugzilla - SoakLRUMap. I've only run it for an hour or so though. I ran something similar for two 3-hour runs with no errors, using a mix of Integer and String keys engineered to get a lot of reuse to happen. I did lots of shorter runs modifying the the number of buckets, number of threads, and relative frequency of adds / replaces, etc. It was easy to get the reported errors with synchronization off; but I saw no errors when access was properly synchronized. Just for the record, since everyone might not have access to these platforms, I saw the same results as Phil while running SoakLRUMap overnight on Mac OS X 10.4.3 dual-G4 and dual-G5 hardware with java versions 1.4.2_09 and 1.5.0_05. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] StrBuilder errors
See patch I attached to bugzilla #34715 http://issues.apache.org/bugzilla/show_bug.cgi?id=34715 michael On Thu, 14 Jul 2005, Gary Gregory wrote: Hello: I'm getting the following two StrBuilderTest errors (Sun Java 1.4.2_08): testAppendFixedWidthPadLeft(org.apache.commons.lang.text.StrBuilderTest) junit.framework.ComparisonFailure: expected:-null but was:null- at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.commons.lang.text.StrBuilderTest.testAppendFixedWidthPadLeft( StrBuilderTest.java:571) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRun ner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRu nner.java:196) testAppendWithSeparators_Iterator(org.apache.commons.lang.text.StrBuilde rTest) java.util.NoSuchElementException at java.util.AbstractList$Itr.next(AbstractList.java:426) at org.apache.commons.lang.text.StrBuilder.appendWithSeparators(StrBuilder. java:614) at org.apache.commons.lang.text.StrBuilderTest.testAppendWithSeparators_Ite rator(StrBuilderTest.java:727) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe stRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRun ner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRu nner.java:196) Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] text.Interpolation, on to 2.2
Gary Gregory wrote:
- (for me ;-) Provide an Interpolation feature that allows a simple way
to use System properties to replace variables in a String. For me, this
could be as simple as:
String s = XXX.resolveAll(source, $, {, },
System.getProperties());
Maybe it is a bit of overkill, but you could use Velocity for this:
Velocity.init();
VelocityContext ctx = new VelocityContext(System.getProperties());
Template t = new Template(...); // make a template from source
StringWriter sw = new StringWriter();
t.merge(ctx, sw);
String s = sw.toString();
Why reimplement something that already works quite well?
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] text.Interpolation, on to 2.2
Michael Heuer wrote:
Gary Gregory wrote:
- (for me ;-) Provide an Interpolation feature that allows a simple way
to use System properties to replace variables in a String. For me, this
could be as simple as:
String s = XXX.resolveAll(source, $, {, },
System.getProperties());
Maybe it is a bit of overkill, but you could use Velocity for this:
Velocity.init();
VelocityContext ctx = new VelocityContext(System.getProperties());
Template t = new Template(...); // make a template from source
StringWriter sw = new StringWriter();
t.merge(ctx, sw);
String s = sw.toString();
Sorry, even easier:
StringWriter sw = new StringWriter();
VelocityContext ctx = new VelocityContext(System.getProperties());
VelocityEngine.evaluate(ctx, sw, source);
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Release Candidiate 8 available
Steven Caswell wrote: Commons-lang 2.1 release candidate 8 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1/ Primary change is Gary's working out the oddball build and class loading issue that only seems to happen on Windows XP (SP2) since Simon reports that the ant build works fine for him on Linux. As with previous RCs, verification against as many JDK versions would be appreciated, and a sanity check of the docs would also be welcome. Works for me with maven 1.0.2 on MacOSX Tiger and JDKs java version 1.5.0_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-56) Java HotSpot(TM) Client VM (build 1.5.0_02-36, mixed mode, sharing) java version 1.4.2_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-215) Java HotSpot(TM) Client VM (build 1.4.2-50, mixed mode) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VOTE 2.1 release based on RC8
A non-binding +1 from me. Thanks for all the work on these RCs, Steven. michael On Mon, 6 Jun 2005, Steven Caswell wrote: Now that RC8 (http://www.apache.org/~stevencaswell/commons-lang-2.1) has been up for a few days with no issues, I propose it becomes the 2.1 release. [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Release Candidiate 8 available
Michael Heuer wrote: Steven Caswell wrote: Commons-lang 2.1 release candidate 8 is available at http://www.apache.org/~stevencaswell/commons-lang-2.1/ Primary change is Gary's working out the oddball build and class loading issue that only seems to happen on Windows XP (SP2) since Simon reports that the ant build works fine for him on Linux. As with previous RCs, verification against as many JDK versions would be appreciated, and a sanity check of the docs would also be welcome. Works for me with maven 1.0.2 on MacOSX Tiger and JDKs java version 1.5.0_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-56) Java HotSpot(TM) Client VM (build 1.5.0_02-36, mixed mode, sharing) java version 1.4.2_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-215) Java HotSpot(TM) Client VM (build 1.4.2-50, mixed mode) Found an older one, although not significantly different; also works for me with maven 1.0.2 on MacOSX 10.3.9 and JDK java version 1.4.2_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-141.4) Java HotSpot(TM) Client VM (build 1.4.2-38, mixed mode) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons-Collections enhanced with Java Generics Support
James Carman wrote: Suppose we do want to further pursue this (I think we should). How would you recommend we set up the project? Should we branch commons-collections off and start doing releases off of the JDK5 branch along side the main branch? With a nod to Rules for Revolutionaries [1] I think it makes the most sense to branch commons-collections. This should be a lot easier process now that the repository is in subversion. The biggest obstacle to overcome is the lack of interested commons committers to coordinate non-Apache developers, to merge different implementations (there is a second 1.5 collections implementation at collections15.sourceforge.net), and address some of the problem areas in the generic conversion process, e.g. MultiMap. michael [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 24, 2005 11:12 AM To: Jakarta Commons Developers List Subject: Re: Commons-Collections enhanced with Java Generics Support On Tue, 2005-05-24 at 16:05 +0200, Thomas Dudziak wrote: On 5/24/05, James Carman [EMAIL PROTECTED] wrote: Why can't we host this project at ASF? Couldn't we create a new branch for JDK5 collections or something? +1, though I'd prefer the simple solution of two jars, one for pre-1.5 and one for 1.5 which contains the generics-support (either version or add-on jar). This would prevent divergences in future versions as only one codebase has to be supported. The major reason the project was developed on sourceforge is that the people who wanted to do the implementation were not commons committers, and no commons committers had time to manage the project. I don't know whether the developers (John/Matt) are even interested in the project being merged back into apache at the moment. But if they were, then in order for it to become a commons project (including being a branch of the existing collections project) either some existing commons committers would need to volunteer to commit patches submitted (including being responsible for the quality, licensing, and ensuring longterm support etc) or some/all of the generics project developers would need to be elected as commons committers. But we can't just elect someone as a commons committer without knowing the quality of their work or their ability to work well within commons (esp. having plenty of patience ;-). I think it very likely that Matt/John would be fine additions to the commons team, but we just don't know them yet (at least I don't). If someone had the time to check the collections.sf.net project mail list and review the existing code thoroughly this might be enough to give a +1 on this issue. Or if they have a track record with some other large open-source project. Otherwise the project really needs a few commons committers to work with them for a month or two until we can feel comfortable about electing them. There is also the question of how large the generic collections community will be. There aren't yet a whole lot of projects coding to 1.5 as far as I know. That would mean that it might be hard to ensure a pool of interested developers for this project that would continue maintenance. And that would be bad - commons doesn't need any more zombie projects than it already has. Then again I may be wrong; there might be huge demand for this. Or Matt/John may be enthusiastic enough to provide maintenance over the next year or two until java 1.5 becomes more prevalent. Checking the sf project forums should provide some evidence of whether there is a solid user community for this project or not. Certainly a pool of only two developers is a little fragile for long-term support if there is only a small user pool to draw new developers from. Note that I'm not saying it's impossible to bring this project into commons if Matt/John want to. And I certainly don't mean any offence to Matt/John, who have clearly put a lot of effort into writing code that is available for free and are therefore good guys by any definition. But these are issues that need to be addressed before adopting this code into commons. In the meantime, though, I see no harm in making sure we have plenty of references from commons to the collections.sf.net project (see, there's one!) from the commons site, wiki, etc. We can make sure people who might visit commons-collections are made aware of the generics version and then those people can make up their own minds about which code base they want to use. That's just being friendly and helpful. And there's nothing *wrong* with projects on sourceforge anyway. If you want to address some of these issues and push for generic collections in commons then go ahead and put a case that addresses the above issues. Regards, Simon - To unsubscribe,
Re: [lang] (RE)VOTE 2.1 Release
A few minor nits with the web site: Links before commas and periods have an extra space, e.g. lang status document . and Maven , JDiff , PMD , FindBugs on index.html. I had thought that this issue was resolved in an upgrade to maven and/or the maven xdoc plugin? Update tasks.html, user guide has been written. (it is quite nice, by the way) Give userguide.html a header similar to that of developerguide.html. userguide.html abbout -- about userguide.html use codeCharSetUtils.delete(testtest, tr)/code instead of 'CharSetUtils.delete(testtest, tr)' ? What about the other methods used in the text, should they be put in code tags as well? developerguide.html nessesary -- necessary A non-binding +1 from me. michael On Tue, 26 Apr 2005, Steven Caswell wrote: Release candidate 3 (and hopefully final :) is in http://www.apache.org/~stevencaswell/commons-lang-2.1/ The only changes between RC2 and RC3 are documentation clean-up (thanks to Gary for finding some inconsistencies). It would be good if someone could check the compatibility of the distribution with JDK 1.2. I know Stephen asked for a clirr, and I haven't had time to work on that, but I should be able to get it by tomorrow evening (ET). Not sure if another vote is necessary since I don't recall any -1s, but I'll go ahead and propose it and see what shakes out: [ ] +1 [ ] -1 -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generics/JDK 5
http://collections15.sourceforge.net/ michael On Thu, 24 Mar 2005, Thomas Klaeger wrote: Hello, I was looking for a generics-capable version of commons-collections, however everything I could find were to small threads on the mailing list. Instead of complaining I decided to work on it myself. The first thing I did was creating a generics-version of the various interfaces provided by commons-collections. Now I'm seeking your advice: where should I put the changed source files, as some discussion is sorely needed? Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving benchmark out of sandbox?
On Sun, 13 Mar 2005, Kevin A. Burton wrote: Has annyone had a chance to take a look at the benchmark project I've been working on? http://jakarta.apache.org/commons/sandbox/benchmark/ I'm really happy with the way everything is turning out and I'd like to move from the sandbox to proper so that I can do a release. I am not an apache committer, so consider these comments appropriately, but I do not feel that benchmark as-is should move to commons proper. A checkstyle report should be generated, as there are lots of style and API problems that I see, public fields, methods with no javadoc, wild-card imports, package-level fields on a public abstract class, etc. Even if the quality of the implementation is good, it doesn't look it at first glance. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear RealMatrixImplTest.java
Sorry to be replying to a cvs commit message, but I think perhaps this is
taking this idea of immutability too far -- a matrix data structure isn't
very useful if you can't even modify the entries.
Wouldn't the pattern used in the Collections interfaces for modifiers be
more reasonable here?
interface RealMatrix
{
...
/**
* Sets the entry in the specified row and column to the specified
* value (optional operation).
*
* ...
* @throws UnsupportedOperationException if the codesetEntrycode
*operation is not supported by this real matrix
*/
void setEntry(int row, int column, double value)
...;
}
I also wanted to mention that I feel that this interface and its
implementation seem too closely intertwined with double arrays, as if
clients of the API are going to be moving back and forth between the
two data representations regularly.
With the Collections interfaces, if I want a List, I'm going to use
one, not go back and forth between Lists and arrays. Similarly, if I want
to use a RealMatrix, I'd like to use one, not go back and forth between it
and 1D and 2D double arrays.
michael
On 12 Oct 2004 [EMAIL PROTECTED] wrote:
psteitz 2004/10/11 23:19:50
Modified:math/xdocs/userguide linear.xml
math/src/java/org/apache/commons/math/linear RealMatrix.java
RealMatrixImpl.java
math/src/test/org/apache/commons/math/linear
RealMatrixImplTest.java
Log:
Removed data mutators from RealMatrix interface and RealMatrixImpl.
Revision ChangesPath
1.9 +4 -5 jakarta-commons/math/xdocs/userguide/linear.xml
Index: linear.xml
===
RCS file: /home/cvs/jakarta-commons/math/xdocs/userguide/linear.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- linear.xml 17 May 2004 05:57:38 - 1.8
+++ linear.xml 12 Oct 2004 06:19:50 - 1.9
@@ -56,11 +56,10 @@
// One more with three rows, two columns
double[][] matrixData2 = { {1d,2d}, {2d,5d}, {1d, 7d}};
-RealMatrix n = new RealMatixImpl();
-n.setData(matrixData2);
+RealMatrix n = new RealMatixImpl(matrixData2);
-// Note: both constructor and setData make
-// Fresh copies of input double[][] arrays
+// Note: constructor makes a
+// Fresh copy of the input double[][] array
// Now multiply m by n
RealMatrix p = m.multiply(n);
1.25 +1 -27
jakarta-commons/math/src/java/org/apache/commons/math/linear/RealMatrix.java
Index: RealMatrix.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/linear/RealMatrix.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- RealMatrix.java 9 Oct 2004 22:39:22 - 1.24
+++ RealMatrix.java 12 Oct 2004 06:19:50 - 1.25
@@ -94,14 +94,6 @@
double[][] getData();
/**
- * Overwrites the underlying data for the matrix with
- * a fresh copy of codedata/code.
- *
- * @param data 2-dimensional array of entries
- */
-void setData(double[][] data);
-
-/**
* Returns the a
href=http://mathworld.wolfram.com/MaximumAbsoluteRowSumNorm.html;
* maximum absolute row sum norm/a of the matrix.
*
@@ -197,24 +189,6 @@
* @throws MatrixIndexException if the row or column index is not valid
*/
double getEntry(int row, int column) throws MatrixIndexException;
-
-/**
- * Sets the entry in the specified row and column to the specified value.
- * p
- * Row and column indices start at 0 and must satisfy
- * ul
- * licode0 = row rowDimension/code/li
- * licode 0 = column columnDimension/code/li
- * /ul
- * otherwise a codeMatrixIndexException/code is thrown.
- *
- * @param rowrow location of entry to be set
- * @param columncolumn location of entry to be set
- * @param value value to set
- * @throws MatrixIndexException if the row or column index is not valid
- */
-void setEntry(int row, int column, double value)
-throws MatrixIndexException;
/**
* Returns the transpose of this matrix.
1.33 +8 -57
jakarta-commons/math/src/java/org/apache/commons/math/linear/RealMatrixImpl.java
Index: RealMatrixImpl.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/linear/RealMatrixImpl.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- RealMatrixImpl.java 10 Oct 2004 18:00:33 - 1.32
+++ RealMatrixImpl.java 12 Oct 2004
Re: [math] RealMatrix Immutability
On Tue, 12 Oct 2004, Phil Steitz wrote:
Mark R. Diggory wrote:
Phil,
I think we wanted to maintain the existence of setEntry/getDataRef API
of the RealMatrixImpl without having it in the RealMatrix Interface. At
least until we come up with a strategy for mutability that made more
sense then these methods. This last change removed it from both.
getDataRef is still there in RealMatrixImpl, though I am starting to think
that we can make it protected. Either the class is immutable or it is
not. We need to decide. All of the use cases that I have can actually be
accomplished with the immutable version, using the algebraic operations
exposed in the RealMatrix API. If others have use cases that require
mutability, then we can change it back, but I would like to know what they
are.
Michael,
We are attempting to make the Implementation immutable so that methods
calls such as getColumnMatrix(i) and getSubMatrix(xmin,xmax,ymin,ymax)
will be able to return submatrice objects of the existing data without
duplicating/copying the internal datastore to do so, this will provide
efficient means to access the stored values without performing costly
array copies on what may be very large double[][]'s or copying objects
which may not be in an []. So basically, what we are trying to avoid is
that if I do the following
Matrix a = ...
Matrix b = a.getColumnMatrix(x);
that if (a) is mutable, then doing something like a.setEntry(x,y,d) will
also cause (b) to change, something we should try to avoid, we are
trying to work with these more as mathematical objects and not
necessarily as Collection objects.
Yes, but the getSubXxx and getCol, getRow currently make copies. Assuming
we retain immutability, this makes no functional difference (another
argument for making the class immutable). Implementation will be very
tricky (and likely very inefficient) if we try to support data sharing
as you describe. It would also make getDataRef impossible to implement.
If you require such mutability, could you take a moment and show an
example of the usage you require it for?
I thought at first that I would need mutability in my applications, and I
think that Kim did as well; but I found that my use of it was just because
I did not have the right boundary between the double[][] stuff that I was
doing and the algebraic operations (which is what RealMatrix is for).
The double[][] constructor for RealMatrixImpl copies the input array, so
if I want to fill a matrix with values, isn't it more efficient and more
straightforward to simply fill the matrix?
RealMatrix rm = new RealMatrixImpl(1, 1);
for (int row = 0, rows = rm.getRowDimension(); row rows; row++)
{
for (int col = 0, cols = rm.getColumnDimension(); col cols; col++)
{
rm.setEntry(row, col, someValue);
}
}
I also wanted to mention that I feel that this interface and its
implementation seem too closely intertwined with double arrays, as if
clients of the API are going to be moving back and forth between the
two data representations regularly.
Well, many clients will in fact be doing that, though hopefully with clean
boundaries. Can you suggest alternatives that do not impose too much
overhead?
With the Collections interfaces, if I want a List, I'm going to use
one, not go back and forth between Lists and arrays. Similarly, if I
want
to use a RealMatrix, I'd like to use one, not go back and forth
between it
and 1D and 2D double arrays.
That's sort of the point of the immutability argument above. The double[]
and double[][] valued accessors are for convenience and speed when
crossing the boundary back into the client application. Some applications
will start with arrays, use RealMatrix to perform algebraic operations and
then use output arrays directly. That is why the accessors are there.
Thanks for the feedback.
Phil
-
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: [math] RealMatrix Immutability
On Tue, 12 Oct 2004, Mark R. Diggory wrote: Phil Steitz wrote: Mark R. Diggory wrote: Phil, I think we wanted to maintain the existence of setEntry/getDataRef API of the RealMatrixImpl without having it in the RealMatrix Interface. At least until we come up with a strategy for mutability that made more sense then these methods. This last change removed it from both. getDataRef is still there in RealMatrixImpl, though I am starting to think that we can make it protected. Either the class is immutable or it is not. We need to decide. All of the use cases that I have can actually be accomplished with the immutable version, using the algebraic operations exposed in the RealMatrix API. If others have use cases that require mutability, then we can change it back, but I would like to know what they are. Thats what I'm hoping to hear from Michael, I want to see solid examples of the need. Michael, We are attempting to make the Implementation immutable so that methods calls such as getColumnMatrix(i) and getSubMatrix(xmin,xmax,ymin,ymax) will be able to return submatrice objects of the existing data without duplicating/copying the internal datastore to do so, this will provide efficient means to access the stored values without performing costly array copies on what may be very large double[][]'s or copying objects which may not be in an []. So basically, what we are trying to avoid is that if I do the following Matrix a = ... Matrix b = a.getColumnMatrix(x); that if (a) is mutable, then doing something like a.setEntry(x,y,d) will also cause (b) to change, something we should try to avoid, we are trying to work with these more as mathematical objects and not necessarily as Collection objects. Yes, but the getSubXxx and getCol, getRow currently make copies. Assuming we retain immutability, this makes no functional difference (another argument for making the class immutable). Yes, like I said, this a feature I am working on in my checkout. I havn't committed it because it is not complete yet. Implementation will be very tricky (and likely very inefficient) if we try to support data sharing as you describe. It would also make getDataRef impossible to implement. Not inefficient, a little complex, yes, but not inefficient, the only real difference is where in the original datastore data structure (in this case the data[][]) your are iterating over, the RealMatrix representing the Row column or submatrix is simply maintaining extra information about the xmn, xmax, ymin, ymax it represents in the original data store. It accesses the original data store using the getEntry(x,y) . The x and y are transposed to the appropriate location int eh datstore using simple arithmetic. This is similar to how colt matrix views (viewRow, viewColumn, viewSelection, etc.) are implemented (disclaimer: I use colt all the time). michael I think were starting get this thing going in the right direction. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sandbox proposal. Events
On Mon, 4 Oct 2004, Mike Stanley wrote: On Mon, 2004-10-04 at 15:14, Jung, Eric wrote: You might also consider using java.util.EventListener, java.util.EventListenerProxy, and java.util.TooManyListenersException as appropriate. All of these were introduced in JSDK 1.3. Events have been around a while in JDK (since 1.1). My implementation takes a different approach to events than the JDK. Where the JDK uses Class signatures, interfaces, and event objects, I utilize reflection and method invocation. Allowing more arbitrary invocation of methods. Using this delegateMethod/event registry approach, any existing class/method can be invoked when an event is fired/raised. Without requiring classes to implement an interface or signature. Look at .NET's events and delegates. They do something similar to this. Let me package everything up and then contribute it. Then it may be easier for me to demonstrate what I'm trying to accomplish. - Mike p.s. I'm not advocating that this is a better way of handling events, just a different approach. (I do believe it is more convenient and flexible to utilize. especially when adding events and event handlers to existing components.) I also think this fits nicely with frameworks, and other patterns such as the chain of responsibility. For what it's worth, my approach has been to adapt the event pattern in Swing for other purposes. I've documented that pattern and provided velocity source code generation templates in http://shore.net/~heuermh/event-codegen-1.0.tar.gz michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692)
How about 'splitPreserveTokens' ? michael On Tue, 6 Jul 2004, Gary Gregory wrote: edI am not making a big stink about this. My belief is that names are important, especially in a library. I like to discuss such things./ed Just to be more precise, what I am not fond of in splitVerb, as in splitPreserve, is that *what* is to be preserved is not specified and in my IMO not obvious, which is why I prefer, in the replacement of a boolean method (about which I am neutral), splitVerbObject, as in maybe splitKeepAllTokens. When I read code and I see splitKeepAllTokens (or something like it) I can pretty much guess (I think) what is going to happen. Now, you guys can tell that it is 100% obvious that the name splitPreserve describes an API that preserves all of the tokens (after all what else is there to preserve I wonder, but I do not have to wonder if you tell me in the name), in which case I'll happily believe you. My preference is too err on the side of verbosity and non-mysterious API names vs. brevity ;-) The C days are long gone :-) Gary -Original Message- From: Steven Caswell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 16:51 To: 'Jakarta Commons Developers List' Subject: RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) Gary didn't like splitPreserve. I originally suggested splitPreserve so that's fine by me. I could also go with splitAll. And I agree, I don't like the boolean flags either. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 6:28 PM To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) StringUtils currently has no boolean flags in method args, and I want to keep it that way. splitAll? 'Split the string keeping All the tokens' splitPreserve? 'Split the string Preserving all the tokens' Stephen - Original Message - From: Steven Caswell [EMAIL PROTECTED] I agree the name is not great. I'm not sure the other suggestions convey the method behavior either. I typically don't like adding a boolean to change the behavior, but rather have a different method of similar name, but I can't think of a great name either. A few more suggestions: - splitIncludeEmptyTokens - splitKeepEmptyTokens - splitWithEmptyTokens I think I like splitIncludeEmptyTokens the best. But to not keep beating this one to death, if one of these is not suitable, let's just go with adding a boolean argument. Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] War is an ugly thing, but not the ugliest of things. The decayed and degraded state of moral and patriotic feeling that thinks that nothing is worth war is much worse. The person who has nothing for which he is willing to fight, nothing which is more important than his own personal safety, is a miserable creature and has no chance of being free unless made and kept so by the exertions of better men than himself. John Stuart Mill. -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 12:45 PM To: Jakarta Commons Developers List Subject: RE: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) Indeed not a great name. splitPreserve does not tell you what it is preserving. How about: - Instead of splitPreserve, split with boolean argument. - Use another word: Keep or Include or With, with or without what is preserved: - splitKeep - splitKeepSeparator - splitWith - splitWithSeparator - splitInclude - splitIncludeSeparator ? Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, July 05, 2004 15:43 To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.split ignores empty items (Bugzilla bug# 22692) Although splitPreserve isn't a great name, I can't thinkn of a better one. This does seem to be requested functionality for a utils class in addition to Tokenizer, so +1. Stephen - Original Message - From: Steven Caswell [EMAIL PROTECTED] Regarding the solution for
Re: [VOTE][collections] Release 3.1
On Wed, 23 Jun 2004, Stephen Colebourne wrote: - [X] +1 Go ahead and release 3.1 [ ] +0 [ ] -0 [ ] -1 Don't release 3.1, because... - (non-binding) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] JDK1.5
I most definitely have the itch, but frankly, that's a lot of typing. :( [collections] HEAD compiles with 1.5 but as expected generates a pile of unchecked warnings, such as [javac] /home/heuer/working/jakarta-commons/collections/src/java/org/apache/commons/collections/set/MapBackedSet.java:130: warning: [unchecked] unchecked call to removeAll(java.util.Collection?) as a member of the raw type java.util.Set [javac] return map.keySet().removeAll(coll); [javac] ^ [javac] /home/heuer/working/jakarta-commons/collections/src/java/org/apache/commons/collections/set/MapBackedSet.java:134: warning: [unchecked] unchecked call to retainAll(java.util.Collection?) as a member of the raw type java.util.Set [javac] return map.keySet().retainAll(coll); [javac] ^ [javac] /home/heuer/working/jakarta-commons/collections/src/java/org/apache/commons/collections/set/MapBackedSet.java:146: warning: [unchecked] unchecked call to TtoArray(T[]) as a member of the raw type java.util.Set [javac] return map.keySet().toArray(array); The tests don't compile because of some variables named 'enum' in TestCollectionUtils. Just add # javac v1.5 support maven.compile.source=1.5 maven.compile.target=1.5 maven.compile.fork=true maven.compile.compilerargs=-Xlint:unchecked to the [collections] project.properties to build with maven (rc3 ant 1.6) and jdk 1.5 (beta3 build 56). michael On Wed, 23 Jun 2004, Stephen Colebourne wrote: While release 3.1 is being tidied up (still time to vote ;-), I thought I'd just put out a note about JDK1.5. One of the key enhancements in JDK1.5 is generics which allows typed classes using the angle bracket notation. The biggest area this impacts is collections. Clearly questions have to be raised as to how this affects [collections]. So far, I have done no work to see if [collections] will compile under JDK1.5. My expectation is that it will, but there are no guarantees. To take full advantage of generics will involve a considerable rewrite of [collections]. It will affect every class, and produce a version that only compiles on JDK1.5. I have no doubt that Sun spent many mandays changing the JDK classes to achieve this update. Personally, I have no plans to update [collections] to JDK1.5 (no itch, too much effort). If anyone else does, feel free to come in and either change [collections], or (more likely) create a new [collections15] project. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Release 3.1 contents - First chance!
The file overview.html needs a little bit of work. Line 112 reads h4Version 3.0/h4 and the paragraphs in the documentation below could use some revision for clarity. michael On Tue, 8 Jun 2004, Stephen Colebourne wrote: The proposed release for collections 3.1 is: http://www.apache.org/~scolebourne/coll31/ This is your first chance to comment on the propopsed release. I intend to have a public RC stage for this release unless anyone objects. (Thats your second chance) Finally a vote for full release (Thats your third chance...) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java
On 1 Jun 2004 [EMAIL PROTECTED] wrote:
scolebourne2004/06/01 14:25:35
Modified:lang/src/java/org/apache/commons/lang Validate.java
Log:
Ensure Validate has no inter-lang dependencies
I'm confused -- why shouldn't a class in [lang] have dependencies to
other classes in [lang]? Isn't this taking things too far??
michael
Revision ChangesPath
1.12 +6 -5
jakarta-commons/lang/src/java/org/apache/commons/lang/Validate.java
Index: Validate.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/Validate.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- Validate.java 19 Feb 2004 21:04:03 - 1.11
+++ Validate.java 1 Jun 2004 21:25:35 - 1.12
@@ -38,6 +38,7 @@
* @version $Id$
*/
public class Validate {
+// Validate has no dependencies on other classes in Commons Lang at present
/**
* Constructor. This class should not normally be instantiated.
@@ -236,7 +237,7 @@
* @throws IllegalArgumentException if the array is empty
*/
public static void notEmpty(Object[] array, String message) {
-if (ArrayUtils.isEmpty(array)) {
+if (array == null || array.length == 0) {
throw new IllegalArgumentException(message);
}
}
@@ -255,7 +256,7 @@
* @throws IllegalArgumentException if the array is empty
*/
public static void notEmpty(Object[] array) {
-if (ArrayUtils.isEmpty(array)) {
+if (array == null || array.length == 0) {
throw new IllegalArgumentException(The validated array is empty);
}
}
@@ -356,7 +357,7 @@
* @throws IllegalArgumentException if the string is empty
*/
public static void notEmpty(String string, String message) {
-if (StringUtils.isEmpty(string)) {
+if (string == null || string.length() == 0) {
throw new IllegalArgumentException(message);
}
}
@@ -375,7 +376,7 @@
* @throws IllegalArgumentException if the string is empty
*/
public static void notEmpty(String string) {
-if (StringUtils.isEmpty(string)) {
+if (string == null || string.length() == 0) {
throw new IllegalArgumentException(The validated string is empty);
}
}
-
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]
[collections] BidiMap javadoc typo
A small typo in the BidiMap javadocs: $ cvs diff src/java/org/apache/commons/collections/BidiMap.java Index: src/java/org/apache/commons/collections/BidiMap.java === RCS file: /home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/collections/BidiMap.java,v retrieving revision 1.15 diff -r1.15 BidiMap.java 23c23 * Th interface extends codeMap/code and so may be used anywhere a map --- * This interface extends codeMap/code and so may be used anywhere a map (or Th - The would work too) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] KeySetMap?
Hello, I need an implementation of Map that uses a predefined set of keys as its keySet. Changes made to the set of keys should be reflected in the map's keySet but not the other way around, e.g. map.keySet() should be unmodifiable. I've written something using a wrapped map but I'm having trouble specifying all of the desired behavior. For instance, if the size of the keySet is 0 but no mappings exist, what is the size of the map? Would the entrySet view contain entries containing each key mapped to null? What should map.remove(key) do? etc. Any comments are appreciated. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Bag interface
On Mon, 26 Apr 2004, Stephen Colebourne wrote: The current Bag interface has the following javadoc warning: * iNote that this interface violates the [EMAIL PROTECTED] Collection} contract./i * The behavior specified in many of these methods is inot/i the same * as the behavior specified by codeCollection/code. The noncompliant methods * are clearly marked with (Violation). A future * version of this class will specify the same behavior as codeCollection/code, * which unfortunately will break backwards compatibility with this version. This has caused bile-like derision in some quarters, and is not something I've ever liked - its basically an artifact of collections history. I propose that we change this to state that its wrong, but that we will keep compatability: * iNOTE: This interface violates the [EMAIL PROTECTED] Collection} contract./i * The behavior specified in many of these methods is inot/i the same * as the behavior specified by codeCollection/code. * The noncompliant methods are clearly marked with (Violation). * Exercise caution when using a bag as a codeCollection/code. * p * This violation resulted from the original specification of the interface. * In an ideal world, the interface would be changed to fix the problems, however * it has been decided to maintain backwards compatibility instead. Opinions? How about creating a Bag2 (or a better name) interface that does not violate the Collection contract and deprecating Bag and friends? michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Size and scope issues
On Thu, 22 Apr 2004, Stephen Colebourne wrote: Its always good to see the opposing points of view ;-) Thanks for all feedback. Following this discussion I did a search around the web to try and find references to collections causing a problem by its size. I didn't really find any, but that doesn't prove anything. The appserver point is part of what jakarta is about, and dropping in a library should not result in concerns over size. On the other hand, projects like beanutils and digester which used one collection each are quite correct to terminate the dependency and cut and paste. One point I should make is that commons frequently gets requests to release everything as one jar. Finding the right component size is always tricky. I would argue collections is about right. The biggest query is really over the functors, but thats a long story - see the mail archives for the pain that they were. I would also argue against having a collections-all and collection-part release strategy. Its all too easy to mess up and to have an old collections-all blocking a newer collections-part. I agree. Finally, half the problem with size in collections comes from the Sun interfaces. Map especially requires an awful lot of classes to implement, and that takes up space ;-) I will go and have a look to see if anything can be done to trim space. Who knows, there may be something simple! Perhaps some of the classes in [collections] could be presented as a JSR for inclusion in the JDK at some later date. That might cut the size of the jar some. :) michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [events] DynamicProxy decorator
On Tue, 20 Apr 2004, Herve Quiroz wrote: Thanks for the link Michael. I like the API in nettool, as it is quite generic. I think however that such a package will require a tutorial to get people started as genericity often comes to a price of complexity. Regarding your alternative, do you have API docs available? It's quite difficult to browse the source (especially in a CVS web interface). Sorry, I don't have a real good place to host the javadocs for browsing. You'll either have to use cvs to check out the source and run maven javadoc or download http://shore.net/~heuermh/dsh-observable-javadocs.tar.gz There are still a few TODOs, mostly related to Iterator-remove-from- entrySet-view-on-SortedBidiMap like complexity discussed recently. michael Herve PS: I do remember now that such discussion occured last year. That's mostly why I wonder why [events] is not more active now that it is a standalone project... On Tue, Apr 20, 2004 at 12:12:00PM -0400, Michael Heuer wrote: Hello Herve, You might also want to take a look at http://nettool.sourceforge.net/nc and https://dsh-lib.dev.java.net/source/browse/dsh-lib/observable/ These are alternate designs for collections events, discussed on the commons-dev mailing list back about June of last year. michael - 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: [collections] MultiKeyMap
On Sun, 11 Apr 2004, Stephen Colebourne wrote:
Why do you we need this when we have MultiKeys available -- i.e., what do
you gain by using multiple keys instead of a single MultiKey? Sorry if I
am being dense here, but I don't understand what disaggregation of the
MultiKey is buying us.
Me not being clear. To use MultiKey as keys in the map has an overhead. For
every get/contains/remove you have to create a new MultiKey object which is
then thrown away once the operation is complete. This was a performance
hotspot in some recent testing I did.
With MultiKeyMap the get/containsKey/remove operations do not create the
temporary MultiKey object, they query the data directly. put still creates
the MultiKey as that is what is actually stored in the hashed map.
Might you also be able to use an unmutable MultiKey for storage in the
hashed map and a mutable MultiKey for lookups, with matching equals and
hashCode implementations?
void put(Obj a, Obj b, ...) {
map.put(new MultiKey(a, b, ..));
}
private MutableMultiKey lookupKey = new MutableMultiKey();
Object get(Obj a, Obj b, ...) {
lookupKey.setKeys(a, b, ..));
return map.get(lookupKey);
}
I have something that works this way lying around somewhere.
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Serializable decorators
non-binding +1 to #1. All the wrapper methods in java.util.Collections note The returned xxx will be serializable if the specified xxx is serializable. in their javadocs and the wrapper classes appear follow this design. michael On Tue, 6 Apr 2004, Stephen Colebourne wrote: I had a look at making the decorators serializable, and it will take some time (tedious mostly). However I did find a design decision. The collection that a decorator decorates may or may not be serializable. But does the decorator need to represent this? This leads to two options. 1) Make all decorators implement serializable, but some will fail at runtime if you decorate a non-serializable instance. 2) Implement serializable subclasses of each decorator, and use the factory method to create either the serializable or non-serializable subclass as required. #1 is easy, #2 will take much longer. Any views? #1 is the default choice. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WeakIdentityMap
On Fri, 20 Feb 2004, Noel J. Bergman wrote: If you decide to submit your classes, it would be best of you submitted your code with the ASF License (www.apache.org/licenses) already embedded. And please also submit a software grant (http://www.apache.org/licenses/software-grant.txt) for them. Out of curiousity, how significant does a contribution need to be before completing and submitting the software grant form is required? michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] maven sites
On Mon, 16 Feb 2004, Stephen Colebourne wrote: The point is that maven keep changing their mind. First came classic blue top Second came white top, big font, red section titles Third (current) is white top, good left, but ridiculous section titles see http://maven.apache.org We need to divorce ourselves from this. The current project.css only works against the xdoc 1.4 plugin. snip This may be a bit drastic, but commons could define its own site.jsl file (originally copied from the appropriate version of the xdoc plugin) and use the property maven.xdoc.jsl=.../commons-site.jsl michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] J2SE 1.5 static import of methods
On Fri, 6 Feb 2004, __matthewHawthorne wrote: Al Chou wrote: It'll be nice when the day comes that we can actually use this feature as the default Yeah, really. It's unfortunate that so many vendors and corporations lag behind the latest Java versions. There are so many cool new features in 1.5, and some good new classes also. That doesn't mean that development can't go on with the latest and greatest -- that's what experimental branches in CVS are for. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Moving apply() down DescriptiveStats hierarchy, simplifying structure
On Sun, 25 Jan 2004, Mark R. Diggory wrote: Phil Steitz wrote: The tests and javadoc still need work. I also notice that the BeanList stuff has been moved to /test. Are we thinking about eliminating this? Not really intending to get rid of it, It was more just to maintain BeanListUnivariateImpl (now completely misnamed) as an example of an implementation and a good test, without having to force maintaining it as part of the API. I still have issues with its design. One thing that I thought about which would provide most of the value of these classes would be to just add a factory somewhere (maybe StatUtils) that would create a DescriptiveStatistics instance from a collection and a property name. I think the real nagging issue that pushed all this into test was the fact that you can wrap a collection inside of the BeanListUnivariateImpl but there was no solution to maintaining state on changes in the underlying Collection, which makes it a requirement that everytime a statistic is calculated, all the Collection entries need to be Transformed (over and over again). I guess the big question is... Is there a way to listen for changes in the underlying collection while still using the java.util.collection api? Yes, the sandbox [event] project contains the observed/observable collection packages removed from [collections] HEAD before the 3.0 release. There are a couple of alternate designs yet to be merged so-to-speak into the [event] codebase, at http://nettool.sourceforge.net/nc/ and http://dsh-lib.dev.java.net/source/browse/dsh-lib/observable/ I imagine now that [collections] 3.0 has been released some further progress will be made in [event]. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons Collections 3.0
(non-binding) Kudos to all, this is quite an impressive release. VOTEs please, closing Tuesday 20th Jan Midnight GMT [X] +1 - I support the release of Commons-Collections-3.0 [ ] +0 [ ] -0 [ ] -1 - I oppose the release of Commons-Collections-3.0 because... michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Commons moving to JIRA
What about jakarta-commons-sandbox projects? Note that there is potential for a name overlap problem, e.g. jakarta-commons [myproject] and a jakarta-commons-sandbox [myproject], although I do not believe this is currently the case. michael On Mon, 12 Jan 2004, Noel J. Bergman wrote: Guys, There are separate requests on the table to move BETWIXT, CLI, CODEC, JEXL and CONFIGURATION from Bugzilla to JIRA. JELLY is already there. Are there any other Jakarta Commons projects that want to migrate? Are there any that do NOT want to leave bugzilla? Right now, each project is a component of Commons. If we move to JIRA, I would propose that we create a Project Category for Jakarta Commons, and make each component a project, so that each one can be released separately with its own versioning, etc. We could use a common scheme for permissions, notifications, etc.. Jelly has a dedicate scheme, but I think we could use a single scheme for all of Jakarta Commons. A bugzilla import will create a single Commons project, but we can then move the issues from the imported project into a new project for each of our real projects. For each TLP, we should probably have a single permission scheme, but I'm not going to get into that argument today. We can create jakarta-administrator and jakarta-commons-developer groups. --- Noel - 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: [collections] What is left to do for 3.0?
Would it be possible to add a class that extends ListOrderedMap and provides the default map constructors, e.g. XxxListOrderedMap() XxxListOrderedMap(Map map) // copies, not wraps where Xxx is Default or Simple or somesuch. Alternatively, change ListOrderedMap to ListOrderedMapDecorator and call the new class ListOrderedMap. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [collections] What is left to do for 3.0?
Very minor typo fixes: $ cvs diff -u xdocs/*.xml Index: xdocs/index.xml === RCS file: /home/cvspublic/jakarta-commons/collections/xdocs/index.xml,v retrieving revision 1.7 diff -u -r1.7 index.xml --- xdocs/index.xml 6 Jan 2004 00:44:20 - 1.7 +++ xdocs/index.xml 6 Jan 2004 04:14:44 - @@ -15,7 +15,7 @@ The a href=http://java.sun.com/products/j2se/1.4/docs/guide/collections/;Java Collections Framework/a was a major addition in JDK 1.2. It added many powerful data structures that accelerate development of most significant Java applications. -Since that time it has become the regognised standard for collection handling in the Java language. +Since that time it has become the recognised standard for collection handling in the Java language. /p p Commons-Collections seek to build upon the JDK classes by providing new interfaces, implementations and utilities. Index: xdocs/userguide.xml === RCS file: /home/cvspublic/jakarta-commons/collections/xdocs/userguide.xml,v retrieving revision 1.1 diff -u -r1.1 userguide.xml --- xdocs/userguide.xml 6 Jan 2004 00:44:20 - 1.1 +++ xdocs/userguide.xml 6 Jan 2004 04:14:44 - @@ -21,7 +21,7 @@ section name=Utils classes p -A Utility class is provided for each major collection interface. +An Utility class is provided for each major collection interface. Thus, the codeSet/code and codeSortedSet/code interfaces are provided for by codeSetUtils/code. These classes provide useful methods for working with that collection type. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] [proposal] Bag interface change
Stephen Colebourne wrote: I am proposing to change the Bag interface. http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/Bag.html Add: equals(Object) - Two Bags are equal if they contain the same number of occurrences of all the same elements. hashCode() - The hashCode is defined as the sum total of each elements hashcode, where the hashcode for an element is defined as (e==null ? 0 : e.hashCode()) ^ noOccurances) This will enable Bags to be compared. I'm seeing a problem related to this change with an unit test for a class that extends AbstractBagDecorator, but this failure doesn't show up in the [collections] unit tests. Will investigate further. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] [proposal] Bag interface change
On Mon, 29 Dec 2003, Michael Heuer wrote: Stephen Colebourne wrote: I am proposing to change the Bag interface. http://jakarta.apache.org/commons/collections/api/org/apache/commons/collections/Bag.html Add: equals(Object) - Two Bags are equal if they contain the same number of occurrences of all the same elements. hashCode() - The hashCode is defined as the sum total of each elements hashcode, where the hashcode for an element is defined as (e==null ? 0 : e.hashCode()) ^ noOccurances) This will enable Bags to be compared. I'm seeing a problem related to this change with an unit test for a class that extends AbstractBagDecorator, but this failure doesn't show up in the [collections] unit tests. Never mind, my [collections] snapshot jar file was out of date in my local repository. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] AbstractTestBidiMap issue
In a situation where I have an unit test that extends AbstractTestBidiMap
for a class that extends AbstractBidiMapDecorator,
Testcase: testBidiInverse took 0.01 sec
FAILED
Inverse of inverse is not equal to original. expected same:{key1=value1,
key3=value3, key2=value2} was not:{key1=value1, key3=value3,
key2=value2}
junit.framework.AssertionFailedError: Inverse of inverse is not equal to
original. expected same:{key1=value1, key3=value3, key2=value2} was
not:{key1=value1, key3=value3, key2=value2}
...
This seems a bit odd, assertSame seems to not do the right thing here.
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/collections maven.xml
Cool, works for me.
michael
On 29 Dec 2003 [EMAIL PROTECTED] wrote:
scolebourne2003/12/29 15:56:15
Modified:collections maven.xml
Log:
Update to handle testframework jar creation and install
Revision ChangesPath
1.6 +70 -13jakarta-commons/collections/maven.xml
Index: maven.xml
===
RCS file: /home/cvs/jakarta-commons/collections/maven.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- maven.xml 29 Dec 2003 18:52:01 - 1.5
+++ maven.xml 29 Dec 2003 23:56:15 - 1.6
@@ -1,23 +1,80 @@
-project default=java:jar xmlns:j=jelly:core xmlns:ant=jelly:ant
+project
+default=java:jar
+xmlns:j=jelly:core
+xmlns:license=license
+xmlns:maven=jelly:maven
+xmlns:util=jelly:util
+xmlns:ant=jelly:ant
postGoal name=clover:on
j:set var=maven.junit.sysproperties value=${maven.junit.sysproperties}
org.apache.commons.collections:with-clover/
j:set var=org.apache.commons.collections:with-clover value=true/
/postGoal
- postGoal name=jar:jar
- ant:tstamp/
- ant:property name=workdir
value=${java.io.tmpdir}/buildtemp_${DSTAMP}${TSTAMP}/
- ant:unjar dest=${workdir}
src=${maven.build.dir}/${maven.final.name}.jar/
+ !-- == JAR == --
+ postGoal name=jar:jar
+j:set var=finalName
value=${pom.getPluginContext('maven-jar-plugin').getVariable('maven.final.name')}/
+j:set var=finalVersion value=${finalName.substring(20)} /
+j:set var=testfwkBase value=${pom.artifactId}-testframework /
+j:set var=testfwkName value=${testfwkBase}-${finalVersion} /
+
+ant:jar
+jarfile=${maven.build.dir}/${testfwkName}.jar
+ j:set var=licenseFileNamelicense:fileName//j:set
+ util:file name=${licenseFileName} var=licenseFile/
+ ant:metainf dir=${licenseFile.canonicalFile.parent}
+ant:include name=${licenseFile.canonicalFile.name}/
+ /ant:metainf
+ ant:manifest
+ant:attribute name=Built-By value=${user.name}/
+ant:attribute name=Created-By value=Apache Jakarta Maven/
+ant:attribute name=Package value=${pom.package}/
+ant:attribute name=Build-Jdk value=${java.version}/
+!-- added supplementary entries --
+ant:attribute name=Extension-Name value=Commons Collections Test
Framework/
+ant:attribute name=Specification-Version
value=${pom.specificationVersion}/
+ant:attribute name=Specification-Vendor
value=${pom.organization.name}/
+ant:attribute name=Specification-Title value=Commons Collections Test
Framework/
+ant:attribute name=Implementation-Version
value=${pom.currentVersion}/
+ant:attribute name=Implementation-Vendor
value=${pom.organization.name}/
+ant:attribute name=Implementation-Vendor-Id
value=${pom.organization.identifier}/
+ /ant:manifest
+ ant:fileset dir=${maven.build.dir}/test-classes
+ant:include name=**/AbstractTest*.class/
+ant:include name=**/BulkTest*.class/
+ /ant:fileset
+/ant:jar
+ /postGoal
+
+ postGoal name=jar:install
+j:set var=finalName
value=${pom.getPluginContext('maven-jar-plugin').getVariable('maven.final.name')}/
+j:set var=finalVersion value=${finalName.substring(20)} /
+j:set var=testfwkBase value=${pom.artifactId}-testframework /
+j:set var=testfwkName value=${testfwkBase}-${finalVersion} /
+
+ant:property name=jardir__
value=${maven.repo.local}/${pom.artifactDirectory}/jars/
+ant:mkdir dir=${jardir__}/
+ant:copy
+file=${maven.build.dir}/${testfwkName}.jar
+todir=${jardir__}
+overwrite=true /
+ /postGoal
+
+ postGoal name=jar:install-snapshot
+j:set var=finalName
value=${pom.getPluginContext('maven-jar-plugin').getVariable('maven.final.name')}/
+j:set var=finalVersion value=${finalName.substring(20)} /
+j:set var=testfwkBase value=${pom.artifactId}-testframework /
+j:set var=testfwkName value=${testfwkBase}-${finalVersion} /
- ant:jar
jarfile=${maven.build.dir}/${pom.artifactId}-testframework-${pom.currentVersion}.jar
manifest=${workdir}/META-INF/MANIFEST.MF
- ant:fileset dir=${maven.build.dir}/test-classes
-ant:include name=**/AbstractTest*.class/
-ant:include name=**/BulkTest*.class/
- /ant:fileset
- /ant:jar
-
- delete dir=${workdir}/
+ant:property name=jardir__
value=${maven.repo.local}/${pom.artifactDirectory}/jars/
+ant:mkdir dir=${jardir__}/
+ant:copy
+file=${maven.build.dir}/${testfwkName}.jar
+
Re: [collections] Race condition
I gave it multiple tries but haven't been able to reproduce this failure either, under maven and OSX JDK 1.4.1_01 or Sun Linux JDK 1.4.2. michael On Wed, 3 Dec 2003, Stephen Colebourne wrote: I've seen it once today. Maybe its just my setup - as far as I can see there is no threading in these tests... Stephen Sun JDK1.4.1 Windows98 - Original Message - From: Phil Steitz [EMAIL PROTECTED] I am not seeing these failures. Did recent commits include a fix? If so, where? I am running the tests under maven, Sun Linux JDK 1.4.2. Phil Stephen Colebourne wrote: HELP! Anyone got any good ideas or tools to track this down. It is now very occaisional, but may knock out the next gump run! Today it only happens when I run TestAllPackages. Stephen - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 12:46 AM Subject: [collections] Race condition Sadly there seems to be a race condition in one of the new classes/tests There was 1 failure: 1) testMapIteratorSet(TestFlat3Map.bulkTestMapIterator.testMapIteratorSet) junit.framework.AssertionFailedError: Map must not contain old value expected:false but was:true at org.apache.commons.collections.iterators.AbstractTestMapIterator.testMapIter atorSet(AbstractTestMapIterator.java:267) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at org.apache.commons.collections.map.TestAll.main(TestAll.java:80) When I run with Eclipse debugger the error is in TestFlat3Map. When I run without the debugger, the error is in TestHashedMap. And occaisionaly it works. I'm going to sleep, so I'll disable the test for the moment in case Gump runs. If anyone wants to play they're welcome - I'm guessing its the test thats bad. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] AMap/IterableMap name
On Tue, 2 Dec 2003, Stephen Colebourne wrote: AMap is a new interface that extends Map to provide one extra method MapIterator mapIterator() I can think of various possible names: Map2 - follows Sun naming standards for replacing interfaces MapA - similar idea, but doesn't clash if Sun ever creates Map2 AMap - similar idea but reversed (A is for Apache) +0 IMap - similar idea, but I is for interface -0 IterableMap - the long name +1 If people favour IterableMap, then thats fine. I was looking for something short to indicate that this should be a general replacement to using Map. Maybe IterableMap is clearer though Naming opinions please? Stephen PS. The new implementation HashedMap is also checked in. Naming views on this are also welcomed plus a proper code review!! And I even discovered a small performance error in the JDK HashMap. - Original Message - From: ASHWIN Suresh [EMAIL PROTECTED] -Original Message- From: Michael Heuer [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2003 22:56 To: Jakarta Commons Developers List Might the name IterateableMap or IteratableMap (the proper spelling alludes me) be more descriptive than AMap? michael Going by the standard pattern, it would be IterableMap. [Pattern: -ation -able ] - 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: [collections][PROPOSAL] Remove Observable subpackage
As a consideration, I believe that neither Neil nor myself have commit access to the commons sandbox. That isn't a show stopper for me because I haven't contributed all that much, but maybe Neil feels otherwise? +0 michael On Tue, 25 Nov 2003, Stephen Colebourne wrote: We've had all positives so far. I'm going to take this as agreed and move the code to a new sandbox project. I reckon [observable] is probably the best name, although I'm open to offers. The move will probably happen late this week/weekend unless someone objects. Stephen - Original Message - From: Neil O'Toole [EMAIL PROTECTED] --- Henri Yandell [EMAIL PROTECTED] wrote: I'm +1 on it moving out. Who is the community as far as that piece of code is concerned? Is it just a Stephen Colebourne work, ie) moving to joda makes good sense, or something by more people? Stephen, Michael Hauer, and myself are the three people who have had most involvement in this area. Stephen wrote the observable implementation. I'd developed another full implementation called notifyingcollections with a different slant. I don't have strong feelings on having separate source trees / projects (+0?) but the observable stuff should certainly have its own distributable. There are many equally valid ways of doing notification (in particular callback vs. event-based, and light event vs. heavy event), and novel features that can be added (such as the ReplayableEvent mechanism in notifyingcollections that allows an event to be undone/replayed in an arbitrary manner thus enable the easy recording of the entire state history of a collection). In short, lots of code. I really think it does deserve its own distributable, and the more I think about it, probably it's own subproject. I believe one of the points that Steven was making is that this work is holding up the release of the core [collections] stuff. And since there's so much that can be done in [observable], I feel it would be fairer to decouple the pair. neil - 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: [collections] Proposal - Subpackages
Scott Colebourne wrote: snip Matthew Hawthorne wrote: I also disagree with moving the observable classes. The way I see it, the desire for a collection that is observable overrides a desire for a specific collection type. The observable classes represent a distinct functionality, and splitting them across the suggested packages seems confusing to me. Plus, it seems we would still need an observed or observable package - else, what package would ModificationEvent and ModificationHandler go in? The observable classes are used together, will change together, so why not package them together? The problem with this is that it doesn't follow your suggested standard structure - but I think it has a good reason not to. If split into the packages, there would have to be an events package with the common event code. Actually, the observed package is one of those parts of [collections] like primitives that is more independent. Observable does seem to have the potential to be popular. (I've received various communications about it.) One possibility might be to create a new jakarta-commons project for it like primitives. Although that does seem a little extreme, it might allow it to grow and include other JDK integration classes for example. Stephen I think I would support a move of the Observable classes to a separate project, but I feel that moves the release that much further away. In addition to the existing implementations, I would also like to see Observable maps, primitive collections, and Colt 2D and 3D matrices. The latter I was planning to implement in a separate repository after the observable classes in commons were released. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] package observed -- observable
While I'm at giving my thoughts on names for things, I would also like to see the package o.a.c.collections.observed change to observable to match the class names. I can submit a patch if desired, but most of the change is in cvs, not in the source code. michael On Thu, 9 Oct 2003, Michael Heuer wrote: For what it's worth, I much prefer using the name [primitives] to [pcollections]. (non-binding) +1 michael On Thu, 9 Oct 2003, Stephen Colebourne wrote: Should we name it [pcollections]? Or is [primitives] better? (The sandbox primitives is then a sandbox for the proper component for experimentation). I had forgotten about the special io input stream stuff, which might lead to the name [primitives]. I don't think that this affects the vote, but it does affect the CVS creation! Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] BidiMap / DoubleOrderedMap
On Sat, 20 Sep 2003, Phil Steitz wrote: See comments inline. Stephen Colebourne wrote: I have been prompted to take a look at DoubleOrderedMap by bugzilla and been a little surprised by what I found. Given the history of collections, what we have is a single implementation brought in from an external project. [collections] should do better :-) A bidirectional map is a relatively standard concept in computing. It is a map where you can use a key to find a value, or a value to find a key with equal ease. This deserves its own interface in [collections] - BidiMap. I agree, though I would favor either spelling out Bidirectional or using Invertible or OneToOne as the prefix. Unless the term BidiMap is a familiar term, I would suggest picking a full word for the prefix. For what it's worth, I would also prefer Bidirectional for the prefix. michael The DoubleOrderedMap class goes beyond this by being Sorted, effectively holding all entries in a Compared order always. This effectively equates to a second interface in [collections] - SortedBidiMap. Yes, and it is important to distinguish between what is required by the interface and how the implementation happens to work. The current class header comments are a bit confusing/nonsensical on this. How things are stored is irrelevant to the interface. BidiMap -- Map methods + BidiMap inverseBidiMap() Object getKeyForValue(Object value) Could drop ForValue here. Object removeValue(Object value) Set entrySetByValue() Set keySetByValue() Collection valuesByValue() (these method names are from DoubleOrderedMap, and seem OKish) SortedBidiMap BidiMap + SortedMap + inverseSortedBidiMap() subMapByValue() headMapByValue() tailMapByValue() The existing DoubleOrderedMap is an implementation of SortedBidiMap. However I would like to rename it to TreeBidiMap. InvertibleTreeMap or BidirectionalTreeMap might be better. An alternative implementation of BidiMap would then be needed, which would be useful as it would not require objects to be comparable. +1 With these new interfaces, decorators could then be written as required. Anything obvious I've missed? Any volunteers? Stephen Phil - 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: [collections] Observed
On Wed, 17 Sep 2003, Stephen Colebourne wrote:
How useful are these convenience methods? I added them, then removed them.
Trouble is that not every handler will necessarily use listeners (although
most will).
It seems to me that the Handler is more an artifact of designing
flexibility into the implementation than something that a client (in most
cases) wants to concern themselves with.
You raise a good exception though.
michael
Synchronized - collection is always synchronized
Bounded - collection is always bounded
Predicated - collection is always predicated
Unmodifiable - collection can not be modified
Observed - collection is always observed
Observable - collection can be observed
Naming is dubious, but I guess Observable might be marginally better as the
observer is optional. Any other views?
Stephen
From: Michael Heuer [EMAIL PROTECTED]
Could you add methods to ObservableCollection and friends that forward to
the ModificationHandler,
public void addPreModificationListener(Object l)
{
getHandler().addPreModificationListener(l);
}
public void removePreModificationListener(Object l)
public void addPostModificationListener(Object l)
public void removePostModificationListener(Object l)
etc.
Also, before release, does anyone else want to weigh in on Observable vs.
Observed?
michael
On Wed, 17 Sep 2003, Stephen Colebourne wrote:
We still have too many issues for a freeze this weekend, so I'll extend
the
deadline by two weeks at this point, although I shan't be surprised if
it
slips again. The code is improving greatly however, so this is good.
Still to do:
- ObservedMap
- write observedXxx() methods for CollectionUtils et al
- write release notes
- tidy up the Bugzilla entries
- MultiMap changes??
- Bag interface changes??
- OrderedMap decorator?
Stephen
- Original Message -
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 10:34 PM
Subject: [collections] 3.0 release (1)
I am volunteering to arrange the 3.0 release of [collections], which
is
long
overdue.
I am currently:
- finishing the ObservedCollection code
- writing release notes
- trying to separate the primitive collections code
- rename SequencedSet to OrderedSet
- reviewing the bugzilla entries
Other tasks:
- write OrderedMap decorator (Hen)
- review Bag interface where it deviates from Collection
- see if MultiMap code on bugzilla can be integrated
Henri has volunteered to do the actual final builds and release to
Minatour/Mirrors, but (unless someone objects) I will manage the
release.
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] ObservedCollection checkin
Just a minor quibble, why past tense (Observed) instead of adjective (Observable, Serializable, Unmodifiable, Cursorable, c.)? michael On Thu, 28 Aug 2003, Stephen Colebourne wrote: First part of ObservedCollection checked in, allowing an event sending wrapper to be written around a collection. TODO: - Validate that the design is OK - Implement ObservedList subList - Test List iterators - Add Bag, SortedSet, SortedBag implementations - Add Fast event mechansim - Add Rich event mechanism Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] ObservedCollection checkin
What about
StandardModificationListener
{
void modificationOccurred(Evt);
}
VetoableModificationListener
{
void modificationOccurring(Evt) throws ModificationVetoedException;
}
and
ObservedCollection
{
static ObservedCollection decorate(Collection coll,
VetoableModificationListener l) {}
static ObservedCollection decorate(Collection coll,
StandardModificationListener l) {}
}
instead of
StandardModificationListener
{
void modificationOccurred(Evt);
void modificationOccurring(Evt) throws ModificationVetoedException;
}
and
ObservedCollection
{
static ObservedCollection decorate(Collection coll,
StandardModificationListener l) {}
static ObservedCollection decoratePostEventsOnly(Collection coll,
StandardModificationListener l) {}
}
?
michael
On Thu, 28 Aug 2003, Stephen Colebourne wrote:
First part of ObservedCollection checked in, allowing an event sending
wrapper to be written around a collection.
TODO:
- Validate that the design is OK
- Implement ObservedList subList
- Test List iterators
- Add Bag, SortedSet, SortedBag implementations
- Add Fast event mechansim
- Add Rich event mechanism
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] ObservedCollection checkin
On Thu, 28 Aug 2003, Michael Heuer wrote:
What about
StandardModificationListener
{
void modificationOccurred(Evt);
}
VetoableModificationListener extends StandardModificationListener
{
void modificationOccurring(Evt) throws ModificationVetoedException;
}
sorry, missed an extends in there.
and
ObservedCollection
{
static ObservedCollection decorate(Collection coll,
VetoableModificationListener l) {}
static ObservedCollection decorate(Collection coll,
StandardModificationListener l) {}
}
instead of
StandardModificationListener
{
void modificationOccurred(Evt);
void modificationOccurring(Evt) throws ModificationVetoedException;
}
and
ObservedCollection
{
static ObservedCollection decorate(Collection coll,
StandardModificationListener l) {}
static ObservedCollection decoratePostEventsOnly(Collection coll,
StandardModificationListener l) {}
}
?
michael
On Thu, 28 Aug 2003, Stephen Colebourne wrote:
First part of ObservedCollection checked in, allowing an event sending
wrapper to be written around a collection.
TODO:
- Validate that the design is OK
- Implement ObservedList subList
- Test List iterators
- Add Bag, SortedSet, SortedBag implementations
- Add Fast event mechansim
- Add Rich event mechanism
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] RuntimeExceptions, assertions, and pluggable validation
On Tue, 26 Aug 2003, David Graham wrote:
--- __matthewHawthorne [EMAIL PROTECTED] wrote:
I've been thinking about RuntimeExceptions and assertions...
Intro
A RuntimeException is typically thought of as a way to indicate misuse
of a
particular method. As I've always seen it, it is not meant to be
caught.
The majority of methods that I write include an initial block which
validates
the arguments, such as:
public void doSomethingWith(Object o) {
if(o == null) {
throw new IllegalArgumentException(Object cannot be
null.);
}
}
I think this is OK, but there are some people who believe that even this
is
overkill. If I were to abandon the null check, a NullPointerException
would be
thrown which would indicate the same thing - programmer error.
NPE exists so that you don't have to code those boring null checks in all
your code. It is indeed overkill to throw IllegalArgumentException for
null parameters. Further, the standard Java classes use NPE to indicate
programmer error.
I don't agree with this -- there are often conditions where passing in
null for one method will not throw an NPE until it is accessed in a
different method. This can be difficult to track down, especially in a
third party library.
I think IAE, or better yet o.a.c.l.NullArgumentException is useful in
many cases.
michael
The flaw that I see in this is the lack of details about the error. A
NullPointerException with a line number is useless to somebody who does
not have
access to the source code.
The stack trace provides enough details to debug the source of the error.
It is not useless to someone without the source because their offending
method call will be somewhere in the trace, instantly locating the
problem.
There is also a certain degree of confusion
as to
where the error lies. If my code calls apache code which calls sun
code, who is
responsible?
You are. If you pass null to a method that doesn't explicitly state that
null is allowed it's your error.
Idea
I like Java 1.4's assertion system, especially the ability the turn the
assertions on or off for certain packages. I would like to be able to
provide
similar functionality that allows for more flexibility in the error
handling,
which could be especially useful in pre-1.4 code.
Here's a rough idea:
class AsserterFactory
Asserter getAsserter(String name)
interface Asserter
void assertTrue(boolean condition, String message)
class Java14Asserter
void assertTrue(boolean condition, String message)
assert condition : message;
class StandardAsserter
void assertTrue(boolean condition, String message)
if(!condition) {
throw new IllegalArgumentException(message)
}
class PassiveAsserter
void assertTrue(boolean condition, String message) {
// Does nothing
}
The asserter name could be a package name, a class name, or some other
type of
identifier. The configuration of these details may require system
properties
or a default asserter.properties file to set up different asserters.
I can think of 2 difficulties presented by this approach, more
specifically,
with the dynamic nature of the RuntimeExceptions that a method may
throw.
1) Unit tests catch RuntimeExceptions to validate method behavior,
if assertions
were pluggable, switching them would cause a lot of tests to fail.
2) The RuntimeExceptions that a method throws could not be
documented.
Conclusion
Any thoughts or ideas? Repetitive coding of validation and
exception handling is starting to make me think that there is a better
way.
The better (and standard) way is to utilize NPE.
There are even similar examples in [lang], where null-handling had to be
updated for tens of methods at a time.
This is a known drawback in libraries that choose to check for null
instead of allowing the runtime to throw NPE.
Imagine a similar concept, such as
Validator
validate(Object o)
StringValidator
validate(Object o) {
String s = (String)o
// Validate s
}
Where users could supply their own validator:
StringUtils.setValidator(StringValidator v)
and be guaranteed that the validate method would be called on any String
that is
passed in.
Thanks in advance for any replies, my apologies for the chaos.
The proposed solution is much worse than the perceived problem. Java
programmers instantly know how to debug a NPE in a stack trace. Adding
some convoluted
Re: [lang] RC3 util package UUID issue
On Tue, 19 Aug 2003, Stephen Colebourne wrote: The discussion over UUID makes me nervous. It has been suggested that UUID, together with the rest of the id stuff goes into a new identifier subpackage. This makes sense. However, it is unreasonable of us to release a new package, and then deprecate it in the next release (2.1). It also raises the question of whether the other two util package classes (BitField and Validate) should be in the main lang package instead. (What does util mean?) Solutions: 1) Release as is, we can't predict the future 2) Don't release entire util subpackage 3) Delete util subpackage. Move BitField and Validate to main lang package. Create identifier subpackage for ids. Release 2.0. 4) Delete util subpackage. Move BitField and Validate to main lang package. Release 2.0 without ids. Non-binding vote of course, but I think this is the best way to go. A package lang.util doesn't make all that much sense, and it'd be nice to get 2.0 out. michael IMHO #1 may tie us to a util subpackage, which I don't like, so #2 is better. #3 is good, but I prefer #4 overall while ids are up in the air - it gives us more design flexibility. Stephen (who is now getting very tired of 2.0...) - Original Message - From: Henri Yandell [EMAIL PROTECTED] http://www.apache.org/~bayard/commons-lang-2.0-rc3/ Changes I know of: Some javadoc WordWrapUtils fixed, renamed to WordUtils and with some of StringUtils code All .zip files should have text files in DOS CRLF format I'm sure there were other ones though. Let's give these a couple of days to see if anyone has any problems with them. 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: [collections] NotifyingCollections - capturing rich non-uniformdata
Let me say that I don't find major flaws with either Neil's or Stephen's approaches. I think both will support my two use cases, as follows 1. Efficient and simple notification of changes in a Collection so that user interface views may refresh. Any detailed information about the change, if necessary, can be calculated by the listener (the view in this case) by comparing the new event source to an old(er) cached one. 2. Enabling a listener to record changes made to a Collection (the buzzword is provenance I guess), who made the change, timestamp, etc. Again, detailed information about the change itself is not very important. I guess that means I'm backing out of the discussion, and will adapt to whatever design comes out of this. :) michael On Thu, 14 Aug 2003, Stephen Colebourne wrote: Been busy with [lang]anyway There are various issues with designing an event system that bering the three approaches into conflict: 1) Listener methods - [neil] One Listener method, different event types [michael] Many Listener methods, one event type [stephen] Favour one method, but What if the user doesn't want a listener? 2) Event classes - [neil] Very simple + Detail in OO hierarchy [michael] Standard, as detailed as possible [stephen] Standard, as detailed as possible, but What if the user wants full detail to allow for undo? 3) OO/Patterns - [neil] Follow OO guidelines, type hierarchies, factories, etc. [michael] Simple solution to get job done [stephen] Basic solution, not much OO, but... What if the user want a more OO solution? Now you may think that #3 is a repeat of #2, but I added it as it is clear that there is a difference in programming approach between Neil and myself. I am not greatly in love with OO. It has its moments of convenience, but I do not really buy into it. (Many commons committers are like this, as commons libraries tend not to be terribly fancy OO designs). Thus #3 is included because I want to note that if I commit a final solution, it won't necessariily be overly OO, just practical. #1 is a straight choice, in theory. #2 is a choice too, simple or detailed. Except that too much constriction is placed by the NotifyingCollections design. What if I want to have events recieved without writing a Listener implementation and registering it. Can I? What if I want events that tell you as much as possible, but not enough to support undo? The design I posted before http://www.scolebourne.eurobell.co.uk/Observed2.zip delegates ALL aspects of the event handling to another object. That object MIGHT be the standard one that calls Listeners. OR it might be one that logs calls directly. OR it might call a method on another object directly (no listener). This is much more flexible. The same handler also enables the factory behaviour from NotifyingCollections without being so explicit. The factory from NotifyingCollections limits the arguments that can be passed into the event object. The ObservedCollection handler creates the event object itself, so can do what it likes, allowing some very flexible possibilities. (eg. creating a handler that is linked to multiple lists and updates one based on changes to another while applying filtering) The default ObservedCollection event stores as much data as possible for List, Collection (Map/Set/Bag can be added). It does not attempt to store absolute data about the change, so an undo facility is not possible. In other words, the single event class is not trying to compete with the hierarchy like for like. Is this anti-OO. Yes, I expect so. But so is the Collections API in that it has UnsupportedOperationException. Typecasting is a pain however you try and look at it. The conflict between the rich hierarchy [neil] and the 'rich as possible monolithic' [stephen/michael] is most acute in defining which is the base event class for the listener. The solution is to not have the conflict - ObservedCollections allows one handler for monolithic that specifies one Listener that is passed a monolithic event, whereas for rich events a separate handler, with a separate Listener that is passed the rich event abstract base event type can be used. Two handlers, two listeners, one for each problem solution. The biggest problem with all this is that the collection returned by getSource() on the event. If the observed collection is wrapped (eg. by a SyncronizedCollection) then getSource() SHOULD return the wrapped collection, but it can't as it doesn't know about it. This problem applies to all designs so far. Stephen - Original Message - From: Neil O'Toole [EMAIL PROTECTED] [stephen] My goals for [collections] is to add something small and simple that doesn't prevent a user adding something more complex. [michael] I think I would prefer multiple listener interfaces and a simple event to a single listener interface and either a hierarchy of event
Re: [collections] NotifyingCollections - capturing rich non-uniformdata
On Thu, 14 Aug 2003, Stephen Colebourne wrote:
snip
The biggest problem with all this is that the collection returned by
getSource() on the event. If the observed collection is wrapped (eg. by a
SyncronizedCollection) then getSource() SHOULD return the wrapped
collection, but it can't as it doesn't know about it. This problem applies
to all designs so far.
Is this also a problem? It's general to all of the delegation
implementations.
private boolean heardChange = false;
public void testChangeToBackingCollection()
{
Collection c = new ArrayList();
ObservableCollection oc = CollectionUtils.observableCollection(c);
oc.addListener(new CollectionListener()
{
public void changed(CollectionEvent e) { heardChange = true; }
});
c.add(hello);
assertTrue(heardChange == true, heardChange == true);
}
I don't think it's possible to make this test pass -- just a
shortcoming of the wrapper design. That's why I was looking into
aspect-based implementations.
michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [io][vote] FileUtils: decision on style
On Tue, 29 Jul 2003, David Graham wrote: --- Arun Thomas [EMAIL PROTECTED] wrote: Hmmm From the last three notes - I think I understand clearly the motivation for requiring the public no-arg constructor, but I still don't understand the reasoning behind the need for avoiding final. The only reason I can see (with possibly poor vision) is to allow access to the methods of the utility class plus additional specific methods with a handle on only one class object or utility instance (of the subclass utility). This seems to me to be very poor design if such a constraint exists. Can anyone see any other value to extending utility classes with entirely static methods? Because static methods can't be overridden you may as well declare them final. However, static methods are truly evil. As soon as you think no one will ever need to override the behavior, some user will come along with a need to do so. This happened in Struts and now we're replacing all the static methods with Singleton classes with instance methods. Is the struts mailing list the best place to go archive-digging on this topic? At first glance I don't really see the `need to override behavior' argument -- if a user doesn't like the way a static method is implemented, can't they just implement their own in a separate class? michael David Cheers, -AMT -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 11:44 AM To: Jakarta Commons Developers List Subject: RE: [io][vote] FileUtils: decision on style --- Arun Thomas [EMAIL PROTECTED] wrote: Can someone expound on this lesson? The Developers Guide mentions neither the rule that final should be avoided, nor the rule that a public constructor is required. I'd love to know the reasoning - is there some reason that actually derives from the constraints of lang, or is it due to constraints on how other systems use lang? I'm particularly confounded by why the use of final would be a problem. Marking a class as final prevents subclassing which is an extraordinarily bad idea in generally available framework classes. This also goes for methods. Classes without default constructors are not JavaBeans and thus cannot be dynamically created and used in certain environments. David Cheers, -AMT -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 5:55 AM To: Jakarta Commons Developers List Subject: Re: [io][vote] FileUtils: decision on style On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote: Hey thanks for the heads up! being one of the original authors/contributor of this class, I do have some comments (mostly in favour of your proposal)... 1rst: you seem to have added a private constructor to prevent instantiation, which hurts usage as in velocity, where you need an instance of a class to allow the introspection to work. I'm -1 for that change in CVS. Yep. This is a Lang-lesson. Have an empty constructor in every 'Utils' class which mentions in a javadoc that this is not intended to be used: /** * pcodeObjectUtils/code instances should NOT be constructed in * standard programming. Instead, the class should be used as * codeObjectUtils.defaultIfNull(a,b);/code./p * * pThis constructor is public to permit tools that require a JavaBean instance * to operate./p */ Also worth looking at and maybe adopting the relatively simple: DEVELOPERS-GUIDE.html in Lang. Mainly it just outlines the XxxUtils philosophy. Also don't make XxxUtils a final class. 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] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] DEVELOPERS-GUIDE.html
Maybe we just try to convince the author(s) of UString to donate their
additional String-related static utility methods to the Jakarta Commons
project? ;)
Overriding utility classes just seems icky to me.
michael
On Tue, 29 Jul 2003, Henri Yandell wrote:
However, the following would work:
UString ustring = new UString(foo);
ustring.capitalise();
if UString had:
...extends StringUtils...
public void capitalise() {
this.myStr = capitalise(this.myStr);
}
Not sure why someone would bother though :) Just as easy to do
StringUtils.capitalise in there.
Hen
On Tue, 29 Jul 2003, Gary Gregory wrote:
Ah, but not really... ;-)
A subclass cannot override methods that are declared static in the
superclass. In other words, a subclass cannot override a class method. A
subclass can /hide/ a static method in the superclass by declaring a static
method in the subclass with the same signature as the static method in the
superclass. Overriding only applies to instance methods, class methods
behave differently (ah, longing for Smalltalk). A class method can be
/shadowed/ by a subclass but not overridden (not to be confused with method
overloading of course ;-)
Here is a fun experiment with statics that always comes and bites you in the
you-know-where:
package test;
class SubC extends SuperC {
static String hi() {
return I am Sub;
}
}
class SuperC extends Object {
static String hi() {
return I am Super;
}
}
public class TestSuperStatic {
public static void main(String[] args) {
SuperC a = new SuperC();
SubC b = new SubC();
SuperC c = b;
System.out.println(a.hi() + , + a.getClass());
System.out.println(b.hi() + , + b.getClass());
System.out.println(c.hi() + , + c.getClass());
}
}
Can you guess what gets printed out? :-)
(and no cheating by running the code!)
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 14:30
To: Jakarta Commons Developers List
Subject: Re: [lang] DEVELOPERS-GUIDE.html
In this use case, everybody uses UString, so you can effectively override.
If you code the same method in the 'subclass', and refer to it using the
subclass class then it will be called.
Stephen
- Original Message -
From: Gary Gregory [EMAIL PROTECTED]
When you do that, do remember that you cannot override static methods in
the
same way that you can with instance methods.
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 14:07
To: Jakarta Commons Developers List
Subject: Re: [lang] DEVELOPERS-GUIDE.html
Because I want to create a subclass of StringUtils.
Use case:
I curently have a string utility class named UString.
I plan to change that to extend StringUtils once 2.0 is released.
(Because I'll get lots of extra methods for free)
But I can only do that if StringUtils is not final.
Stephen
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 7:46 PM
Subject: Re: [lang] DEVELOPERS-GUIDE.html
Question just came up on [io].
Why do we not make our XxxUtil classes final again? :) Anyone remember
or
should I trawl through the mail from last year?
Hen
On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote:
Plus1
Stephen
from:Henri Yandell [EMAIL PROTECTED]
date:Tue, 29 Jul 2003 14:00:23
to: [EMAIL PROTECTED]
subject: Re: [lang] DEVELOPERS-GUIDE.html
Just noticed that DEVELOPERS-GUIDE.html doesn't mention whether our
XxxUtils class should be final or not. I'm pretty sure we ended up
making
them not final. Anyone object to this before I add a line to the
guide?
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
