Wondering is it possible to integrate Camel with a very old version of Sonic MQ (5.02). The queues in one of the legacy application we have, were built in 2003! When we try to post using Camel (with the sonic client jar on the classpath) we get class not found exceptions from Camel...
java.lang.AbstractMethodError:
javax.jms.ConnectionFactory.createConnection()Ljavax/jms/Connection;
This relates to the old version of JMS api (1.02b) shipped with Sonic.
Even if we put the correct version of JMS API on class path.. we get further... but then various sonic exceptions .....
Wondering if it is even supported?? Has anyone tried this..
or have info the could share?
Much Appreciated
What version of Camel do you use?
Camel does not support JMS 1.0 api for a very long time. You would need to use an old version of Camel. In fact that happend form Camel 2.5 onwards, see its release notes: http://camel.apache.org/camel-250-release.html
Related
I'm working on a legacy project with Spring Version 4.1.0.RELEASE (no Spring Boot). Is there a way to integrate Kafka to the project? We need to consume and produce messages.
All I found on the internet about Spring + Kafka was about newer Spring versions and/or Spring Boot. Updating the project is unfortunately not an option. There is a parallel updating project for the application, but we need a short-time solution.
I tried to use spring-kafka 1.3.11.RELEASE, but I get an error while starting the application.
Caused by: java.lang.ClassNotFoundException: org.springframework.core.MethodIntrospector
I found out that update to a newer Spring version would fix that. But as I said, updating Spring is not an option in this project context.
kafka-clients alone does not depend on Spring. You are not required to use spring-kafka , spring-integration, spring-cloud-streams, etc. dependendencies to "use Kafka with Spring", so if you don't mind wiring in the Kafka clients by yourself, then just start with the raw client library.
I have a Spring boot 2.25.1 application which is using Camel 2.25.1 with camel-kafka everything is working fine..
In my Kafka consumer, I have a need to add the feature to pause consumption on demand so I upgraded to camel 3.18.1 so I can use the pausable feature.
After upgrading to 3.18.1 I am getting error FileNotFound with class file TimeoutAwareAggregationStategy.class.
when I opened camel-core 3.18.1 jar this class does not exist which was available in came 2.25.1 version.
Please suggest.
I was expecting smoother upgrade from camel 2.25.1 to camel 3.18.1.
According to the Camel upgrade guide for Camel 2.x to 3, the camel-core was modularized and broken up into multiple jar files. In that upgrade guide, they mention a lot of changes to Aggregation Strategies. While I couldn't find a direct implementation of the AggregationStrategy interface called TimeoutAwareAggregationStategy, I can see that class exists in camel-core in version 2.25.4 and the AggregationStrategy interface is moved to camel-api in version 3.0.
I was expecting smoother upgrade from camel 2.25.1 to camel 3.18.1
Normally, when upgrading a major version to a newer major version, there will be major changes that you have to account for. These changes are almost always covered in the change list or upgrade guide.
I can see in spring-jms.gradle that starting with 5.0.0, the dependency to the JMS API changed from 1.1 to 2.0.
However, my question is: does this mean that spring-jms 5.x actually requires the provider to implement JMS 2.0?
I cannot find a clear requirement for th JMS version in the spring documentation neither in the Javadoc of the main spring-jms classes (like #EnableJms). For other JEE APIs like servlet-api or JPA, spring documentation/javadocs make this clearer.
Today, I still use spring 4.x and want to upgrade to 5.x, however I use a JMS provider (Oracle AQ) that implements only JMS 1.1. I would like to be sure whether spring-jms may make use of specific JMS 2.0 features like JMSContext.
I believe it's backwards-compatible, so as long as you don't try to use any 2.0 features, you should be ok.
Why don't you just give it a try?
I have a RESTful web service application in java deployed on google app-engine which uses jersey 1.18.6.
I want to use postmark java client to send transactional emails from it.
When I integrated it, i was seeing the following exception:
javax.ws.rs.core.Response$Status$Family.familyOf(I)Ljavax/ws/rs/core/Response$Status$Family
From what I could find, I think this error was because of there were two different (and probably incompatible) version of jersey being used ,1.18.6 for jersey-server, jersey-guice and jersey-bundle and 2.25.1 for jersey-client (by postmark).
Then I tried to make the jersey version 1.18,6 throughout, so in the my main project pom, while including the dependency for postmark, I excluded the jersey-client (by added exclusions header) and separately added jersey-client dependency in my main project .
But then I got the following error:
java.lang.NoClassDefFoundError: javax/ws/rs/core/MultivaluedHashMap
This is I think the class MultivaluedHashMap is present only in jax-rs 2.x versions (which is compatible with jersey 2.x versions)
So my questions are:
Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
If no then what options do I have other than migrating my main project from jersey 1.x to jersey 2.x. I don't want to do that since we will have to migrate not just the jersey dependencies but I think some other things like guice, shiro etc. which would be time consuming. Also it doesn't really seem optimal to modify multiple existing dependencies just to include one additional module.
There isn't. The very first commit of the project's pom.xml already used Jersey 2.25.1
as Mureinik mentioned above, when we worked on the library, our plan at Postmark was to use newer library versions, since they are better options in long run.
On our Github page Rupert made good suggestions, from which I find separate ClassLoader a good choice. I will play a bit with the library code in next couple of days on compatibility, however we are always in favour of using newer libraries for our codebase.
please check out my latest comment on Github issues page for possible solution for using older Jersey version https://github.com/wildbit/postmark-java/issues/11
It should be pretty easy to port the library to Jersey 1.x by porting only the HttpClient class on your side.
We have an application that is currently running spring 2.5.6 and mule 2.2.1. We have decided to go ahead and upgrade the app to use spring 3.2 we also upgraded spring security to 3.1. I understand that Mule 2.2.1 uses spring 2.5.6 for configuration and so forth. We were to re-factor our code and build the entire project. However after deploying the application and starting the server, my server started in about 6 seconds instead of the normal 30 seconds and then I noticed that none of my services were not loaded. Unfortunately after days of investigating I cannot find where everything fails, as there are no errors in any of the logs including spring and mule logs. My question is it possible to get these to play together or should I just forget about getting this to work.
I read this post http://lifeinide.blogspot.com/2012/07/spring-3-and-mule-2-initialized-by.html and followed these instruction and still was not able to get it work. Mule says it started up just fine without any errors but I can hit any of my services. Any help? Thanks
Thanks #genjosanzo for the pointer. It helped met dig into this issue better and eventually make it work.
#mtanzania,
We had a similar need like yours - need to make Mule 2.2.1 work with Spring 3.2.x releases. Upgrade to Mule 3 involved rewrite of Mule extensions such as exception handling strategies, a RabbitMQ Mule transport etc. Upgrade to Mule 3 was therefore ruled out.
In order to make this work, you need to rewrite/update 3 java files from your module:
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:2.2.1
with implementations from :
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:3.4.0
To be more specific, you need these classes to be updated/upgraded: MuleBeanDefinitionDocumentReader.java, MuleApplicationContext.java and SpringXmlConfigurationBuilder.java
With these updated versions, you can continue to create the MuleContext like:
SpringXmlConfigurationBuilder springConfigBuilder = new SpringXmlConfigurationBuilder(muleConfigPaths);
MuleContext context = new DefaultMuleContextFactory().createMuleContext(springConfigBuilder)
The modified implementations are here : Mule in Trooper and sample class that uses this is here : Trooper Mule container
Mule uses some internal spring API to parse the mule configuration and creates the correspondent beans.
For this reason the upgrade might work with spring 3.0.x but I'm pretty sure that something got broken with spring 3.1.x (i.e. this code has been introduced to maintain backward compatibility).
How about upgrading mule as well? Most of the 2.2.x syntax is still supported and many new feature has been introduced in newer mule versions.
FWIW, the above answer from #regunathb is right on. Patching in those three classes works. However, it is important to note that the 3.4 version of those classes from mule-module-spring-config will not work as-is. You must get the modified versions of the classes that #regunathb posted on GitHub, otherwise you'll end up with various incompatibilities between 3.4 and 2.2.1.