Mule

Confusing inbound router element/type names

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.0.0-RC1
  • Fix Version/s: 2.0.0-RC2
  • Component/s: Core: Configuration
  • Labels:
    None
  • User impact:
    Medium
  • Similar Issues:
    MULE-2839 "inbound-router" element name seems wrong
    MULE-4168 A wiretap filter affects all inbound routers
    MULE-2078 inbound endpoints within <router> tags do not get registered as listeners
    MULE-3170 Inconsistent configuration of Inbound vs. Outbound routers
    MULE-3410 idempotent-receiver-router should have "disablePersistance" and "storePath" attributes in schema
    MULE-5298 Creating Custom Routers topic mentions inbound routers
    MULE-3585 recipient-list-router
    MULE-4731 Mule sends Transfer-Encoding header when used with servlet transport, confusing the servlet container
    MULE-2901 abstractConnectorType does not have a name attribute
    MULE-4100 Support failOnTimeout option for all inbound aggregator routers

Description

Some thoughts on the inbound router element and type names (note that some my confusion could very well be due to my lack of understanding of what these routers do)

idempotent-receiver-router : idempotentReceiverType

  • Type name should end with "RouterType" to be consistent.
  • Is "Receiver" in element and type name unnecessary?
  • If it is necessary, would "Inbound" be more consistent that "Reciever"?

idempotent-secure-hash-receiver-router : filteredInboundRouterType

  • Should this be of type idempotentReceiverType?
  • See above, can "Receiver" be removed?

message-chunking-aggregator-router : correlationRouterType
correlation-resequencer-router : correlationRouterType
correlation-aggregator-router : correlationAggregatorRouterType

  • Should message-chunking-aggregator-router be of type correlationAggregatorRouterType?
  • Or should aggregator be removed and the name be correlation-message-chunking-router?

Activity

Hide
Andrew Perepelytsya added a comment - 20/Dec/07 04:30 PM

Ted, I can comment on the general naming convention. The major point is that those are standard names for EIP and people quickly get an idea when they see the familiar name. This applies to idempotent-receiver and aggregators with resequencers. The router suffix is added to hint what it is in Mule internal terms.

Show
Andrew Perepelytsya added a comment - 20/Dec/07 04:30 PM Ted, I can comment on the general naming convention. The major point is that those are standard names for EIP and people quickly get an idea when they see the familiar name. This applies to idempotent-receiver and aggregators with resequencers. The router suffix is added to hint what it is in Mule internal terms.
Hide
andrew cooke added a comment - 21/Jan/08 02:29 PM

no big changes to names here (see andrew p's comment - these are things we inherited from 1.x i believe, and tend also to follow java class names), but there were a couple of errors that needed fixing: i've made it explicit that the correlation aggregator is "custom" and needs a class; i've fixed the type of the correlation resequencer; i've renamed a type to match an element.

Show
andrew cooke added a comment - 21/Jan/08 02:29 PM no big changes to names here (see andrew p's comment - these are things we inherited from 1.x i believe, and tend also to follow java class names), but there were a couple of errors that needed fixing: i've made it explicit that the correlation aggregator is "custom" and needs a class; i've fixed the type of the correlation resequencer; i've renamed a type to match an element.

People

Vote (0)
Watch (0)

Dates

  • Created:
    20/Dec/07 04:23 PM
    Updated:
    21/Jan/08 02:29 PM
    Resolved:
    21/Jan/08 02:29 PM