[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 {
^
[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]
[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]
[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]
[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]
[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
[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]
