Well I have implemented something like the Version checking before, so I would 
opt to take care of that.

I would define an Annotation with an optional "from" and "to" version ... you 
could use that 
I would need something that provides the version of the server from your side.

With this I would then implement an Aspect that intercepts these calls, does 
the check and eventually throws Exceptions with a message what the minimum or 
maximum version for a feature would be.

I would use a compile-time weaver as this does not add any more dependencies or 
setup complexity to the construct.

Any objections to this approach?

Chris


´╗┐Am 13.03.18, 03:06 schrieb "vino yang" <yanghua1...@gmail.com>:

    Hi Chris,
    
    It looks like a good idea. I think to finish this job, we can split it into
    three sub tasks:
    
       - upgrade kafka version to 1.x and test it to match the 0.8.x
       connector's function and behaivor;
       - Carding and defining the annotation which contains different kafka
       version and features
       - expose the new feature's API to user and check with annotation
    
    What's your opinion?
    
    
    2018-03-12 21:00 GMT+08:00 Christofer Dutz <christofer.d...@c-ware.de>:
    
    > Don't know if this would be an option:
    >
    > If we defined and used a Java annotation which defines what Kafka-Version
    > a feature is available from (or up to which version it is supported) and
    > then we could do quick checks that compare the current version with the
    > annotations on the methods we call. I think this type of check should be
    > quite easy to understand and we wouldn't have to build, maintain, test,
    > document etc. loads of separate modules.
    >
    > Chris
    >
    >
    >
    > Am 12.03.18, 13:30 schrieb "vino yang" <yanghua1...@gmail.com>:
    >
    >     Hi Chris,
    >
    >     OK, Hope for listening someone's opinion.
    >
    >     Vino yang.
    >
    >     2018-03-12 20:23 GMT+08:00 Christofer Dutz <christofer.d...@c-ware.de
    > >:
    >
    >     > Hi Vino,
    >     >
    >     > please don't interpret my opinion as some official project decision.
    >     > For discussions like this I would definitely prefer to hear the
    > opinions
    >     > of others in the project.
    >     > Perhaps having a new client API and having compatibility layers
    > inside the
    >     > connector would be another option.
    >     > So per default the compatibility level of the Kafka client lib would
    > be
    >     > used but a developer could explicitly choose
    >     > older compatibility levels, where we have taken care of the work to
    > decide
    >     > what works and what doesn't.
    >     >
    >     > Chris
    >     >
    >     >
    >     >
    >     > Am 12.03.18, 13:07 schrieb "vino yang" <yanghua1...@gmail.com>:
    >     >
    >     >     Hi Chris,
    >     >
    >     >     In some ways, I argee with you. Though kafka API has the
    >     > compatibility. But
    >     >
    >     >
    >     >        - old API + higher server version : this mode would miss some
    > key
    >     > new
    >     >        feature.
    >     >        - new API + older server version : this mode, users are in a
    > puzzle
    >     >        about which feature they could use and which could not. Also,
    > new
    >     > API will
    >     >        do more logic judgement and something else (which cause
    > performance
    >     > cost)
    >     >        for backward compatibility.
    >     >
    >     >     I think it's the main reason that other framework split
    > different kafka
    >     >     connector with versions.
    >     >
    >     >     Anyway, I will respect your decision. Can I claim this task 
about
    >     > upgrading
    >     >     the kafka client's version to 1.x?
    >     >
    >     >
    >     >     2018-03-12 16:30 GMT+08:00 Christofer Dutz <
    > christofer.d...@c-ware.de
    >     > >:
    >     >
    >     >     > Hi Vino,
    >     >     >
    >     >     > I would rather go a different path. I talked to some Kafka
    > pros and
    >     > they
    >     >     > sort of confirmed my gut-feeling.
    >     >     > The greatest changes to Kafka have been in the layers behind
    > the API
    >     >     > itself. The API seems to have been designed with backward
    >     > compatibility in
    >     >     > mind.
    >     >     > That means you can generally use a newer API with an older
    > broker as
    >     > well
    >     >     > as use a new broker with an older API (This is probably even
    > the
    >     > safer way
    >     >     > around). As soon as you try to do something with the API which
    > your
    >     > broker
    >     >     > doesn't support, you get error messages.
    >     >     >
    >     >     > https://cwiki.apache.org/confluence/display/KAFKA/
    >     > Compatibility+Matrix
    >     >     >
    >     >     > I would rather update the existing connector to a newer Kafka
    >     > version ...
    >     >     > 0.8.2.2 is quite old and we should update to a version of at
    > least
    >     > 0.10.0
    >     >     > (I would prefer a 1.x) and stick with that. I doubt many will
    > be
    >     > using an
    >     >     > ancient 0.8.2 version (09.09.2015). And everything starting
    > with
    >     > 0.10.x
    >     >     > should be interchangeable.
    >     >     >
    >     >     > I wouldn't like to have yet another project maintaining a Zoo
    > of
    >     > adapters
    >     >     > for Kafka.
    >     >     >
    >     >     > Eventually a Kafka-Streams client would make sense though ...
    > to
    >     > sort of
    >     >     > extend the Edgent streams from the edge to the Kafka cluster.
    >     >     >
    >     >     > Chris
    >     >     >
    >     >     >
    >     >     >
    >     >     > Am 12.03.18, 03:41 schrieb "vino yang" <yanghua1...@gmail.com
    > >:
    >     >     >
    >     >     >     Hi guys,
    >     >     >
    >     >     >     How about this idea, I think we should support kafka's new
    >     > client API.
    >     >     >
    >     >     >     2018-03-04 15:10 GMT+08:00 vino yang <
    > yanghua1...@gmail.com>:
    >     >     >
    >     >     >     > The reason is that Kafka 0.9+ provided a new consumer 
API
    >     > which has
    >     >     > more
    >     >     >     > features and better performance.
    >     >     >     >
    >     >     >     > Just like Flink's implementation :
    > https://github.com/apache/
    >     >     >     > flink/tree/master/flink-connectors.
    >     >     >     >
    >     >     >     > vinoyang
    >     >     >     > Thanks.
    >     >     >     >
    >     >     >     >
    >     >     >
    >     >     >
    >     >     >
    >     >
    >     >
    >     >
    >
    >
    >
    

Reply via email to