understanding switchyard and camel contexts

[jeanniesorenson]

I am searching for a deeper understanding of what is going on in the switchyard and camel contexts.

Some starting questions:

• is the camel context replaced by the switchyard context?
• does the one or both contexts sit on top of the context in cdi? Or inside it?
• can I use the context features of CDI without worrying about stepping on a sy/camel context feature, and vice-versa?
• is there feature overlap between sw/camel and cdi? If so, is there any reason to not use a cdi feature, e.g. a @Schedule to name one example?
• what are the features or services provided by the sw/camel contexts

My apologies if this is all documented somewhere.

[kcbabo]

• is the camel context replaced by the switchyard context?

A Camel context still exists, but it is created by the runtime and not directly configurable via a Spring application context.

• does the one or both contexts sit on top of the context in cdi? Or inside it?

The CDI BeanManager is integrated with the Camel bean registry, which is part of the CamelContext.   

can I use the context features of CDI without worrying about stepping on a sy/camel context feature, and vice-versa?

Can you be a bit more specific here?  Are you referring to scopes within CDI or something else? 

is there feature overlap between sw/camel and cdi? If so, is there any reason to not use a cdi feature, e.g. a @Schedule to name one example?

Generally speaking, I would represent outside stimuli such as message transports, schedulers, etc. as gateway bindings.  You can create a service in SwitchYard and then add any binding you want to it.  For your example, you could create a bean service, promote it and then add a Quartz binding to the service which will invoke the service based on the schedule specified in the binding.

what are the features or services provided by the sw/camel contexts

You're going to have be a bit more specific with this question.

[jeanniesorenson]

• what are the features or services provided by the sw/camel contexts

>> You're going to have be a bit more specific with this question.

Thanks for your answer.  Okay. I will try to clarify.

a. Is a Switchyard Context a Camel context, nothing more, nothing less? If nothing more, I can refer to the Camel documentation. If something more, what exactly, i.e. where can I find documentation on this. An overview perhaps?

b. Can there be more than one Switchyard context?

c. Is the switchyard.xml the place where "features" of the context are defined? Datasources, message queues, and the like?

• can I use the context features of CDI without worrying about stepping on a sy/camel context feature, and vice-versa?

>> Can you be a bit more specific here?  Are you referring to scopes within CDI or something else?

Ok. So I have a @Stateless bean. Or a @Stateful bean. Can they both be a @Service? Or I have a @Schedule. Can that be a @Service? Or a MDB? A @Service? Do such things live happily in harmony with one another? Do I inject such managed beans into a Switchyard Service?

Or can I use for instance: @TransactionAttribute(TransactionAttributeType.MANDATORY)? Or @RequestScoped?

Thanks!

[kcbabo]

a. Is a Switchyard Context a Camel context, nothing more, nothing less? If nothing more, I can refer to the Camel documentation. If something more, what exactly, i.e. where can I find documentation on this. An overview perhaps?

CamelContext is not directly exposed to the user in SwitchYard.  There is not a Spring application context in which it's configured.  The CamelContext is created by the runtime and integrated with the appropriate platform services.  Camel routes are created as services and the route definition is defined in its own file.  CDI bean discovery is used in place of defining beans in an application context.

b. Can there be more than one Switchyard context?

One per application.

c. Is the switchyard.xml the place where "features" of the context are defined? Datasources, message queues, and the like?

No, message queues and data sources would be defined in the application server (EAP) and referenced from the switchyard.xml.

Ok. So I have a @Stateless bean. Or a @Stateful bean. Can they both be a @Service? Or I have a @Schedule. Can that be a @Service? Or a MDB? A @Service? Do such things live happily in harmony with one another? Do I inject such managed beans into a Switchyard Service?

Or can I use for instance: @TransactionAttribute(TransactionAttributeType.MANDATORY)? Or @RequestScoped?

You can integrate SwitchYard applications with Java EE components, but it's not required.  Integration with Java EE services occurs via CDI, so you can inject a bean proxy for a SwitchYard service into your Java EE component (stateless bean or whatever).  Likewise, you can inject Java EE components into beans used in a SwitchYard application.

I recommend that you check out the example applications that ship with the platform for some examples of how CDI and Camel are both used within SwitchYard.

https://github.com/jboss-switchyard/quickstarts

[jeanniesorenson]

Thanks. Can I then use, as two examples, @TransactionAttribute(TransactionAttributeType.MANDATORY) or @RequestScoped in a Switchyard service?

[kcbabo]

Thanks. Can I then use, as two examples, @TransactionAttribute(TransactionAttributeType.MANDATORY) or @RequestScoped in a Switchyard service?

There are alternatives to using these annotations if you are implementing a SwitchYard service.  For the former, you can use our transaction policy support to specify transaction requirements.  For the latter, all bean services are application-scoped.  You can, however, invoke a CDI bean from a Camel route which would give you the equivalent of request scoped.

[san_ebro]

Hi,

is it possible to inject beans into Message Composer, Processor and other switchard components using CDI?

Thanks.

[kcbabo]

You can't inject a bean into a Message Composer at this point.  In order to support injection, the injection target needs to be a CDI bean itself.  We actually support this for transformers and we could do something similar for message composers as well (point to a bean instead of class name in the definition).  If you feel this would be useful, please file a JIRA requesting the feature.

You cannot inject a bean into a Processor, but you can inject a bean into another bean.  A bean invoked from a Camel route will have access to everything a Processor can do.  If it must be a Processor, I imagine you could perform a lookup of the bean you want to invoke via the camel context (exchange.getContext().getRegistry()).

[san_ebro]

Thank you very much. I can inject into a Transformer then, and this solves my problem.

[angelo.rlcosta]

Hello guys,

lets imagine i have a scheduling task which runs once and gets some data from DB how and where can i put this data so that in every camel route i can have access to this data?

Thanks

[igarashitm]

Can you create a new thread to make another question so people hit same problem can find it later?