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 thoght you have on this topic especially where they help aoid pulling unnecessary jars into the camel-core. Cheers, Ashwin... JIRA j...@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.
