Camel
  1. Camel
  2. CAMEL-5172

TypeConverter - Tighten up API to rethrow failed exception during type conversion, and introduce new API for try to convert

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.8.5, 2.9.3, 2.10.0
    • Component/s: camel-core
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      The org.apache.camel.TypeConverter API would not propagate exceptions that would occur during type conversion back to the caller. But instead return null.

      We should tighten this up and introduce a new API for trying to convert, so what we would have is

      • convertTo = converts, and throws exception if failure during conversion, can return null, if no value to convert, or no type converter exists to do this
      • mandatoryConvertTo = convertTo + will throw exception if no value, eg it never returns null
      • new tryConvertTo = convertTo but will catch exceptions and return null (like the old behavior)

      This introduces an API change in TypeConverter. But it is more intuitive. There is some internal logic that needs to be adjust a bit due they rely on the old behavior.

        Issue Links

          Activity

          Hide
          Claus Ibsen added a comment -

          The Type Converter API has been adjust accordingly. Now the default behavior by the Camel type converter system, is to fail fast, and propagate exceptions back the the caller by default. You can use the new tryConvertTo to use the old behavior.

          Show
          Claus Ibsen added a comment - The Type Converter API has been adjust accordingly. Now the default behavior by the Camel type converter system, is to fail fast, and propagate exceptions back the the caller by default. You can use the new tryConvertTo to use the old behavior.
          Hide
          Claus Ibsen added a comment -

          Added TypeConverterSupport as base class to make it easier to implement custom TypeConverter

          Show
          Claus Ibsen added a comment - Added TypeConverterSupport as base class to make it easier to implement custom TypeConverter
          Hide
          Claus Ibsen added a comment -

          Backported to 2.8 branch as well.

          Show
          Claus Ibsen added a comment - Backported to 2.8 branch as well.
          Hide
          Babak Vahdat added a comment -

          Question:

          What was the reason to deprecate those 4 utility methods by:

          org.apache.camel.util.ExchangeHelper.getMandatory...Body()
          

          As to my understanding they provide an easy-to-use shorthand writing.

          Show
          Babak Vahdat added a comment - Question: What was the reason to deprecate those 4 utility methods by: org.apache.camel.util.ExchangeHelper.getMandatory...Body() As to my understanding they provide an easy-to-use shorthand writing.
          Hide
          Claus Ibsen added a comment -

          See the javadoc of these methods as the @deprecated refers to what to use instead.

          Show
          Claus Ibsen added a comment - See the javadoc of these methods as the @deprecated refers to what to use instead.
          Hide
          Babak Vahdat added a comment -

          Thanks for your reply but my question was why? Why to deprecate them as they do provide an easy-to-use shorthand writing. I mean instead of

          exchange.getOut().getMandatoryBody();
          

          We can simply say:

          ExchangeHelper.getMandatoryOutBody()
          

          So 1 method call chain instead of 2 ==> shorthand writing.

          Show
          Babak Vahdat added a comment - Thanks for your reply but my question was why ? Why to deprecate them as they do provide an easy-to-use shorthand writing. I mean instead of exchange.getOut().getMandatoryBody(); We can simply say: ExchangeHelper.getMandatoryOutBody() So 1 method call chain instead of 2 ==> shorthand writing.
          Hide
          Claus Ibsen added a comment -

          The main interaction for end users to the message, is using the Exchange and Message API from org.apache.camel package. So in this case when you want the message body and expects a message body to exists, then use getMandatoryBody() on the Message.

          The util classes is not primary intended for end users to use. But more for Camel itself, and Camel component developers etc.

          Also in your example its more cumbersome to use ExchangeHelper as you need to
          1. import the class
          2. pass in exchange as parameter, eg your example above is wrong

          This is not easier than just typing (no imports needed)

          exchange.getIn().getMandatoryBody();
          

          Also there is many classes in camel-core, and we should avoid having to many methods and APIs for end user to 'get lost in'. So its a good idea to @deprecate duplicates and whatnot.

          Show
          Claus Ibsen added a comment - The main interaction for end users to the message, is using the Exchange and Message API from org.apache.camel package. So in this case when you want the message body and expects a message body to exists, then use getMandatoryBody() on the Message. The util classes is not primary intended for end users to use. But more for Camel itself, and Camel component developers etc. Also in your example its more cumbersome to use ExchangeHelper as you need to 1. import the class 2. pass in exchange as parameter, eg your example above is wrong This is not easier than just typing (no imports needed) exchange.getIn().getMandatoryBody(); Also there is many classes in camel-core, and we should avoid having to many methods and APIs for end user to 'get lost in'. So its a good idea to @deprecate duplicates and whatnot.
          Hide
          Babak Vahdat added a comment -

          I still don't get the point but never mind.
          Thanks anyway for your clarifications.

          Show
          Babak Vahdat added a comment - I still don't get the point but never mind. Thanks anyway for your clarifications.
          Hide
          Babak Vahdat added a comment -

          Fair enough, I did already remove the usage of those utility methods, so that we've got:

          • Less JDK compiler warnings by now
          • Less cleanup work while working on the Camel 3.x release

          http://svn.apache.org/viewvc?view=revision&revision=1336558

          My personal vote for the deprecation of these utilities is -1... However now it's already too late for that

          Show
          Babak Vahdat added a comment - Fair enough, I did already remove the usage of those utility methods, so that we've got: Less JDK compiler warnings by now Less cleanup work while working on the Camel 3.x release http://svn.apache.org/viewvc?view=revision&revision=1336558 My personal vote for the deprecation of these utilities is -1... However now it's already too late for that
          Hide
          Christian Müller added a comment -

          Babak, please be careful with -1 votes on code modifications. -1 AND a comment "let's do it in your way" are contrary.
          Votes for code modifications are binding votes as described here [1]. This means some time in the future, where you may are a PMC and vote with -1, the committer has to convince you or he has to roll back the change.
          This NOT mean you should not express your meaning, but you should know what a -1 could imply in the future...

          [1] http://www.apache.org/foundation/voting.html

          Best,
          Christian

          Show
          Christian Müller added a comment - Babak, please be careful with -1 votes on code modifications. -1 AND a comment "let's do it in your way" are contrary. Votes for code modifications are binding votes as described here [1] . This means some time in the future, where you may are a PMC and vote with -1, the committer has to convince you or he has to roll back the change. This NOT mean you should not express your meaning, but you should know what a -1 could imply in the future... [1] http://www.apache.org/foundation/voting.html Best, Christian
          Hide
          Babak Vahdat added a comment -

          Christian, thanks for the hint & the link as well. Seems I have to be more careful while expressing myself as there seems to be a bit of politics while choosing the "wording".

          With "My personal vote" I did mean "My personal opinion" but according to the link you did provide it does really mean "voting"!

          Though still a question: I did also put some "funny" comments into CAMEL-4341 just for the sake of a relaxed atmosphere as well as good mood. Is there also something wrong with that as well?

          Show
          Babak Vahdat added a comment - Christian, thanks for the hint & the link as well. Seems I have to be more careful while expressing myself as there seems to be a bit of politics while choosing the "wording". With "My personal vote" I did mean "My personal opinion" but according to the link you did provide it does really mean "voting"! Though still a question: I did also put some "funny" comments into CAMEL-4341 just for the sake of a relaxed atmosphere as well as good mood. Is there also something wrong with that as well?
          Hide
          Christian Müller added a comment -

          Don't worry, there is nothing wrong to add comments to build "a relaxed atmosphere". We mostly like it.
          But the combination of the word "vote(s)" and "-1" should be used careful.

          Don't stop sharing your opinions!

          Best,
          Christian

          Show
          Christian Müller added a comment - Don't worry, there is nothing wrong to add comments to build "a relaxed atmosphere". We mostly like it. But the combination of the word "vote(s)" and "-1" should be used careful. Don't stop sharing your opinions! Best, Christian

            People

            • Assignee:
              Claus Ibsen
              Reporter:
              Claus Ibsen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development