camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: AW: AW: CAMEL-6648
Date Mon, 11 Nov 2013 19:51:33 GMT
Will do. The default is 'Major' so pretty much all issues are like that. 
Few are changed to a different level (usually to draw attention to 
something that has a more serious impact). It's hard to be pedantic with 
the issue severities, because, we are a self managed community (like all 
others at the ASF) and the severity is in the eye of the beholder, not 
driven by a business impact as is usually the case with commercial software.


On 11/11/2013 02:32 PM, Jan Matèrne (jhm) wrote:
>> Personally I don't think there is a need for one in camel core. As a
>> framework, camel should stay very simple and provide solutions/helpers
>> for the common use cases. Such a dsl, while useful in your context adds
>> unnecessary (imho) complexity for camel. That's the beauty of camel, it
>> is pluggable and extensible, but not all extensions are good candidates
>> for inclusion back in the core for various reasons (some depend on non
>> compatible licenses, and hosted at camel-extra, some are application
>> specific, etc).
>> FWIW, I've been using variations of the builder pattern for a long
>> while, but to build domain specific messages and then use the generic
>> ProducerTemplate to send them to an Endpoint. I consider it a better
>> approach, as it is tied to the (semantics of the) domain vs the lower
>> level Camel api.
>> Your work is noted though and appreciated.
>> Hadrian
> Then please close that issue.
> I wonder why this was prioritized as "major" ....
> Jan

View raw message