You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2019/12/06 19:19:21 UTC

[GitHub] [camel-quarkus] ppalaga commented on issue #521: Fix #74 Telegram extension

ppalaga commented on issue #521: Fix #74 Telegram extension
URL: https://github.com/apache/camel-quarkus/pull/521#issuecomment-562703223
 
 
   > 1. we should not have duplicated components as it is a source of confusion and it increases the maintenances cost
   
   I agree that not having duplicated code is a good thing and I agree that as much code as possible from this PR needs to get ported to Camel. Whether all or just part and which parts of the component code should go to Camel is an open question for me and I'd like to reach some agreement before I spend time with the porting.
   
   At the same time, as many of you may know, having a Telegram extension is handy when presenting. So I vote for temporarily hosting the duplicated component here.
   
   > 2. this PR brings RESTEasy and MP Rest Client and it would be better to just use RESTEasy as we had a long discussion about bringing full RESTEasy client support in Quarkus
   
   No problem, let me try that.
   
   > 3. I'd would have done in the opposite way like making the camel-telegram pluggable and only after that creating the extension here as it make much easier to understand and review the changes that are required
   
   That would be more work for me, esp. when requests like 2. appear during the review. So I chose not to go that far in the first iteration.
   
   ### Pluggability: yes or no?
   
   Yes, the component may be made pluggable to allow for running with both CXF and RestEasy REST client. But I'd like us all to think once again whether it is a good idea to support two equivalent rest clients. That's more code, more bugs and more maintenance than having just one client. Do we really want to do that and can't we come up with any solution without the pluggability?
   
   I can see these options:
   
   #### A. Replace the CXF client with RestEasy: 
   
   Reasons: The rest client is just an implementation detail. End users should not notice the change. The CXF client does not work OotB on Quarkus and it is safer for us to use libs that are known to work there.
   
   There is also @oscerd 's statement in [CAMEL-13903](https://issues.apache.org/jira/browse/CAMEL-13903?focusedCommentId=16914300&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16914300)
   
   #### B. Replace the CXF client with bare Apache HTTP client and Jackson.
   
   That's basically, what both the CXF client and RestEasy client are using under the hood. There is just a handful of endpoints to cover. It would be a bit more code in the component, but less dependencies.
   
   WDYT?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services