2009/5/14 Hadrian Zbarcea <hzbar...@gmail.com>:
> I personally don't see a reason for a specialized Exchange. We already *do*
> have specialized Messages and I think we should keep that (others have a
> different opinion).
>
> CAMEL-1078, is implemented for the most part, I'll try to finish the
> remaining stuff, for the upcoming 2.0-M2. In the meantime maybe we could
> clarify why Roman for instance thinks that we should not have specialized
> Messages and make a decision on that.
So it seems like I should speak up ;)
So to be perfectly clear I don't think we shouldn't have specialized
Messages at all. I see some uses of them, but not the way a lot of
those Messages look like right now.
I believe that all information that Camel message has, should be kept
directly in the DefaultMessage itself - currently we sometimes try to
synchronize camel message with the underlying message, while I believe
getBody(), getHeader() or getHeaders() should be final. Moreover I
believe that DefaultMessage should have an original 'underlying'
message available just as an Object - whatever could be the original
message like JMSMessage, HttpServletRequest, ... and I believe we
shouldn't modify it.
This way every Camel message has an access to underlying technology
object and we will not loose it, because someone forgot to implement
newInstance() or copyFrom().
At the same time I see valid reason of subclassing DefaultMessage to
lazy-load body or headers (we do it by createBody() and
populateInitialHeaders()). Then you CAN implement copyFrom() and have
optimization in place, but if there is no need to optimize, you will
not loose original message.
Problem exists today in JmsMessage like
message.getHeader("foo") // returns "bar"
message.setHeader("foo", "baz")
message.getHeader("foo") // returns "bar" once again as it reaches
original JMS message
message.getHeaders().get("foo") // returns "baz" as it reaches
DefaultMessage's internal map
So first thing I would definitely do now would be to make
get/setBody(), get/setHeaders(), get/setHeader() and maybe other
methods final with ability to lazy create their content via some
protected method (like it is now).
We could also have some 'dirty' flag that say if the message was
modified - then we can optimize some components like JMS that would
look at original message and if (message.getOriginal() instanceof
javax.jms.Message && !message.isDirty()) then it can directly send
message.getOriginal() instead of marshaling a new message. But it is
purely optimization then, that is component specific.
..long mail came out ;) Hope you reached here and you get my point.
Roman
