cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-5353) abstract for client/driver reuse
Date Wed, 20 Nov 2013 08:29:30 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne resolved CASSANDRA-5353.
-----------------------------------------

    Resolution: Won't Fix

Let's close that one. Just putting all the current dependencies of the transport package in
the client-util jar is not very useful imho because, as said in the description, it's a whole
lot of dependency (which would also make it hard to know when we add more dependencies).

Refactoring the transport package to be more reusable is not crazy in itself, if only for
the sake of modularity, but it's quite a bit of work in practice (and not particularly fun
one). So I'm not sure it's really worth the trouble.

Regarding the DataStax Java driver, we ended up pulling the transport bits inside the driver
(as this was just simpler for the reasons described above) so it doesn't have any dependency
on Cassandra whatsoever and doesn't care about this ticket.

> abstract for client/driver reuse
> --------------------------------
>
>                 Key: CASSANDRA-5353
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5353
>             Project: Cassandra
>          Issue Type: Bug
>          Components: API, Core, Drivers (now out of tree)
>    Affects Versions: 1.2.2
>            Reporter: Eric Evans
>              Labels: cql3, native_protocol
>
> The native transport CQL driver ["Java Driver"|https://github.com/datastax/java-driver]
has a maven pom which declares a dependency on the {{cassandra-all}} artifact (aka Everything).
This is Bad because Cassandra makes use of many common libraries, making conflicts with client
applications inevitable.
> Some of [java-driver|https://github.com/datastax/java-driver]'s uses can be avoided,
I think.  For example, it seems to use the {{AbstractType}} extending classes in {{org.apache.cassandra.db.marshal}}
instead of the classes included in the {{cassandra-clientutil}} artifact ({{org.apache.cassandra.cql.jdbc}}).
 I will file a separate Github issue for that.  The rest of its usage looks something like
the following:
> * org.apache.cassandra.db.marshal.*
> * org.apache.cassandra.exceptions.*
> * org.apache.cassandra.transport.Message;
> * org.apache.cassandra.transport.messages.ErrorMessage
> * org.apache.cassandra.transport.messages.ExecuteMessage
> * org.apache.cassandra.transport.messages.PrepareMessage
> * org.apache.cassandra.transport.messages.QueryMessage
> * org.apache.cassandra.transport.messages.ResultMessage
> * org.apache.cassandra.service.ClientState
> * org.apache.cassandra.transport.*  ??
> * org.apache.cassandra.transport.ConsistencyLevel  ??
> * org.apache.cassandra.transport.Event  ??
> * org.apache.cassandra.cql3.ColumnSpecification
> * org.apache.cassandra.utils.MD5Digest
> Ostensibly the solution would be to move what's needed into clientutil jar, but this
will likely require significantly more.  For example, grepping imports on the {{o.a.c.transport}}
package yields the following:
> * org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor
> * org.apache.cassandra.concurrent.NamedThreadFactory
> * org.apache.cassandra.config.DatabaseDescriptor
> * org.apache.cassandra.config.EncryptionOptions
> * org.apache.cassandra.cql3.ColumnSpecification
> * org.apache.cassandra.cql3.CQLStatement
> * org.apache.cassandra.cql3.QueryProcessor
> * org.apache.cassandra.cql3.ResultSet
> * org.apache.cassandra.db.ConsistencyLevel
> * org.apache.cassandra.db.marshal.*
> * org.apache.cassandra.db.marshal.Int32Type
> * org.apache.cassandra.db.marshal.TypeParser
> * org.apache.cassandra.db.marshal.UTF8Type
> * org.apache.cassandra.db.WriteType
> * org.apache.cassandra.security.SSLFactory
> * org.apache.cassandra.service.CassandraDaemon
> * org.apache.cassandra.service.ClientState
> * org.apache.cassandra.service.IEndpointLifecycleSubscriber
> * org.apache.cassandra.service.IMigrationListener
> * org.apache.cassandra.service.MigrationManager
> * org.apache.cassandra.service.QueryState
> * org.apache.cassandra.service.StorageService
> * org.apache.cassandra.tracing.Tracing
> * org.apache.cassandra.utils.FBUtilities
> * org.apache.cassandra.utils.MD5Digest
> * org.apache.cassandra.utils.Pair
> * org.apache.cassandra.utils.SemanticVersion
> And it's probably much worse once transitive dependencies are taken into account.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message