2008/11/21 S. Ali Tokmen <[EMAIL PROTECTED]>: > Hello > > This is very good to know :) A repository would in fact resemble the > "endpoint id" mechanism, the only difference being that the endpoint > identifier would not be "hardcoded" but rather obtained from a Repository > service. > > I'm launching debug sessions to see at which points integration fits best. I > hope to be able of doing what I want without having do change CAMEL core.
Sorry I'm so slow diving into this interesting thread; I've been on paternity leave & trying to sleep :) So the reference mechanism Claus mentioned is really intended for local aliasing; for example if you refer to the same endpoint many times within routes & you don't want to have to include all the various URI parameters and so forth - you can introduce a logical name for it. A bit like introducing a shared variable in code. I think what you are after is some kind of registry/repository mechanism so that you can look up logical named endpoints - but at runtime have some separate database/JNDI/LDAP thing map the logical name to some physical endpoint class and/or URI string etc. There are a few ways to do this; I'll just list some ideas to see which one seems the most fitting. One of the design ideas behind Camel was that there can be many Endpoints; they can be lazily created on demand or registered by the user into a CamelContext. A Component is really just a factory of Endpoints; it takes a URI and creates an Endpoint instance for it. Sometimes a Component can share some configuration information across actual endpoints (e.g. a JMS component can share JMS ConnectionFactory objects across endpoints for individual queues and topics etc) http://activemq.apache.org/camel/component.html So you could create some kind of Registry Component which takes a logical URI and maps it to some Endpoint instance somehow. e.g. your component could use the scheme 'foo' so that a URI foo:someLogicalName then takes the remaining name and looks it up somewhere - then returns the Endpoint object - or looks up an Endpoint by URI to lazily create the physical endpoint etc. We should probably have standard JNDI / ldap / OSGi components which just look up a logical endpoint name in those particular registry implementations. Though in some ways we can just reuse existing IoC contains for this. e.g. we could refer to an Endpoint by its logical name - then use Spring Dynamic Modules to look up the endpoint by name in OSGi; or use Spring's JNDI lookup mechanism to look up in JNDI etc Incidentally another approach to this is to use OSGi / JBI / NMR as a level of indirection. e.g. when using Camel inside ServiceMix you can refer to JBI endpoints using their logical name - then the NMR can resolve those logical names to physical endpoints. I tend to view the JBI NMR as being an endpoint registry; capable of mapping a logical endpoint to one or more physical endpoints. Finally on the licensing & including in an example; we can't redistribute or link with any LGPL code in an Apache project. However so long as the Apache code doesn't import directly any LGPL code - it seems allowable to have an example maven program download the LGPL code. e.g. an Apache example could use JPA and then have a maven build use either OpenJPA or Hibernate. So I think we could have an example program which routes using URIs which use an LGPL component at runtime to resolve the URIs into physical endpoints -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
