camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashwin Karpe <aska...@progress.com>
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.

Cheers,

Ashwin... 
 

JIRA jira@apache.org wrote:
> 
> 
>     [
> https://issues.apache.org/activemq/browse/CAMEL-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53593#action_53593
> ] 
> 
> 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...
> http://camel.apache.org/recipient-list.html
> 
> {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: https://issues.apache.org/activemq/browse/CAMEL-1900
>>             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) 
---- 
Blog: http://opensourceknowledge.blogspot.com/


-- 
View this message in context: http://www.nabble.com/-jira--Created%3A-%28CAMEL-1900%29-Need-to-allow-adding-of-model-definitions-and-processors-in-camel-components-without-involving-the-camel-core-tp24924243p24948644.html
Sent from the Camel Development mailing list archive at Nabble.com.


Mime
View raw message