]
Kevin Conner commented on JBESB-3313:
-------------------------------------
Please follow up on this forum thread, an alternative (additional) action model is already
being discussed.
Abstraction layer between actions and messages
----------------------------------------------
Key: JBESB-3313
URL:
https://jira.jboss.org/jira/browse/JBESB-3313
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Rosetta
Reporter: David van Balen
I feel that having action developers interact directly with
org.jboss.soa.esb.message.Message unnecessarily ties the ESB to a particular message
implementation, as well as generating extra work and inconsistency when implementing new
actions.
It occurred to me that actions could all extend a common base class that abstracts
functionality related to manipulating the message, isolating actions from its
implementation. For instance, it is currently the action developer's responsibility to
place the action's result on the message. While some developers have provided the
options of configuring an alternative location from the default for that response, many
actions don't seem to provide it. Enforcing that results be placed on the message by
calling some kind of "setResult" method,that takes care of checking whether the
user has configured an alternate location, would make action implementation more
consistent, as well as ensuring that basic functionality like specifying an alternate
response location is available across actions. Additionally, things like the exact text of
the configuration property would be more likely to remain consistent across actions.
Also, abstracting operations related to message attachments and properties would allow
how these are implemented to change without breaking a large amount of the codebase.
Ideally, action developers should not have access to the message object.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: