[
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.
