Mule

Rename default-component-exception-strategy to default-service-exception-strategy

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.0-M2
  • Fix Version/s: 2.0.0-RC1
  • Component/s: Core: Configuration
  • Labels:
    None
  • User impact:
    Low
  • Similar Issues:
    MULE-14 Default exception strategy on the Model
    MULE-3128 Improve the <default-exception-strategy> configuration
    MULE-5731 "default-service-exception-strategy" is permitted in flows
    MULE-5269 Clean up exception strategy schema elements after exception strategy work in core
    MULE-4515 default-service-exception-strategy does not honor exception-type-filter
    MULE-4341 Transformerconfigured on an endpoint in exception-strategy are ignored
    MULE-5895 As a user I want to be able to define a custom default exception strategy that is used when a a flow or service does not define one explicitly
    MULE-3181 Default Component Exception Strategy being thrown on wrong component
    MULE-5738 When configuring <default-exception-strategy> inbound transaction is committed by default when no commit or rollback pattern is configured
    MULE-5342 message-filter throwOnUnaccepted=true not handled by default-exception-strategy

Activity

Hide
andrew cooke added a comment - 20/Nov/07 07:44 AM

there's also threading elements that might need renaming, but they need documenting first.

Show
andrew cooke added a comment - 20/Nov/07 07:44 AM there's also threading elements that might need renaming, but they need documenting first.
Hide
andrew cooke added a comment - 20/Nov/07 09:31 AM

threading:

  • inside configuration element (singletons in registry, available via MuleConfiguration)
  • default-threading-profile
  • default-dispatcher-threading-profile
  • default-receiver-threading-profile
  • default-component-threading-profile
    last three chain to default-threading-profile for defaults. updates in config modify values,
    overwriting rather than defining a new instance.
  • inside service element:
  • threading-profile defaults taken from default-component-threading-profile
    set on SedaComponent (which is the service). used to create work manage for component.
  • inside connector element:
  • dispatcher-threading-profile defaults taken from default-dispatcher-threading-profile
  • receiver-threading-profile defaults taken from default-receiver-threading-profile
    set on AbstractComponent. used to create UMOWorkManager instances

so, in conclusion, changed threading-profile to component-threading-profile so that it was consistent with the default. did not change to service because "service = component + receiver + dispatcher".

Show
andrew cooke added a comment - 20/Nov/07 09:31 AM threading:
  • inside configuration element (singletons in registry, available via MuleConfiguration)
  • default-threading-profile
  • default-dispatcher-threading-profile
  • default-receiver-threading-profile
  • default-component-threading-profile last three chain to default-threading-profile for defaults. updates in config modify values, overwriting rather than defining a new instance.
  • inside service element:
  • threading-profile defaults taken from default-component-threading-profile set on SedaComponent (which is the service). used to create work manage for component.
  • inside connector element:
  • dispatcher-threading-profile defaults taken from default-dispatcher-threading-profile
  • receiver-threading-profile defaults taken from default-receiver-threading-profile set on AbstractComponent. used to create UMOWorkManager instances
so, in conclusion, changed threading-profile to component-threading-profile so that it was consistent with the default. did not change to service because "service = component + receiver + dispatcher".

People

Vote (0)
Watch (0)

Dates

  • Created:
    20/Nov/07 06:12 AM
    Updated:
    20/Nov/07 09:31 AM
    Resolved:
    20/Nov/07 09:31 AM