[
https://issues.apache.org/jira/browse/CAMEL-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988594#action_12988594
]
Claus Ibsen commented on CAMEL-3285:
------------------------------------
Yes I think the goal should be to simplify from end user perspective. What we
are aiming for is to let non-developers (or very inexperience developers) to
orchestrates business flows.
And that requires a DSL / endpoint syntax which is simple and intuitive. And
convention over configuration.
If that means a little flexibility must be sacrificed then so be it.
The error messages returned should be more verbose trying to explain what may
be wrong. And provide hints what to do to remedy that.
Also given more thought I dont like the *inner* CamelContext. The CamelContext
wasn't really designed to be embedded in a outer context.
Also by default the context setup JMX, Cache, Type Converters and a lot of
other resources which is *not* needed to be duplicated.
That's why I suggested that the current routebox should be marked as *subject
to change* (at the documentation page) as we just got started working on it.
I think Ashwin have done a good start, but I am very open to improve and make
it more flexible and easier to use in Camel 2.7 onwards.
And from a tooling point of view, then the FuseSource Camel IDE may help as a
vehicle to steer for simplicity, as it forces us to think of using the routebox
without having to do any coding at all. Or to setup spring beans or any other
weird stuff that a non-developer don't know how to do.
> Create a new blackbox component which can encapsulate routes using a
> specialized ProtocolBuilder endpoint (similar to RouteBuilder)
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-3285
> URL: https://issues.apache.org/jira/browse/CAMEL-3285
> Project: Camel
> Issue Type: New Feature
> Reporter: Ashwin Karpe
> Assignee: Ashwin Karpe
> Fix For: 2.6.0
>
> Attachments: camel-routebox-20101220.zip, routebox.diff
>
>
> Given below is the discussion forum thread that spawned this thought.
> http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-td3234703.html#a3234703
> Component requirements:
> Need a Camel component (called Backbox, maybe) that can nicely expose a
> ProtocolBuilder endpoint that does the following
> a> Instantiate route definitions/route(s) configured in Spring or DSL at
> startup
> b> Launch a Producer or Consumer with a well known protocol(s) so that a
> client can invoke it (could be direct or seda initially but could be any
> protocol... really) . Must support multiple consumer endpoints and routes
> using a URI scheme.
> c> redirect received payloads (with marshalling into an exchange if
> necessary) to the inner route(s) since they are launched and started. If
> there are multiple inner routes with many consumers, we could expect the user
> to provide a clue using the payload and/or an exchange property as to how the
> payload should be routed.
> d> Extend from a Default Consumer, Producer, Endpoint and Component.
> e> Internally manage inner route lifecycles and operations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
