Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.0
    • Component/s: None
    • Labels:
      None

      Description

      The fact that there are output/fault/exception could be confusing and clutter the dsl, especially for components where there is no distinction between fault and exception. We should merge the two and simplify the model.

      See nabble thread:
      http://www.nabble.com/in-out-fault-messages-discussion-to14170013s22882.html#a14170013

        Activity

        Hide
        Hadrian Zbarcea added a comment -

        Let's see if we can do anything about this one in 1.5.

        I propose to:

        • not change the api
        • deprecate faults
        • consider faults outputs (not camel exception) and
          1. faults are outputs of java.lang.Exception subtype always
          2. fault are outputs of any type, but have a header (say "camel-fault" = true) to indicate their fault semantic
          3. faults are of type exception and have the fault header
        • on fault the pipeline is interrupted (faults do not get sent to next processor)
        • keep the current mechanism - handleFault() - to handle faults as exceptions, in which case faults become exceptions and the error handler applies.

        We could then remove the fault api in 2.0. I'd love some feedback on this one.

        Show
        Hadrian Zbarcea added a comment - Let's see if we can do anything about this one in 1.5. I propose to: not change the api deprecate faults consider faults outputs (not camel exception) and 1. faults are outputs of java.lang.Exception subtype always 2. fault are outputs of any type, but have a header (say "camel-fault" = true) to indicate their fault semantic 3. faults are of type exception and have the fault header on fault the pipeline is interrupted (faults do not get sent to next processor) keep the current mechanism - handleFault() - to handle faults as exceptions, in which case faults become exceptions and the error handler applies. We could then remove the fault api in 2.0. I'd love some feedback on this one.
        Hide
        Jonathan Anstey added a comment -

        3. faults are of type exception and have the fault header

        +1 - I think it may just be confusing to the user if you can have any object be a fault. So, having the mandatory Exception type would be good. The fault header would be needed too I think since there wouldn't be another way of determining whether an output was a fault or not.

        The rest of the proposal sounds good to me.

        Show
        Jonathan Anstey added a comment - 3. faults are of type exception and have the fault header +1 - I think it may just be confusing to the user if you can have any object be a fault. So, having the mandatory Exception type would be good. The fault header would be needed too I think since there wouldn't be another way of determining whether an output was a fault or not. The rest of the proposal sounds good to me.
        Hide
        Claus Ibsen added a comment -

        +1 to #3

        I suggest to use a header without any minus or dot. We have trouble with these already. And we consider using a new pattern for Camel 2.0 that James suggested:
        "CamelFault" is a better header name.

        BTW: We also have a throwFault DSL.

        Show
        Claus Ibsen added a comment - +1 to #3 I suggest to use a header without any minus or dot. We have trouble with these already. And we consider using a new pattern for Camel 2.0 that James suggested: "CamelFault" is a better header name. BTW: We also have a throwFault DSL.
        Hide
        Hadrian Zbarcea added a comment -

        The only difference between #1 and #3 is the header. Assuming that normal outputs cannot be of java.lang.Exception type, which is I think pretty reasonable, there is no difference between the two. I have however an amendment for #3:

        #4. faults are of type java.lang.Exception and a header CamelFaultOrigin=<url>.

        The header's mere presence is equivalent with CamelFault=true, as proposed in #3, but also gives a hint of what endpoint produced the fault. We may need more details about the fault.

        Show
        Hadrian Zbarcea added a comment - The only difference between #1 and #3 is the header. Assuming that normal outputs cannot be of java.lang.Exception type, which is I think pretty reasonable, there is no difference between the two. I have however an amendment for #3: #4. faults are of type java.lang.Exception and a header CamelFaultOrigin=<url>. The header's mere presence is equivalent with CamelFault=true, as proposed in #3, but also gives a hint of what endpoint produced the fault. We may need more details about the fault.
        Hide
        Claus Ibsen added a comment -

        Hadrian, others

        Do we want to do this? We havent started on this for 2.0.

        Any thoughts?

        Show
        Claus Ibsen added a comment - Hadrian, others Do we want to do this? We havent started on this for 2.0. Any thoughts?
        Hide
        Claus Ibsen added a comment -

        We never got this addressed in Camel 2.0 timeframe.

        If really needed we can address or look at it again in Camel 3.0 or later.

        Show
        Claus Ibsen added a comment - We never got this addressed in Camel 2.0 timeframe. If really needed we can address or look at it again in Camel 3.0 or later.
        Hide
        Hadrian Zbarcea added a comment -

        I think we should tackle this in 2.0. I will look at it again this weekend.

        Show
        Hadrian Zbarcea added a comment - I think we should tackle this in 2.0. I will look at it again this weekend.
        Hide
        Claus Ibsen added a comment -

        Hadrian, I think its very late, and unless the change have minimal impact on eg SMX then its possible otherwise I would like to leave as is.

        If we remove fault all together there is quite some code that depends on it, and how does SMX handle this?

        We are pushing the last must have for Camel 2.0 to get it done in due time, eg hopefully in 2-3 weeks.

        Show
        Claus Ibsen added a comment - Hadrian, I think its very late, and unless the change have minimal impact on eg SMX then its possible otherwise I would like to leave as is. If we remove fault all together there is quite some code that depends on it, and how does SMX handle this? We are pushing the last must have for Camel 2.0 to get it done in due time, eg hopefully in 2-3 weeks.
        Hide
        Claus Ibsen added a comment -

        Now that we will do a 2.0M2 we have more time to rework the FAULT stuff in Camel 2.0 API

        Show
        Claus Ibsen added a comment - Now that we will do a 2.0M2 we have more time to rework the FAULT stuff in Camel 2.0 API
        Hide
        Claus Ibsen added a comment -

        Moving to future as we do not have time to get over this in Camel 2.x

        Show
        Claus Ibsen added a comment - Moving to future as we do not have time to get over this in Camel 2.x
        Hide
        Claus Ibsen added a comment -

        We have opened this discussion again and looks like we agree on proposal #3
        http://www.nabble.com/-DISCUSS--Faults-and-Exceptions-in-Camel-td24398169s22882.html

        Hadrian I assume you can make the needed API changes related to Fault?

        Show
        Claus Ibsen added a comment - We have opened this discussion again and looks like we agree on proposal #3 http://www.nabble.com/-DISCUSS--Faults-and-Exceptions-in-Camel-td24398169s22882.html Hadrian I assume you can make the needed API changes related to Fault?
        Hide
        Hadrian Zbarcea added a comment -

        Fix committed, awaiting wiki updates.

        Show
        Hadrian Zbarcea added a comment - Fix committed, awaiting wiki updates.
        Hide
        Hadrian Zbarcea added a comment -

        Release Notes updated.

        Show
        Hadrian Zbarcea added a comment - Release Notes updated.

          People

          • Assignee:
            Hadrian Zbarcea
            Reporter:
            Hadrian Zbarcea
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development