Difference between CamelContext and Registry in Camel - apache-camel

I'm new to Camel and bit confused between CamelContext and Registry.
As far as I know that CamelContext is the base object like ApplicationContext in Spring that is used for add routes and maintains the camel life cycle.
Also we got the Registry object from CamelContext but not sure what is the main purpose of this registry.
My intention is to add the component in the context/registry so that JNDIBind can look up the components.

CamelContext: Kind of Camel Runtime that keeps everything in Camel together, e.g.: Endpoints, TypeConverter, Routes, Components and Registry(!).
Registry: allows you to lookup beans, which by default will be JNDI beans. If you use the spring integration it will be Spring's ApplicationContext.

Generally camel when used with spring makes use of the ApplicationContextRegistry to lookup components, endpoints etc with the name of the bean defined in spring-bean.xml file. In places where we need to use JNDIRegistry we would have to add that registry when creating the CamelContext. This is used in places where JNDI objects are shared accross multiple JVMs where JNDI is the best solution.
Please see different types of registry implementation for camel: camel registries

Related

Camel Salesforce - Multiple Components Configurations

I am trying to configure multiple Camel Salesforce components in the same camel context. As I need to connect two different salesforce instances.
I know in order to configure another instance, we can simply create a new bean with a different name and it can then be used in endpoint configurations.
I got one configured via standard properties configurations and the second one is configured using a bean with different properties.
But on startup my second bean configurations get overwritten by main components configurations in SalesforceComponentConfigurer class.
Is there any way to stop configurer to ignore the second component?
#Bean("salesforce-target")
public SalesforceComponent targetSalesforceComponent(#Autowired CamelContext camelContext) {
SalesforceComponent targetComponent = new SalesforceComponent(camelContext);
targetComponent.setClientId(clientId);
targetComponent.setClientSecret(clientSecret);
targetComponent.setUserName(userName);
targetComponent.setPassword(password);
targetComponent.setLoginUrl(loginUrl);
targetComponent.setLazyLogin(true);
targetComponent.setAuthenticationType(AuthenticationType.USERNAME_PASSWORD);
return targetComponent;
}

Apache camel - How to retrieve Endpoint URIs for a given Component

I use Apache Camel 2.20x.
A camel component can be developed with a uri scheme for example "sample-component". Now the Endpoint of this component can actually extend an existing Endpoint say SQL which has uri syntax as "sql:<select query">.
Now I am listening to camel Exchange event (ExchangeSentEvent) When I retrive the uri from the event I get "sql:<select query">. But what I want is to get "sample-component". How can we achieve that. In simple terms following is the ask
How can we get all Endpoint uri schemes for a camel component.
Thanks in advance
Gk
ComponentName+Endpoint . You can see all the uri that the component will take. All camel components are named this way.There may be exceptions. also if u use intellij idea apache camel plugin it show .
examples
HttpEndpoint
TimerEndpoint
SedaEndpoint
DirectEndpoint
You can also find the consumer and producer classes of these components as follows.
HtppProducer if support HttpConsumer ..

Updating hystrix configuration in camel route

Is there a way to update hystrix configuration at runtime? I am using Java DSL to create route and referring to a hystrix configuration bean in SimpleRegistry (also tried with SpringBean registry). Nothing seems to change when I modify this bean and then do camelContext.addRouteDefinition().

EJB, JNDI & ENC - real life scenario

I am preparing for the EJB certification and I am going thro the EJB 3.1 book (O'Reilly)
One of the chapters discusses about JNDI, ENC and the EJB connections
Can some of you give me a real life scenario of these so that I can get a better understandin
JNDI in this scenario is used as a central location through which 'names' (a kind of URL) are routed to an EJB bean. Think of it how a Servlet is mapped to a URL.
If EJB beans are local to an application (e.g. they reside within the web module or within the EJB module of the same EAR), then you don't necessarily need to come into contact with JNDI. Namely, you'd probably use injection to get instances of your bean and no JNDI is needed then.
However, if you need to address an EJB bean in a remote server or if you want to lookup (a proxy to) a bean programmatically, you'd use its JNDI name and JNDI to get hold of it.
See this for some more info, including ENC: Declaring #Resource and #EJB at the class level in Java EE6

Apache Camel: Keeping routing information completely independent of the Java Code

First of all thanks to folks who are currently involved in the development of Camel, I am grateful for all the hard work they have put in.
I am looking for some design advice.
The architecture is something like this:
I have a bunch of Java classes which when instantiated are required to connect to each other and send messages using Apache Camel. The design constraints require me to create a framework such that all routing information, producers, consumers, endpoints etc should be a part of the camel-context.xml.
An individual should have the capability to modify such a file and completely change the existing route without having the Java code available to him.(The Java code would not be provided, only the compiled Jar would be)
For example in One setup,
Bean A ->Bean B->Bean C->file->email.
in another
Bean B->Bean A->Bean C->ftp->file->email
We have tried various approached, but if the originating bean is not implemented as a Java DSL, the messages rate is very high because camel constantly invokes Bean A in the first example and Bean B in the second(they being the source).
Bean A and Bean B originate messages and are event driven. In case the required event occurs, the beans send out a notification message.
My transformations are very simple and I do not require the power of Java DSL at all.
To summarize, I have the following questions:
1) Considering the above constraints, I do I ensure all routing information, including destination addresses, everything is a part of the camel context file?
2) Are there example I can look at for keeping the routing information completely independent of the java code?
3) How do I ensure Camel does not constantly invoke the originating bean?
4) Does Camel constantly invoke just the originating bean or any bean it sends & messages to irrespective of the position of the bean in the entire messaging queue?
I have run out of options trying various ways to set this up. Any help would be appreciated.
Read about hiding the middleware on the Camel wiki pages. This allows you to let clients use an interface to send/receive messages but totally unaware of Camel (no Camel API used at all).
Even better consider buying the Camel in Action book and read chapter 14 which talks about this.
http://www.manning.com/ibsen/
Save 41% on Manning books: Camel in Action or ActiveMQ in Action. Use code s2941. Expires 6th oct. http://www.manning.com/ibsen/
If you consider using ServiceMix of FuseESB, you might want to separate your routes in two parts.
First part would be the Event-driver bean that trigger the route. It could push messages to the ServiceNMR (see http://camel.apache.org/nmr.html).
The other part would be left to the framework users, using Spring DSL. It would just listen to message on the NMR (push by the other route) and do whatever they want with it.
Of course endpoint definition could be propertized using servicemix configuration service (see http://camel.apache.org/properties.html#Properties-UsingBlueprintpropertyplaceholderwithCamelroutes)

Resources