Clebert,
This would not remove the need for javax.jms.Message and its
extensions/implementations. In fact, the way I was thinking of it, this
would just be a wrapper payload type that had type-safe
getters/setters/fields for each of the properties that could be defined, as
well as headers. There would be a special payload method that determined
the body. All of this mapping could be done with annotations.
There's no reason this mapping couldn't be reused for all cases where a
message was sent.
John
On Fri, Nov 25, 2011 at 11:50 AM, Clebert Suconic <clebert.suconic_at_gmail.com
> wrote:
>
>
> On Fri, Nov 25, 2011 at 8:16 AM, John D. Ament <john.d.ament_at_gmail.com>wrote:
>
>> Pete,
>>
>> Actually, the proposal to the EG was around the use of concrete message
>> typed objects as the event payloads. Much more robust than what I have
>> today in Seam JMS.
>>
>>
> But just to be sure we are on the same page, Nobody is proposing
> eliminating message-types right? We would still be able to aggregate
> properties to messages and do server side filter without requiring parse on
> the message-body, right?
>
>
> I think that's important to keep. I understand users are asking for
> XML-message, but having the current way of filtering is important for users
> as that tends to scale better on the server's side. The user would still
> have an option.
>