Announcement Announcement Module
Collapse
No announcement yet.
Support for Generics Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Support for Generics

    Is there any particular reason why
    Code:
    org.springframework.amqp.support.converter.MessageConvertor
    is not
    Code:
    org.springframework.amqp.support.converter.MessageConverter<T>
    with correspondingly changing the method signatures?

    It will be great if the next fix version changes this.

  • #2
    Typically a MessageConverter is used in situations where *any* Object could be passed to it (e.g. when handling a return value from a method invoked by a MessageListenerContainer). That also means that it would not ever be truly type-safe when used in such situations anyways, so I'm not sure that parameterization adds much value.

    Can you describe how you are using it, and why you think the parameterization is helpful?

    Thanks,
    Mark

    Comment


    • #3
      I don't necessarily disagree with you, but in order to do this correctly, you would need to genericize much more than just the MessageConverter. Take the RabbitTemplate for instance. It would need to be defined as RabbitTemplate<T>, as the signature of setMessageConverter would need to change to
      Code:
      public void setMessageConverter(MessageConverter<T> messageConverter) {...}
      ...
      public void convertAndSend(T object) throws AmqpException {...}
      This means pretty drastic breaking changes.

      The receiving side uses reflection anyways in order to identify the correct method on your handler to call. You still have no static type safety here. I suppose you could add a type param to MessageLIstenerAdapter so it takes a Handler<T> instead of object as well.

      If you want to handle more than one message type, like most people do, you would need to have a common Iface or base type. You will still need to have a nasty nested if/else block with cast in multiple places (or less nasty pattern match in scala) in order to correctly deserialize and handle the different message types.

      Comment

      Working...
      X