[
https://jira.jboss.org/jira/browse/DNA-192?page=com.atlassian.jira.plugin...
]
Randall Hauch commented on DNA-192:
-----------------------------------
Renamed the "org.jboss.dna.spi.graph.connection" package to
"org.jboss.dna.spi.connector", and removed the notion of a
RepositoryConnectionFactory and a ManagedRepositoryConnectionFactory. Instead,
RepositorySource now defines all of the methods previously inherited, and
RepositoryConnectionPool no longer inherits any interfaces and defines its own
ConnectionFactory interface that only it uses. RepositoryConnectionFactories was renamed
to RepositorySourceRegistry, and its single method was changed to use RepositorySource
rather than a RepositoryConnectionFactory. AbstractRepositorySource now properly
implements Serializable methods to rebuild the pool upon deserialization. Several of the
RepositoryOperation interfaces were moved to the test source, since they're only used
in the test harness.
Numerous files were touched because of the package and class renaming/refactoring.
Clean up the repository connector SPI
-------------------------------------
Key: DNA-192
URL:
https://jira.jboss.org/jira/browse/DNA-192
Project: DNA
Issue Type: Task
Components: Connectors, SPI
Affects Versions: 0.2
Reporter: Randall Hauch
Fix For: 0.2
The current SPI is somewhat confusing, especially the distinction between
RepositoryConnectionFactory and RepositorySource, and what the meaning of the
RepositoryConnectionFactories interface is. The original idea was to pattern after JDBC
DataSource, but a number of things are not handled well in DataSource (like connection
pooling, which is done above the sources). Plus, the current design extracted interfaces
when there was similar behavior/methods rather than designing the interfaces to be easily
understood and used, and this resulted in some confusing names and concepts that
overlapped or were too generic.
There should be a RepositorySource interface that defines all of the methods: getName(),
getConnection(), and the management methods like shutdown(), shutdownNow(), isShutdown(),
isTerminated(), awaitTermination(), etc. Also, if a RepositorySource would benefit from
pooling connections, it should implement the pooling and can include any pooling
parameters in the source's JavaBean properties. This means that no pooling is ever
done above the RepositorySource, and that the RepositorySource bean properties fully
specify and control the behavior of the source.
To make it easier to implement RepositorySource with pooling, the
RepositoryConnectionPool class should be kept but should not share any interfaces, and an
AbstractRepositorySource implement most of the RepositorySource functionality by
delegating to a pool that it owns and manages.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira