camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashwin Karpe (JIRA)" <>
Subject [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 03:38:36 GMT


Ashwin Karpe commented on CAMEL-1900:

Hi James, Claus, Hadrian and Jon,

I did look at existing DSL definitions closely to see if there was an EIP that I could use
to accomplish my objective.

The nearet ones I came up with considering the processors I had were really two
       a> The Enricher component that suitably refactored could altenatively apply something
other than an AggregationStrategy in the following way
                               from(...).enrich("cache:testcache", cacheTokenReplacer(...)).to(...)
             The trouble however with doing this in an existing DSL is messy and the most
straightforward was
                              from("http://...").process(new CacheBasedTokenReplacer(cache,
key, token)).to(...)
       b> The other component that seemed to fit the bill was the DataFormat marshaller/unmarshaller.
I toyed with the idea of adding a little data format which would enrich/modify the original
payload . This is guaranteed to work since org.apache.camel.spi.Dataformat is an interface
that can be easily implemented from outside the camel core. I employed this strategy when
I developed the camel-xmlsecurity data format for encryption/decryption of xml payloads, tags
and tag contents. This was great since I avoided adding the xml-security jars into the camel-core.

             Unfortunately org.apache.model.ProcessorDefinition is a class that needs to be
extended and is not an interface which can be implemented from different places, which is
the root of the problem. I can see why it is this way and how it helps with intellisense.
However the side-effect of this choice is that model definitions/processors cannot be discreetly
added from components outside the camel-core. I could implement the Block interface that is
implementted by ProcessorDefinition by would end up creating  a parallel ProcessorDefinition
class (maybe ok but will have no intellisense).

       c> I totally agree your idea of making lookups into a higher level abstracted lookup
pattern which could extend/support lookups on several other endpoints (JNDI, ehCache, DB,
OSGi) etc. But I am unclear on how this can be accomplished within the camel core without
running into the same issues. that currently are not required to be in the camel-core (e.g
ehCache etc).

My suggestion/recommendation would be to upgrade the model setup to something very similar
to DataFomat which make everything extensible and intellisense friendly... 

Please let me know what you think.

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

View raw message