Can someone help me with advantages and disadvantages of using Spring Boot and CXF over original Tomcat/Jetty. Is it advisable to go for Spring Boot and CXF having embedded Tomcat/Jetty. Is it worth using it in Production environment. I'm building a SOA application. How does the performance compare in either of the cases.
It depends on how dependent you are on customizations. Spring Boot applies a certain defaults (which Spring classifies as sensible) based on what dependencies you have in your classpath. If you don't have an ugly legacy project I would go for bootsrapping your project with Spring Boot.
The features I've grown to like are that:
it really is easier to put up a Spring-based project
the profile-based configuration is really easy to use
it brings me closer to achieving a certain level of Continuous Delivery, just think about it: if you have a web project, you don't have to worry about setting up a Tomcat/Jetty on your machine. You just run java -jar package.jar
the variety of starter POMS opens up some nice possibilities for integrating modern technologies
Related
we have a very old java web application (about 15 years old!) with servlet, Spring version 3 and ... technologies, I want to develop a rest API for this application, in order to be able to use modern technologies I decided to develop a new modern spring (boot) web application without an embedded server and bootstrap it using a new servlet that I will define in the legacy app web.xml. I also need to isolate dependencies using Java ClassLoader. it is obvious that the new app has dependencies inside the old one and I need to be able to inject them. I know this is possible (OSGI frameworks use a very similar approach). but I have some questions.
first question(s): is this a correct/sensible strategy for this task? is there any better way?
second question: where can I find some resources to study and learn in order to implement this strategy?
I would personally look to update your Java code to use Spring boot and build new controllers, services and new views using Thymeleaf. It may be a bit of upfront work, however, once you port your App to use Spring Boot, you will be able to manage it better.
I have a very small Java codebase that I would like to expose as a REST service that responds in JSON format (to be used by a Ruby on Rails project).
I have only notions about Java web servers / web frameworks. What would be:
a. a suitable Java MVC and
b. a java server
to ease my deployment? I am interested in:
easy to build(wrap) the solution
easy to maintain / configure the server
stable (not experimental)
We use CXF extensively. It is very simple standard JAX-RS annotation based. There is a good tutorial to set it up quickly. It works with or without Spring, but easier with spring, this is my preference. The other option would be Spring REST it is very similar to Spring MVC which is very easy if you know spring already, but on the other hand it is not JAX-RS based.
you might want to give Grails a try - it:
shares some similarities with RoR
comes bundled with an application server so it's very easy to get up and running
allows very simple deployment to a Java application server (e.g. Tomcat, Jetty)
has built-in support for JSON
has recent stable releases
is under active development
http://www.restlet.org/
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html
https://github.com/dhanji/sitebricks (my favorit)
For the server part of the problem, build your code so that it is a servlet and then deploy in a container like Tomcat or Jetty. (There are many others too, but Tomcat and Jetty work very well and are pretty easy to use.)
For the framework, I'd recommend CXF (I've had good success with it in my project) as it keeps the amount of configuration you need to write small (typically just add annotations to mark which methods are to be exposed; the annotations are standardized as JAX-RS), but many others are valid choices too.
I last installed Spring a few years ago and back then it was just some jars I had to add. Now after I googled for Spring, it brought me to SpringSource, a division of VMWare.
It took me through a whole installation process for the SpringSource Tool Suite and it looks cool, but is also bulky.
What are people doing for a robust and lightweight Java MVC framework these days?
Well, Spring MVC is a robust and lightweight Java MVC framework these days ;-)
One "problem", though: it uses Spring itself (of course), which has gotten much bigger over the years. What was once just a dependency injection framework, today is almost a complete Java EE replacement. Meaning: if you want Java EE without a true application server, then use Spring. And that boils down to using Tomcat with Spring in most cases.
So, the true answer is: you can still use Spring without much hassle, but use only what you need, if you really need it. Spring originates from 2003, when Java EE was a real pain in the neck, but nowadays Java EE has gotten more and more simple, almost to the point that it's preferred over Spring, especially EE 6.
Springsource Tools isn't needed for using Spring, but it is recommended for efficient Spring usage. If you stick with XML configuration, lack of tools assistance will hamper you in the long run.
My little rant is over, so I hope I helped you at least a bit.
Springsource Tool Suite is their customized distribution of Eclipse, and no you don't technically need it. You still only need the jar files, which can be found here.
You don't need SpringSource Tool Suite.
Spring is still the most popular lightweight Java MVC framework.
Spring is splitted into different modules (projects) to avoid big dependencies if you don't need them.
List of projects from springsource
spring-framework-3.1.0.M1.zip is 25.6 MB and can be found here
Have fun!
As a seasoned Spring user I was assuming that Spring Integration would make the most sense in a recent project requiring some (JMS) messaging capabilities (more details). After some days working with Spring Integration it still feels like a lot of configuration overhead given the amount of channels you have to configure to bring some request-response (listening on different JMS queues) communications in place.
Therefore I was looking for some background information how Camel is different from Spring Integration, but it seems like information out there are pretty spare, I found:
http://java.dzone.com/articles/spring-integration-and-apache (Very neutral comparison between implementing a real-world integration scenario in Spring Integration vs. Camel, from December 2009)
http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparing Camel with other solutions, October 2009)
http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, October 2008)
Question is: what experiences did you make on using the one stack over the other? In which scenarios would you recommend Camel were Spring Integration lacks support? Where do you see pros and cons of each? Any advise from real-world projects are highly appreciated.
We choose Camel over Spring-Integration because the fluent API is really nice. We actually use it in Spring projects and use Spring to configure part of it. The programming API's are clear and there is a large set of sensible components.
We did a small scale shootout and basically at that time for our requirement Camel won. We use it mainly to transfer internal datafiles to/from external parties which usually requires format conversions sending it using ftp/sftp/... or attaching it to an email and sending it out.
We found the edit-compile-debug cycle reduced. Using groovy to experiment setting up routes are added bonuses.
Spring-Integration is a great product too, and I am quite sure it would satisfy our needs too.
I only recommend Spring Integration if you already have got a Spring project and you have just to add some "basic" integration using File, FTP, JMS, JDBC, and so on.
Apache Camel has two main advantages:
Many, many more technologies are supported.
Besides, a (good) XML DSL, there are fluent APIs for Java, Groovy and Scala.
Because Apache Camel has very good integration with Spring, I would even use it instead of Spring Integration in most Spring projects.
If you need more details, you can read my experiences in my blog post: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?
I have recently conducted a Camel vs Spring Integration shoot-out with the aim to integrate Apache Kafka. Despite being an avid Spring developer, I sadly found my suspicion with Spring's ever-growing Project stack confirmed: Spring is awesome as IOC-Container to serve as glue for other framework, but it fails at providing viable alternatives to those frameworks. There might be exceptions to this, namely everything to do with MVC, where Spring came from and where it does a great job, but other attempts to provide new functionality on top of container features fall short for three reasons and the SI Kafka use case confirms all of them:
Introduction of a long-winded difficult to use DSL for XML-configuration.
Pages of xml-configuration code to get all framework components wired-up.
Missing resources to provide functionality on par with dedicated frameworks.
Now, back to the results of my shoot-out: most importantly I am impressed by Camels overall concept of routes between endpoints. Kafka seamlessly integrates with this concept and three lines of configuration are enough to get everything up-and-running. Problems encountered during the process are neatly addressed by ample documentation from the project team as well as a lot of questions on Stackoverflow. Last but not least, there is a comprehensive integration into Spring that leaves no wishes unfulfilled.
With SI on the contrary, the documentation for the Kafka integration is quite intense and still fails to explain clearly how to integrate Kafka. The integration of Kafka is pressed into the SI-way of doing things, which adds extra complexity. Other documentation, e.g. on Stackoverflow is also less plentiful and less helpful than for Camel.
My conclusion: cobbler stick to your trade - use Spring as a container and Camel as system integration framework.
It really depends on what you want to do. If you need to extend something to build your own messaging solution Spring Integration has the better programming model. If you need something that supports many protocols without custom code, Camel is ahead of Spring Integration.
Having a small scale shootout is a very good idea, just make sure you're trying to do the type of things that you'd typically be doing in the project.
--disclaimer: I'm a Spring Integration committer
Most comparisons of Camel and SI that I've seen don't take the following into account:
1.) The effect that Spring Boot has had on developer productivity for Spring Integration
2.) The effect of Spring XD has had on making Spring Integration applications available with no code compilation - also Spring XD sources and sinks are simply Spring Integration channel adapters, when you're looking to extend Spring XD.
3.) The effect of Spring XD has had on making unifying Spring Integration, Spring Batch, Spring Data (+Hadoop!) in one stack, effectively bringing batch and stream processing, HDFS/Apache Hadoop support, and much more to Spring Integration.
4.) The effect of the soon-to-be-released Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference
For your consideration,
/Pieter (disclaimer I work at Pivotal)
We are using Spring Integration for our application and now considering to move to Apache Camel as we encountered lots of issues with Spring Integration framework. Here are couple of issues.
The CachingConnectionFactory which Spring provides opens 1000's of idle connections in IBM MQ and there is no guarantee that these connections are reused. And still these connections will stay open forever which creates troubles on the MQ side. Had to restart the application every week in lower environments just to refresh the connections. Apache Camel also provides Caching and the connections seems to go up/down based on the load.
Spring doesn't provide mappers for QoS parameters. Even if you enable QoS, the delivery mode and expiration/timetolive properties will get lost (I am going to raise a JIRA issue for this). Apache Camel handles this and QoS parameters are sent to upstream applications and not dropping it.
I am right now working on issues with handling the exceptions and transactions with Apache Camel which Spring seemed to handle better with AOP.
Apache Camel is a very good framework and very complete too. But if your application uses spring, my personal advice is to use Spring Integration.
Spring Integration is the integration EIP complaint framework of Spring-Source ecosystem. It has excellent integration with the ecosystem: Spring boot, Batch, XD; even the core uses same abstraction starting from Spring Framework 4. Some of the messaging abstraction were moved in the framework, as proof that the basic messaging abstraction of Spring Integration is very strong. Now Spring framework for instance use the messaging abstraction for Spring Web, web socket support.
Another good thing in a Spring application with Spring integration respect to use Apache Camel is that with Spring integration, you can use only one Application Context. Remember that the Camel Context is a Spring context. if you have the chance of use a new Spring version, I suggest to use Spring Integration Java DSL for configuration. I use it on my new projects, and it feels more readable and clear. I hope that this reflection can help you for the your evaluations.
Actually, I would say FTP has graduated its incubation period. You can do a simple search on SI forums/JIRA to see what new features were implemented and bugs that were fixed. From various chatter it seems like there is already some production usage out of it, so I would suggest to give it a second look and of course communicate your concerns to us via
http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT
Cheers
Oleg
Disclaimer: I am Spring Integration committer
One reason to use Camel over Spring Integration is when you need a more featureful EIP set. Spring Integration doesn't provide abstractions over things such as ThreadPool.
Camel does provide additional constructs for this simplifying some of the aspects of working with concurrent code:
http://camel.apache.org/camel-23-threadpool-configuration.html
If you have no need for this sort of thing and just want to connect file, JMS, FTP endpoints etc... then just use Spring Integration.
Camel act as middleware for application where one can perform data modeling, transformation of message values and choreography of messages.
If your current application is in Spring and require features which are supported by Spring Integration of EIP then Spring Integration is the best option else require more third party supports/protocols/file formats etc
Has anyone done this or attempted to do this for a preexisting project?
It seems there are two options to go with here, either using the embedded EJB API basically the following class
javax.ejb.embeddable.EJBContainer
Which expects a configured glassfish v3 install to be available (application scoped resources will make this easier).
The alternative is using the embedded glassfish jar files and the embedded glassfish API
I am looking for feedback from someone who has or who is in the process of doing this, links to blogs etc with a simple EJB & test case are dime a dozen.
If you've done this with any other EJB 3.1 container feel free to share.
Did you use any particular test framework for reasons other than it been your preferred tool?
Which JPA 2.0 implementation did you use, and was there a particular reason for doing so?
If you used glassfish which of the above strategies did you use? If not then which EJB 3.1 container did you use?
If you successfully did this, was it worth the effort and would you do this again for another existing project?
It seems there are two options to go with here, either using the embedded EJB API (...) which expects a configured glassfish v3 install to be available.
No, you can also use a minimal domain inside your project.
I am looking for feedback from someone who has or who is in the process of doing this, links to blogs etc with a simple EJB & test case are dime a dozen.
I've done integration testing of EJB 3.1 and JPA on my pet project (under Maven), inspired by Unit Testing EJBs and JPA with Embeddable GlassFish. Reading it is definitely worth it.
Did you use any particular test framework for reasons other than it been your preferred tool?
Nope.
Which JPA 2.0 implementation did you use, and was there a particular reason for doing so?
I used EclipseLink (because it was available at that time).
If you used glassfish which of the above strategies did you use? If not then which EJB 3.1 container did you use?
I used the Embedded EJB API, I was planning to run my code on other Java EE 6 containers when they'll be available.
If you successfully did this, was it worth the effort and would you do this again for another existing project?
Well, I think that integration / functional testing have value and find that the Embedded EJB API is really nice for that. It was not a pain to use it even if I don't consider my sample as a real life project.
For more complex scenarios, I keep an eye on the maven-embedded-glassfish-plugin (see also this answer).
I have written a small tutorial on my blog for using embedded glassfish 3.1 for unit-testing EJBs using javax.ejb.embeddable.EJBContainer. There are some pitfalls to it, which I got around by modifying the default embedded glassfish domain and putting some properties to createEJBContainer() call.