"jstrachan' wrote: > > So when we're routing into a Protocol from the outside, we need to > decide what the URI parameters map to - is it configuring properties > on the protocol bean, or passing headers into the message? It could go > either way. > > Typically we tend to configure a component (which can have many > possible endpoints) once through dependency injection > (spring/guice/jndi etc), then use uri parameters to configure the > actual Endpoint objects. > > So when a Protocol is a Component we should follow suit; if you want > different Protocol instances with different configurations (with their > own sets of endpoints) then use different dependency injected beans > with different URI schemes. > > So in your previous example we might use URIs "fooBar://in" & > "fooNoBar://in" on different component instances configured. > > When a Protocol is exposed as just a single Endpoint (with a fixed > "in" endpoint), then the act of creating the Endpoint from the > Protocol could configure a new instance of the Protocol bean using URI > query parameters. > > So in your example, "route:foo?foo=bar" could be instantiating the foo > bean, setting the foo property then invoking it's 'in' endpoint. > >
Ok, I see, that makes sense. When a protocol is a component, the component 'owns' the route config. Since there are multiple endpoints, using a shorthand to configure properties on the component level is plain wrong as it could result in erraditic behaviour. If the Protocol component should support a shorthand notation, passing the values as headers would be the only option I guess. jstrachan wrote: > > Incidentally, maybe using the term "Protocol" for the Component or > Endpoint use cases above is confusing. Maybe we say a Protocol is-a > Component with a URI scheme and multiple public input/output endpoints > and for the Endpoint case (in your example) we just call that a "Route > Endpoint" - I.e. turning a named RouteBuilder bean into an Endpoint > (then sending to it's first 'from')? > Good point, distinct names for both concepts. I'm starting to wonder though whether the Route Endpoint would still be of use when there is a protocol component. The only benefit of having a Route Endpoint is that you could configure properties through URI parameters. I don't even know whether there is be a real use case for that. Maybe the concept of passing header values via a shorthand notation is already all the customer needs. I guess we'll know once the customer will start the real implementation. But I would definitively prefer to reusing the protocol concept as it fits the core requirement, which is creating reusable components with proper endpoint encapsulation / scoping. -- View this message in context: http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3245266.html Sent from the Camel - Users mailing list archive at Nabble.com.
