I implement a Spring Boot (1.5.x) application with Apache Camel (2.19)
For integration purposes I need to use three data sources (see for more about multi-data-sources here: https://github.com/spring-projects/spring-data-examples/tree/master/jpa/multiple-datasources).
One of the routes I have marked with .transacted():
from(Consts.DIRECT_ROUTE + routeId)
.routeId(routeId)
.startupOrder(loadRouteParameters.getStartupOrderTransformAndLoad())
.autoStartup(true)
.transacted()
however, when I start the app I get:
Caused by: java.lang.IllegalArgumentException: Found 3 PlatformTransactionManager in registry. Cannot determine which one to use. Please configure a TransactionTemplate on the transacted policy.
How to handle it? How to fulfill "Please configure a TransactionTemplate". I was not able to find any example for this special case.
Sounds like you have multiple TransactionManager beans in your Spring context. Camel does not know which one to take. You have to help your Camel a bit.
Define a SpringTransactionPolicy and reference the TransactionManager to be used in the Camel route.
<bean id="txPolicyName" class="org.apache.camel.spring.spi.SpringTransactionPolicy">
<property name="transactionManager" ref="[yourTxManagerBeanId]" />
</bean>
Then you can set the policy as argument to your transacted() in the Camel route:
.transacted("txPolicyName") // txPolicyBeanId as String
Related
I am new to Apache Camel and I am in a situation where my application needs a codec (HL7) to be registered with camel context. I know there is a solution where you can create a default camel context with an instance of your own registry but is there any way I could configure my own registry in the camel context?
I am using JavaDSL to develop my application and the configuration in context goes like this.
<bean id="hl7codec" class="org.apache.camel.component.hl7.HL7MLLPCodec">
<property name="charset" value="iso-8859-1"/>
</bean>
<camelcontext id = "context">
<ref bean = "MyRouteBuilder"/>
<camelcontext/>
I build the routes in MyRouteBuilder Class by overriding the configure method. My route goes like this.
from("mina2:tcp://localhost:8888?sync=true&codec=#hl7codec").to("jms:queue")
However, the codec doesn't seem to work. When I remove the codec, My application runs just fine and accepts HL7 messages but with the codec, I am not able to receive any messages. I feel this occurs because the codec bean is defined but the context isnt able to pick it up. I do not want to create a defaultcamelcontext with the required registry settings. Rather, I am looking for a way to register the codec within camelcontext configuration xml, and so far, I have failed.
Am I missing anything with my configuration? Any help would be greatly appreciated.
You normally should not need to use & in Java DSL, so replace &codec= with &codec=
I have config xml based spring application for which I have moved proprties required at start up time in database. It was very difficult to manage hundreds in property file and that is why database is introduced. To read properties a spring restful service is developed to return a map of all properties required at start up time.
I want to know how to replace properties reading from a map to spring context file e.g. ${config.service.url} should be polulated from a map read via web service.
One option I considered is to upgrade to Annotation based and start using MapPropertySource and Environment interface as environment.getRequiredProperty("config.service.url"). However upgrading to Annotation based is a big impact on project and is no at this time.
Second option that I am looking forward is to have a customised PropertyPlaceholderConfigurer.
Any pointer/help on this will be great.
Cheers,
Amber
You could define a PropertyPlaceholderConfigurer, but instead of specifying a file location, you can pass the properties directly as returned by your restful service.
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties" .../>
</bean>
I am configuring Atomikios TM API with my Spring Application to achieve global transaction. As Atomikios require XADatasource to work, so I have done JNDI look up to get the same. But, unfortunately I am getting following errors while doing the look up.
Object of type [class com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource] available at JNDI location [jdbc/cuds] is not assignable to [javax.sql.XADataSource]
<jee:jndi-lookup id="dataSourceCu" jndi-name="jdbc/cuds" cache="true" resource-ref="true" lookup-on-startup="true" expected-type="javax.sql.XADataSource" />
<jee:jndi-lookup id="dataSourceGodb" jndi-name="jdbc/pushpullds" cache="true" resource-ref="true" lookup-on-startup="true" expected-type="javax.sql.XADataSource" />
I am using Spring 3.0/ hibernate with WebSphere 7.0.Where I am doing wrong. Please help me. Thanks.
The data source configured under jdbc/cuds is not an XADataSource but a normal one. You need to change the data source configuration in WebSphere (I have no idea how to do this).
However since you're on WebSphere which has it's own transaction manager there really is no need for configuring Atomikios. You can either use
<tx:jta-transaction-manager>
or org.springframework.transaction.jta.JtaTransactionManager / org.springframework.transaction.jta.WebSphereUowTransactionManager but the data source still needs to be XA.
XADataSource defines a contract between a JDBC provider and the application server and can only be used in that context. The DataSource object that you get when looking up the data source via JNDI in your application will never implement the XADataSource interface, even if the underlying data source is configured to support XA.
If you want to use your own transaction manager, then you would also have to manage the data sources yourself. Note that personally I wouldn't do that and strongly advice to use WebSphere's transaction manager instead. The reason is that distributed transactions involve lots of subtleties (e.g. recovery and in-doubt transactions) and it is unlikely that setting up a transaction manager inside an application would achieve the same level of robustness as WebSphere's transaction manager.
I'm implementing a SOLR server in our application.
We use the CommonsHttpSolrServer in the SolrJ package to connect to our solr server which uses the commons-httpclient.
We also use Spring.
Now our sysadmin secured the solr server (with good reason) and used Basic Auth.
How can I instantiate a HttpClient with Basic Auth to be injected in the SolrJ?
e.g.
<bean id="httpSolrServer" class="org.apache.solr.client.solrj.impl.CommonsHttpSolrServer">
<constructor-arg value="${solrserver_path}" />
<constructor-arg ref="solrHttpClient" />
</bean>
Thanks!
Unfortunately, you have to use a factory that creates the client. There is no bean property for credentials in the classes involved in authentication, namely
HttpState.setCredentials(AuthScope, Credentials) which isn't a bean property.
I uploaded my HttpClientFactory to github. Se also the snippet for the spring context.
Seems like a simple task. I have a webapp which requires a database connection. I'd like to be able to drop an updated .war file on this app server and load a new version without having to re-edit an applicationConfig.xml file to specify the database connection parameters for production.
Is using the container to setup the data source and then referencing it from JNDI the preferred way to go? I think it is cleaner having it all defined in the spring .xml file, but I can't come up with a clean way to allow the production password to be set only once as we roll out new versions.
So, how do you specify your database connection information in a spring application so that you can upgrade it without having to re-edit the files?
If you use JNDI, how do you handle setting up of your tests since the JNDI is not going to be available outside of the container?
Thanks!
The typical way to externalize database connection properties is to store them in a .properties file and load using <context:property-placeholder .../> . Then you can have different .properties files for testing and production.
If you choose JNDI, you can use a Spring's mock JNDI support for testing.
One approach is for your Spring configuration file to be composed of fragments related to specific layers in your application.
One such fragment could contain your DataSource defintion. For production, this fragment would use a jee:jndi-lookup. And then for test, have a different fragment would use a DriverManagerDataSource ?
Update:
If you want to change the datasource after deployment, then you can use this technique, along with changing the which datasource is injected into your other beans using a PropertyPlaceholderConfigurer as explained in an old post I wrote
eg:
<bean class="foo.bar.SomeClassNeedingDataSource"">
<property name="dataSource" ref="${the.datasource.to.inject}" />
</bean>
<jee:jndi-lookup id="jndiDataSource" ... />
<bean id="driverManagerDataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
...
</bean>
# the properties file
the.datasource.to.inject = jndiDataSource
#the.datasource.to.inject = driverManagerDataSource