Hi When I started looking at Camel the MEP patterns confused me to start with. It's not really explained to well what its does, why its there and which components supports witch kind of them. And then they come in multi flavors such as RobustInOnly. I know they are from w3.org but they are sometimes to smart people sitting in their tower to long, and not noticing the world around them.
I do think we should slate for Camel 2.0 to simply the MEP and only support what most people know and use: - sync (InOut) - async (InOnly) And each component should state the pattern when you create a component and not inherit InOut so the component developer thinks what his component support. And we should document it on the wiki. And Camel is a bit confusing if you use the producer template to send an InOnly message you get your own input message back as response. Why not void? To make it clear and easy. So I think the ProducerTemplate should be changed to be more concise with all its methods which is InOnly and InOut. Not many know that you should use requestBody for the InOut cases. With the latest patch from CAMEL-688 it broke a route from bean to file. Having a clear implementation of MEP for all components ensures that we don't break new route combinations that we currently don't have unit test covering. Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: Willem Jiang [mailto:[EMAIL PROTECTED] Sent: 10. juli 2008 11:17 To: [email protected] Subject: Re: ExchangePattern handling in Camel Hi Gert, In the default case (for handling JMS message), camel just use the ExchangePattern.InOnly, so it is not surprise for use to see we can set the out message in a InOnly exchange. But in camel-cxf component , we always want to camel's exchange working in InOut mode, because we need to set the response back. I think current CAMEL-688 just add a restriction check for the exchange pattern, it cause some side effect on the BeanExpression which need to return the value even the exchange is InOnly. I agree Gert's keeping the camel current behavior, because it simple for most case. Willem Gert Vanthienen wrote: > L.S., > > If you look at the comments on CAMEL-688 and some of the others mails > on the commits, it looks like it is time we make up our minds what we > want to do with ExchangePattern handling inside Camel. Up to now, the > ExchangePattern was there mostly for informational purposes -- e.g. to > transfer this information inside Camel when interacting with JBI or > CXF exchanges. > > If it is just there for informational purposes however, we should try > to avoid implementing other behavior based on the MEP. For example: > for CAMEL-688, we should follow on Claus' suggestion to just use > getOut(true) to force the 'out' message to be created. > > On the other hand, if we really want to honor the ExchangePattern > inside Camel, the current patch is OK, but we probably also need a lot > of other changes. Just an example: the PipeLine currently sends the > incoming exchange to the first target, even if this is an in-only > exchange. If we want to go for strict MEP handling, we should > probably change that behavior so it always interacts with it targets > in an in-out manner, allowing them to send set the 'out' message content. > > As I said: I think it's time we make up our minds here, because the > current situation is just a bit messy. Personally, I would prefer to > keep Camel as lightweight and simple as possible, just keeping the > current behavior, where the MEP isn't influencing the behavior. > > Regards, > > Gert >
