[
https://issues.apache.org/jira/browse/CAMEL-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14247177#comment-14247177
]
Justin Rosenberg edited comment on CAMEL-5858 at 12/15/14 8:29 PM:
-------------------------------------------------------------------
[~davsclaus], Although I understand your position, the opposite can occur. If
you want to take advantage of the new AllowUseOriginalMessage, now you have to
add it to every Camel Context defined. That's what I call a "configuration
monster" and what I'm dealing currently. If you had a centralized definition,
then you would only need to change it one place.
Specifically the use case I have is I want each context to have a unique ID,
but not have to cut and paste the same options (i.e. AllowUseOriginalMessage).
That way in the JMX console and when logging, they can be distinguished from
each other.
Alternatively, we could add documentation on what <camelContext/> translate to
in standard Spring (without using camel-spring tags). That way someone could
accomplish this feature without having to modify the camel-spring project.
was (Author: justinksu):
[~davsclaus], Although I understand your position, the opposite can occur. If
you want to take advantage of the new AllowUseOriginalMessage, now you have to
add it to every Camel Context defined. That's what I call a "configuration
monster" and what I'm dealing currently. If you had a centralized definition,
then you would only need to change it one place.
Specifically the use case I have, is I want each context to have a unique ID,
but not have to cut and paste the same options (i.e. AllowUseOriginalMessage).
Alternatively, we could add documentation on what <camelContext/> translate to
in standard Spring (without using camel-spring tags). That way someone could
accomplish this feature without having to modify the camel-spring project.
> Camel Context Inheritance
> -------------------------
>
> Key: CAMEL-5858
> URL: https://issues.apache.org/jira/browse/CAMEL-5858
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: Raúl Kripalani
> Assignee: Raúl Kripalani
> Fix For: Future
>
>
> Camel is a great foundation for building SOA-based integration platforms.
> To improve governance and code manageability, one tends to define a number of
> common policies/items to apply across all routes in the system, e.g.
> exception handlers, data format configurations, property placeholder
> configurations, component configurations, etc.
> If you use Spring, defining common component configs is possible by placing
> them in a separate Spring App Context file and using Spring's <import />
> directive, since components are just standard beans.
> However, for Camel-specific elements, there's no good solution, so you end up
> repeating yourself a lot... Consider this for a DRY solution:
> {code}
> <camelContext id="parent.config" abstract="true">
> <onException>
> <exception>java.lang.Exception</exception>
> ... do something here...
> </onException>
> <dataFormats>
> <json ... />
> <jaxb ... />
> </dataFormats>
> <propertyPlaceholder id="properties" location="ref:myProperties"/>
> </camelContext>
> {code}
> A new Camel Context could "absorb" the config above like this:
> {code}
> <camelContext parentId="parent.config">
> ... specific configuration ...
> ... routes ...
> </camelContext>
> {code}
> This works nicely with OSGi because Camel Contexts are enlisted in the
> Service Registry, so they can access and introspect each other. For other
> environments, we'll have to design something else.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
