[
http://jira.jboss.com/jira/browse/JBESB-1282?page=comments#action_12385290 ]
Kurt Stam commented on JBESB-1282:
----------------------------------
Let me clarify this. This is a generic issue with our transport where do NOT leave the
payload opaque. Instead we serialize the *entire* message on the way out and deserialize
it on reception in the Courier. So now this courier will need access to the specific java
classes contained in the message (let's say the dvd store classes). This is a
consequence of the transport/message Implementation design and has nothing to do with the
DLQ Service.
IMO we should leave the payload OPAQUE until we need to interact with the message. This
will make sending messages around much easier.
How does DLQ work when message payload types are out of scope of the
service?
-----------------------------------------------------------------------------
Key: JBESB-1282
URL:
http://jira.jboss.com/jira/browse/JBESB-1282
Project: JBoss ESB
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Rosetta, Process flow
Affects Versions: 4.2.1 IR2
Reporter: Tom Fennelly
Assigned To: Kurt Stam
Fix For: 4.2.1 triage
Just wondering e.g. the DLQ is running as a centralized service... it's forwarded a
failed message that contains payload types that it knows nothing about... what should
happen?
I'm seeing an exception related to this on th aggregator quickstart. The DLQ service
is running on the AS, while the individual serives are all running standalone. The DLQ
Service has no visibility on the payload types bound to them failed messages that get
delivered to it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira