camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashwin Karpe <>
Subject Re: [jira] Commented: (CAMEL-1900) Need to allow adding of model definitions and processors in camel components without involving the camel-core
Date Thu, 13 Aug 2009 04:26:30 GMT

Hi James,

I do like your idea of decoupling the body/token/xpath... based replacement
of data in message exchanges to work in a consistent way with all endpoints.

I will be happy to do some spadework on this. I will however need to add a
simple lookupandreplace() to the ProcessorDefinition.The challenge I
currently foresee with this at the moment is in how to tap into the
Configuration classes for individual components to parse different URI's and
then do the needful lookup/replace.

Please let me know of any thought you have on this topic especially where
they help avoid pulling unnecessary jars into the camel-core.



JIRA wrote:
>     [
> ] 
> James Strachan commented on CAMEL-1900:
> ---------------------------------------
> Just a general idea on the cache endpoint.
> If a cache endpoints supported specifying the key in the URI, then you
> could use the a dynamic recipient list to bind any message to any cache
> without any new DSL changes...
> {code}
> from("something").recipientList().xpath("'cache://someCache/' +
> /some/key/thing")
> {code}
> the cache endpoint would then update the key (the value of /some/key/thing
> from the message) with the payload of the message if its an InOnly. An
> InOut could be used for a cache lookup.
> Be that as it may; however the cache lookup/update message patterns work,
> if there is some requirement to replace bits of a message with some other
> value/message using some mechanism, isnt that independent of the cache
> endpoint itself?
> e.g. you might want to do a token replacement of a message where the value
> to be replaced comes from a file, HTTP endpoint, cache lookup, JNDI
> lookup, OSGi look up etc.
> So I'm wondering if this idea should be decoupled; have a 'replace bits of
> messages via tokens/xpath/whatnot' as one extension, then try let that
> extension work with any endpoint - of which cache can be but one.
> Incidentally its not really scalable to extend the DSL with every single
> possible way of processing a message. When things get kinda specific there
> is always just a regular good old fashioned Java bean with a method. We
> need to draw a careful line between whats in the DSL and whats too
> specific to too narrow a use case.
> Having said that, we do need a way to do message payload transformations
> via simple replacements (token/xpath/etc), and being able to easily do
> some kinda 'lookup in cache - if not present look up on this endpoint and
> update the cache' type thing.
> If we focus on smaller more reusable primitives it might help the DSL
> construction
>> Need to allow adding of model definitions and processors in camel
>> components without involving the camel-core
>> -------------------------------------------------------------------------------------------------------------
>>                 Key: CAMEL-1900
>>                 URL:
>>             Project: Apache Camel
>>          Issue Type: New Feature
>>          Components: camel-core
>>    Affects Versions: 2.0-M3
>>            Reporter: Ashwin Karpe
>>             Fix For: Future
>> Please see the synopsis of my problem below...
>> =================================================================================
>> I recently submitted an camel-cache component based on Ehcache to the
>> Apache Camel community (CAMEL-1868). The component has an event based
>> Cache consumer and a Cache Producer to write to the cache.
>> I was planning on adding several processors that would do selective cache
>> contents based replacement at the payload/token/XPath level. I have the
>> code written and working however, I was planning on adding a nice model
>> definition to bring it all together via DSL. This is where I ran into a
>> serious problem. The problem is the following
>>          a> The processors are in the cache component and I extended the
>> base interface processor and I can do the following in unit tests and it
>> works.
>>                     from("cache://TestCache1").
>>                           filter(header("CACHE_KEY").isEqualTo("quote")).
>>                           process (new
>> CacheBasedTokenReplacer("cache://TestCache1","cache_key","##tag##")).
>>                           to("direct:next");
>>          b> I put together a CamelCacheDefinition class (see attached)
>>                in the camel-cache component (not camel-core)
>>                that uses package org.apache.camel.model.cache
>>                and extends ProcessorDefinition<CacheProcessorDefinition>
>> from package org.apache.camel.model 
>>          c> I would like the following effect                   
>>                     from("cache://TestCache1").
>>                           filter(header("CACHE_KEY").isEqualTo("quote")).
>> applycachevalue("cache://TestCache1","cache_key","##tag##").
>>                           to("direct:next");
>> The problem is that when I develop the unit test and try to do
>> intellisense, I do not see applycachevalue() against ProcessorDefinition
>> (this part I understand, since it is not seeing the CacheDefinition
>> entry) since this capabilty comes from the processorDefinition in
>> came-core. What I am trying to see is 
>>           a> How can I do this without having to modify the
>> ProcessorDefinition in camel-core and keep my CacheDefinition in the
>> camel-cache component. 
>>           b> I do not wish to add the ehCache dependency in the
>> camel-core and bloat the core. Also, the Producer and Consumer ehCache
>> components are all related to the processors and I would like to avoid
>> fragmentation of the processors from the components.
>>           b> If not and I do have to move the CacheDefinition into the
>> camel-core, can I still keep the processors in camel-cache component and
>> intellisense without side-effects ( I suspect I can through the groups
>> setup in camel-core but I need to verify)
>> ======================================================================================
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

Ashwin Karpe, Principal Consultant, PS - Opensource Center of Competence 
Progress Software Corporation
14 Oak Park Drive
Bedford, MA 01730
+1-972-304-9084 (Office) 
+1-972-971-1700 (Mobile) 

View this message in context:
Sent from the Camel Development mailing list archive at

View raw message