camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-1900) Need to allow adding of model definitions and processors in camel components without involving the camel-core
Date Wed, 12 Aug 2009 12:57:35 GMT

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


Mime
View raw message