Article Series: Migrating Spring Applications to Java EE 6 – Part 1

April 17, 2012

Developer Topics, Java EE

Bert Ertman  and Paul Bakker of Luminis have written a multi-part article that covers migrating Spring Applications to Java EE 6 technology.  It also consists of sample code a working project.  In the series Paul and Bert discuss the rationale for migrating your applications from Spring to Java EE 6 and show you real examples of upgrading the web UI, replacing the data access layer, migrating AOP to CDI interceptors, migrating JMX, how to deal with JDBC templates, and as an added bonus will demonstrate how to perform integration tests of you Java EE 6 application using Arquillian.

See the PDF here “Migrating Spring to Java EE 6 – Part 1″  or read online below.

PART 1 – Introduction

Over the past couple of years there has been a growing interest in all things Java EE. Generally speaking Java EE 5 to some extent, but Java EE 6 in particular marked the re-birth of Java EE’s credibility with developers. While Java EE is considered to be hot again, people wonder whether to jump on this train. Back in the days around 2003/2004, J2EE was at the height of its unpopularity. Developers hated its ivory tower specification process and its blindness to solving real-world problems. By that time a book came out that radically changed the way that enterprise Java development would be done for the next five years. This book of course was the “J2EE Design and Development” book, later followed by the “J2EE without EJB” book, both from Rod Johnson et all.

Developers loved these books and their way of presenting better solutions to the real-world problems they were facing at that time. In fact people still love those books without realizing that the world has changed dramatically ever since. The reality check here is to wonder whether the rhetorics set forth by Rod Johnson in his 2003/2004 books are still actual today. In our opinion all of the problems presented in the book can now be easily solved using standard, boiler-plate free, configuration-by-exception, easy to comprehend, lightweight POJO-based Java EE technologies. So if you still care about those books, the best way to show your appreciation is probably to use them as your monitor stand.

There are two ways to approaching the Spring vs. Java EE discussion nowadays. You are either in the situation that you have to build a green field enterprise application and you ponder what gear to stuff into your toolbox. Or you are facing a serious legacy enterprise application upgrade issue. Upgrading six or seven year old Java technology, being it Spring or J2EE inflicts a lot of pain anyway. The discussion whether or not to use Spring vs. Java EE for new enterprise Java applications is a no-brainer in our opinion. It took a while but Java EE has finally made the leap to be a standard, lightweight, fitting solutions to the vast majority of real-world development challenges in the mainstream enterprise applications space. You should have no single reason beyond choosing the standard. The question whether Spring or Java EE is the better solution is not the main focus of this series of articles. We want to present you an approach on how to tackle the problem of upgrading your legacy Spring applications from the past. It is important to understand that there are means to an end. In other words we don’t encourage you to take the migration all the way or else it wouldn’t be complete. Our intention is to present you with a migration path that you can head onto for just as many steps as you are willing to take. There can be all sorts of valid reasons not to take the migration all the way. These can be based on available time, money, and expertise. We are sure though that if you find yourself stuck with a legacy Spring application and wonder how to move forward from this point on towards a modernized enterprise application that is considered fit enough to last at least another five years, this series of articles will present you with hands-on, ready-to-use examples.

Why migrate?

Before we start talking about what a migration path for legacy Spring applications would look like, it is valid to ask yourself the imminent question “why should I migrate my application in the first place?”. This is definitely a valid question and there are multiple answers to this one. First off, Spring was born out of frustration with mainstream technology, has been a hugely successful – do no evil – Open Source project, and has since then fallen a prey to the hungry minds of Venture Capitalists and finally into the hands of a virtualization company called VMware. Within the Java world VMware is probably best known for being able to run Windows on your Mac, and we’re not even sure if that is a good thing to be remembered of. Despite various efforts Spring nor any of its sub-projects has ever become a true Java standard. While the different companies and individuals behind the Spring framework have been doing some work in the JCP their voting behavior on important JSRs is peculiar to say the least. From how we see it, neither the Spring framework, nor the companies behind SpringSource have any benefit of truly standardizing it ever. This is of course a political motive and most developers don’t care about that at all, so let’s move on to more technical arguments of why a migration is a good solution for your problem. The technical reason is that upgrading your old-school Spring applications, even to modern Spring-based solutions, requires a lot of work anyway. Some technologies that might be used in the original application might even be considered end-of-life soon, or worse, are already part of a dark past.

When we mention “old-school Spring apps” we picture lots of complex XML configuration, an outdated ORM solution like JDBC templates, Kodo, or TopLink, and an old fashioned approach towards the web using a deprecated extension based Web MVC SimpleFormController. Just to give you an example.

Can you still find developers that master the techniques and frameworks used in the application? And if so, can you still find them say in another five years? From our own experience we have also seen applications that show ‘tells’ of each and every year that maintenance took place. We could tell from the use of different web an/or ORM frameworks and techniques that were all used within the same applications as a representative of the current most popular framework of that time. Ploughing through this framework erosion is tedious, boring, and above all complicated work leaving much room for mistakes causing even more damage to the application. And so this calls for an extreme makeover approach. Parts of the application have to be radically renewed, sometimes from the ground up. While you are confronted with that, why not take a little extra step and take it to the standard?

Busting myths

If you still have some concerns whether Java EE is suited for the job we encourage you to read on and get some misunderstandings out of the way first. We already discussed some of the J2EE problems of the past. However, some developers completely stopped looking at new developments in the Java EE space and might have lost track of the current state of technology. It is not the aim of this article to introduce you to Java EE 6, but as a quick refresher, let’s take a look at some key technologies of both Spring and Java EE 6 and see how they compare and moreover to see how Java EE caught up on Spring.

Lightweight

Some of the complaints of the past include the statement that Java EE has become fat and bloated. Some people even rebranded Java EE to Java Evil Edition. Is this still true today? You can of course take our word for it, but it is probably best to take a look at modern application server startup times. Firing up the latest JBoss AS 7 Application Server from scratch and deploying a full blown Java EE 6 application into the server takes somewhere between two and five seconds on a standard machine. This is in the same league as a Tomcat / Spring combo. There is a dramatic difference however if you consider the size of the deployment archive as well. A fairly standard Java EE 6 application will take up about 100 kilobytes while a comparable Spring application weighs in at a whopping 30 Megabytes! The Java EE 6 application is of course benefiting heavily from the fact that all Java EE 6 APIs are provided by the Application Server runtime. One of our favorite quotes is from JBoss’ own Andrew Lee Rubinger stating that “nowhere in the Java EE spec does it say that Java EE servers should be heavyweight and slow..”. Exactly true!

Dependency injection

From a technical standpoint it is interesting to take a look at some of the technology capabilities that Java EE lacked in the past and that have put Spring in the driver’s seat. Let’s start with one of the most important reasons for developers to resort to Spring in the past: Inversion of Control (IoC) or whats more popularly known as Dependency Injection (DI). According to Wikipedia Inversion of Control is a style of software construction where reusable generic code controls the execution of problem-specific code. It carries the strong connotation that the reusable code and the problem-specific code are developed independently, which often results in a single integrated application. Inversion of Control is sometimes referred to as the “Hollywood Principle: Don’t call us, we’ll call you”, because implementations typically rely on callbacks.

Although IoC is commonly thought off to be invented by the Spring framework authors, it is in fact an old design paradigm which was mentioned in official publications in the late eighties of the previous century. What the Spring framework did however is putting the IoC pattern to use in Java to heavily reduce coupling in enterprise Java implementations leading to much better testable code. It took quite a while for Java EE to catch up but finally as part of Java EE 6, the Context and Dependency Injection (CDI) specification was introduced to the Java platform, which has a very powerful contextual DI model adding extensibility of injectable enterprise services along the way. If you don’t know about CDI yet, you are really missing out!

Aspect Oriented Programming

Another technique that was popularized by the Spring framework is Aspect Oriented Programming (AOP). In AOP the object oriented nature of the programming language is extended by a technique that weaves some cross-cutting concerns into the application at compile time or at runtime. Typical examples of cross-cutting concerns are logging and security, but it can be used for anything. A common pitfall when taking AOP too far is that your code might end up all asymmetric and unreadable. This is due to the fact that the aspect and its implementation are not in the same place. Determining what a piece of code will do at runtime at a glance will be really hard. This does not make AOP useless. If you use it responsibly and in the right amount it might prove to be a very powerful way to achieve separation of concerns and reusability. We often refer to that as “AOP Light” and this is exactly what Java EE Interceptors do for example. The implementation of interceptors on EJBs for example is somewhat limited making it harder to burn your fingers on too much AOP. In a way this is very much comparable to lightweight AOP in Spring AOP as well. The intercepter model was introduced in Java EE 5 and combining it with CDI (which was introduced in Java EE 6) creates a very powerful interceptor model that will give you a clean separation of concerns and greatly reduces the amount of code duplication in your application.

Testing

We already touched upon the subject of testing when we discussed IoC. Testing in J2EE was hard if not impossible. Mainly this was due to the fact that most J2EE components required lots of runtime services to be available in order to function properly. This is the death of a testable design. As Java EE returned to a POJO-based approach to enterprise components, testability increased a lot. Still also Java EE components require runtime services. In order to truly be able to test a Java EE component in its natural surrounding – the application server – we need a mocking framework. Or maybe not?  Not that long ago a new revelation on the testing horizon has surfaced. Its name is Arquillian. With Arquillian we can get rid of mocking frameworks and test Java EE components in their natural environment. Before running a unit test Arquillian creates a so-called micro deployment containing the Java EE component under test and its direct dependencies and creates a small deployable archive, deploys it into a running container or temporarily starts one, runs the tests and undeploys the archive from the container. Arquillian does not force an alternative way of unit testing upon you, but integrates non-intrusively with your favorite testing framework, e.g. JUnit. Arquillian is the ultimate companion to Java EE when it comes to testing. There is some good documentation with lots of examples available for Arquillian but as part of this article series we will show you how to write some basic integration tests of your own.

Tooling

Finally, we all have nightmares from firing up overweight tooling providing UML-savvy, crappy wizards that only worked once – when you were lucky – in order to do some decent productive development. Your computer felt like a car being trampled upon by a monster truck. Thankfully, this is now truly something from the past. All three major Java IDEs offer decent support for developing Java EE components without violating your computer’s resources. Developing Java EE applications is no longer tight to single vendor’s tooling solutions but you can use your IDE of choice, a little bit of Maven, and the application server of your liking. Setting up a Java EE project based on Maven from scratch is a breeze with tools like JBoss Forge which is pretty much compatible with all respected frameworks and application servers out there.

Comparing Spring and Java EE capabilities

For your convenience we listed a capabilities comparison matrix below to map Spring’s technology to that of Java EE.

Capability Spring JavaEE
Dependency Injection Spring Container CDI
Transactions AOP / annotations EJB
Web framework Spring Web MVC JSF
AOP AspectJ (limited to Spring beans) Interceptors
Messaging JMS JMS / CDI
Data Access JDBC templates / other ORM / JPA JPA
RESTful Web Services Spring Web MVC (3.0) JAX-RS
Integration testing Spring Test framework Arquillian *

* Not part of the Java EE specification

As a summary to what you have been reading so far it is safe to say that apparently it can all be done using plain vanilla lightweight Java EE. This leaves us with the migration issue at hand.

Migration approach

What would be the best way to move forward and start the migration? Some might be tempted to completely throw away the legacy application and start all over again. While this might appeal as an attractive solution and if time nor money constraints are an obstacle this might work. However for most realistic situations this is clearly not an option. What we do need is a gradual way of renovating the application without it collapsing on us on the way. Therefore we need a recipe that moves us forward step by step. The recipe should also allow for your own creativity and it should be possible to end the migration at any step that you would like. We came up with the following steps:

1. Upgrade Spring to the latest version

2. Replace old or out-dated frameworks (e.g. ORM, web frameworks) within Spring

3. Run Spring and Java EE container side-by-side

4. Replace Spring entirely

5. Remove Spring container

In the next part of the series we will elaborate on the migration approach and then take you through the different steps by showing you real-world examples of the migration in progress. There will be code examples and a link to a special GitHub project where you can take the project for a migration spin of your own, or subsequently apply all the change sets that we’ve prepared in order to demo your way through parts of the migration process.

- Bert  Ertman & Paul Bakker


About the authors

Bert Ertman (@BertErtman) is a Fellow at Luminis in the Netherlands and a Sun/Oracle recognized Java Champion. Besides his day-job he is a JUG Leader for the Netherlands Java User Group (3500 members).

Paul Bakker (@pbakker) is a senior developer at Luminis Technologies in the Netherlands and a contributor on the JBoss Seam, Arquillian, and Forge projects.

Both authors have extensive experience in building enterprise applications using a variety of technologies ranging from the pre-J2EE, J2EE, Spring, and modern Java EE technologies. They have been discussing the use of new enterprise technologies regularly and had endless discussions on Spring vs. Java EE. Currently, they believe that both new, green field, enterprise applications, and large-scale maintenance migration on legacy apps can be done best using Java EE 6 technology. The authors have been evangelizing Java EE (6) technology at various conferences around the world, including J-Fall, Jfokus, Devoxx, and JavaOne. This series of articles is based upon their well-received JavaOne 2011 presentation titled “Best Practices for Migrating Spring to Java EE 6”.

Disclaimer: The views and opinions expressed in this article are those of the authors and do not necessarily reflect the official policy or position of Red Hat, Inc. Examples of analysis performed within this article are only examples. Assumptions made within the analysis are not reflective of the position of Red Hat, Inc.

,

About rayploski

I'm lucky enough to have a dream job. I run developer strategy for Red Hat.

View all posts by rayploski

39 Comments on “Article Series: Migrating Spring Applications to Java EE 6 – Part 1”

  1. Sharat Chander Says:

    Fantastic article. Happy you presented this at JavaOne Moscow. It was very well received.

    Reply

  2. phillips1021 Says:

    I really don’t understand these sentences:

    “The discussion whether or not to use Spring vs. Java EE for new enterprise Java applications is a no-brainer in our opinion. It took a while but Java EE has finally made the leap to be a standard, lightweight, fitting solutions to the vast majority of real-world development challenges in the mainstream enterprise applications space. You should have no single reason beyond choosing the standard. ”

    My development team has a huge Spring knowledge base and Spring has worked exceptionally well for our Java projects. So I need to provide my managers with much more compelling reasons then Java EE is now the standard (heck J2EE was the standard and for many good reasons we went with Spring) to get them to invest in quite a bit of developer training in order for us to be as productive with Java EE 6 as we are with Spring.

    I appreciate your article but I think you’re very biased. I do like Java EE 6 but I have to convince managers and other developers to switch from Spring (which has proven to be very successful for us) and spend significant resources (money/time/brain cells) to learn Java EE 6 in depth. I need a much more compelling argument then “well Java EE 6 is the standard and it does what Spring does.”

    Reply

    • rayploski Says:

      “I need to provide my managers with much more compelling reasons then Java EE is now the standard” – Valid point. Look for a posting in the future that describes the differences in detail.

      Reply

    • Paul Bakker (@pbakker) Says:

      Existing knowledge in a team is a strong argument not to migrate away from any technology, even if the newer technology is “better” for whatever reason. We see a lot of teams with very fractured knowledge however, because people join and leave the project, because junior developers don’t know about the older frameworks etc. Being based on a standard will reduce that problem in the future because there is a pretty good change new developers at least know these. It would be good to start incorporating Java EE APIs such as JPA within Spring. This is a great gradual learning path towards full Java EE, and outdated frameworks used within Spring (Kodo, JDO, old web frameworks etc.) should be replaced at some point anyway. This guide explains how to migrate gradually, and that’s exactly how you should do it in real projects.

      We do strongly prefer Java EE because it’s the standard and do prefer the programming model, but we have also been doing many Spring projects and gave training in both Java EE and Spring; we’re not biased because of unfamiliarity and we are not working for an app server vendor either.

      Reply

      • phillips1021 Says:

        My teams knowledge is very good on Spring and we keep up-to-date on the new Spring releases. This knowledge was gained over a period of time. So far new developers to the team have not had experience in Java EE 6.

        One issue that would help all developers if the learning material for Java EE 6 was better. There are few up-to-date Java EE 6 books. The online material from Oracle for Java EE 6 is focused almost exclusively on Netbeans and GlassFish. Also much of the online material provided by Oracle reference using Netbeans “wizards” to generate your code. That’s not a good learning technique–that just learning how to press specific buttons in Netbeans.

        Our team uses Eclipse/Maven and trying to get learning material/examples/books that we can use with Eclipse/Maven and Java EE 6 has been difficult. There are bits and pieces on the web in various blogs, but nothing comprehensive that we could use as part of a training course. Our employer won’t spend money to train developers in Java EE 6 since the tools we now use are working well.

        Any recommendations you can provide for learning Java EE 6 in an Eclipse/Maven environment would be great.

        Otherwise trying to convince management that developers should switch from Eclipse, Spring, Maven, Tomcat to Netbeans, Java EE 6, and GlassFish is a huge mountain to overcome.

      • Shane K Johnson Says:

        I use Maven too.

        I would suggest taking a look at the JBoss AS7 / EAP 6 quickstarts here and here.

        They are Maven based. They are Java EE 6 based.

        I’ve found some of them to be great references due to their simplicity.

      • Shane K Johnson Says:

        In addition, I would suggest taking a look at the JBoss EE 6 Maven archetypes.

        JBoss Nexus Repository (link)
        GitHub (link)
        Documentation (link)

      • phillips1021 Says:

        Shane on the quick start web pages at the bottom (e.g. see: https://github.com/jboss-eap/quickstart/tree/master/cdi-injection) is a link to “Use JBoss Developer Studio or Eclipse to Run the Quickstarts” but that link results in a 404.

        Do you have a good link to that page?

        Thanks for the help.

      • Shane K Johnson Says:

        While that link is supposed to take you to the ‘Use JBoss Developer Studio or Eclipse to Run the Quickstarts’ section of the README, I think you may find this documentation (link) to be of more help.

      • Paul Bakker (@pbakker) Says:

        This is a very good question. I completely agree the documentation could be much better, unfortunately this always takes time.

        I do have a few tips:
        -Have a look at JBoss Forge. This tool help you to configure Java EE in a standard maven way: http://forge.github.com
        -Bert and I did a 3 hour tutorial at Devoxx that shows how to create a Java EE 6 Maven project from scratch (using Forge): http://www.parleys.com/#st=5&id=2892&sl=0
        -There are a few good books about the different specifications that are part of EE 6
        1) JPA 2: http://www.amazon.com/Pro-JPA-Mastering-Persistence-Technology/dp/1430219564
        2) JAX-RS: http://www.amazon.com/RESTful-Java-Jax-RS-Animal-Guide/dp/0596158041/ref=sr_1_1?ie=UTF8&qid=1334860860&sr=8-1

        Besides that the WELD documentation is a very good resource to learn more about CDI.
        I believe this website will also contain more guides in the near future, maybe Ray can say more about that.

        I will send your feedback about the Oracle docs to some people I know there.

      • phillips1021 Says:

        Paul – Really appreciate the links – unfortunately the link to your Devoxx tutorial is for subscribers only – I got to see the first few minutes and then was told to pay for a subscription.

        I’ve read through several books on JPA 2 and in new Spring projects try to use JPA 2.

        I’ll check out forge – but for learning I prefer not to use “wizards/code generators”

        The quick starts Shane linked to in his reply look promising but I dislike the idea of having to install and run JBoss AS 7 just to run the unit tests.

        There a large “stack” of Java EE 6 technologies–JSF 2, JPA 2, CDI, EJB 3.1, etc– that I’ love to find a book that covers well and have source code that uses Maven for building.

      • Shane K Johnson Says:

        Perhaps you can clarify.

        Do you dislike the idea of executing tests against a container?

      • phillips1021 Says:

        I don’t mind the container part but rather the extra work of having to download/install a specific container and then start it up prior to running the unit tests. If the container/app server was embedded and was started/stopped as part of Maven running the unit/integration tests that would be fine. That is what we have for testing Spring applications.

        Once reason I really like Maven is that you can download a project and (usually) just run mvn goals to run the tests, the site documentation, create JavaDoc, build, and even deploy to an embedded container such as Tomcat or Jetty. Especially when learning about how a new framework/library/API works – that type of scenario is invaluable and really encourages developers to learn a new technology.

        I believe GlassFish does provide an embedded application server and a Maven plugin that allows you to include everything needed in the pom.xml.

        Part of the problem with Spring/Maven developers transitioning to Java EE 6 is that Java EE 6 doesn’t do Maven as well (e.g. Java EE 6 artifacts are not in the Maven central repository).

        Right now I believe most Java developers are still at the “need to learn how to use the Java EE 6 APIs” stage. The easier Oracle and the Java community can make learning Java EE 6 for Java developers who currently use Maven and are not on the latest Java EE application servers (JBoss AS 7, GlassFish 3) and are not Netbeans wizards the more developers who will get into Java EE 6.

        The other advantage of having really good Maven examples is that all the current Java IDEs (Eclipse, NetBeans, IntelliJ) can import and handle Maven projects.

      • Shane K Johnson Says:

        The ‘arq-jbossas-managed’ Maven profile will start and stop the server.

        We agree that Maven is important.

        Java EE 6 Maven support with JBoss is excellent (link).

        The JBoss AS 7 / EAP 6 quickstarts are Maven projects. The Java EE 6 API dependencies are in the Maven Central Repository. JBoss maintains a Java EE 6 bill of materials (link). It is pushed to the Maven Central Repository.

        We believe in the advantages of providing Maven based examples. That is why we provide the quickstarts. And yes, because they are Maven based, they are not intended for a specific IDE.

        A developer can install JBoss AS 7 by downloading a 127MB ZIP archive and extracting the files.

      • phillips1021 Says:

        Shane – appreciate the help. I’ve setup JBoss AS 7, installed all the JBoss Eclipse tools, imported the maven quick start projects. But I’m getting numerous maven errors such as:

        org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact org.jboss.spec:jboss-javaee-6.0:pom:3.0.0.Final-redhat-1 in central (http://repo.maven.apache.org/maven2)

        and also:

        [ERROR] ‘dependencies.dependency.version’ for javax.enterprise:cdi-api:jar is missing. @ line 53, column 19
        [ERROR] ‘dependencies.dependency.version’ for org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is missing. @ line 61, column 19
        [ERROR] ‘dependencies.dependency.version’ for org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ line 69, column 19

        on the helloworld quick start when just doing mvn clean either in Eclipse or at the command line.

        Note I’m using Maven 3.0.4

      • Shane K Johnson Says:

        It looks like you are working with the JBoss EAP 6 quickstarts. The JBoss EAP 6 dependencies (including Java EE 6) are not in the Maven Central Repository.

        However, the JBoss AS 7 dependencies (including Java EE 6) are in the Maven Central Repository.

      • Paul Bakker (@pbakker) Says:

        The presentation at Parleys will be published for free at some point, I only don’t know when. There is a similar presentation on Parleys from Bert and me that we did on a BeJUG evening, that one is available for free.

        Forge is really not about code-generation and wizards, it does help you write the Maven files however. Because it sets up Maven step by step you will never end up with a whole bunch of xml without knowing what it does.

        Testing in a container is all about integration testing, not unit testing. There is a thin line between the two, but they are different. You can unit test Java EE code using JUnit and your mocking framework of choice. Besides that, you should also have integration tests that test JPA code, dependency injection, messaging etc. The only way to make those test useful is run them in a real app server. To do so you should use Arquillian, we will discuss this in more detail in one of the following parts of the series.

      • phillips1021 Says:

        Shane – you’re right I used your second quick start link above instead of the first one. The link for the JBoss AS 7 quick start projects is https://github.com/jbossas/quickstart.

        Everything is now working well in Eclipse and Maven. I can run the helloWorld quick start in the JBoss server from within Eclipse and I can run the unit tests for the Bean-Validation quick start with JBoss being started and stopped via the Maven arq-jbossas-managed profile.

        It did take ma a little while to figure out where to set jbossHome value (in the the arquilian.xml file in src/main/resources) but after that the unit tests are successful.

        Now I have some very good Maven examples of Java EE 6 technologies and an application server to use in testing and running them. And everything is working with Eclipse.

        So now I’m off to study these quick starts and continue my learning on Java EE 6. I may write an article for my blog (http://www.brucephillips.name/blog) that details how I got all this to work as there were a few confusing steps (I had to uninstall the m2eclipse plugin I did have in Eclipse so that the JBoss plugins could install a different version, getting the correct quick start download for AS 7, where to configure jbossHome, etc).

        I appreciate all the assistance and the effort everyone put in to making these quick start Maven examples work well.

      • Shane K Johnson Says:

        Nice work!

        If you write that article, let us know. We would love to see it.

      • phillips1021 Says:

        Wrote an article for my blog – http://www.brucephillips.name/blog/index.cfm/2012/4/20/Java-EE-6-Example-Projects-For-Eclipse-and-Maven-Users

        I have to admit – JBoss has done a very good job of making it easier for Eclipse/Maven users to learn Java EE 6.

      • Piotr T. Says:

        How to use NoSQL database with JEE ?
        How to use stored procedure with JEE ?
        How to perform batch processing with JEE ?
        How to avoid vendor lock using JEE container services ?

      • Shane K Johnson Says:

        How do you use a NOSQL database with Java EE?

        With Java. Look at MongoDB. There is a Java driver, and number of third party frameworks and libraries, a JDBC driver, a REST server, and more.

        While a new Spring module is necessary to support a new project with Spring because it must be Spring-ified, that is not the case with Java EE.

        How do you use stored procedures with Java EE?

        JPA Native Queries, JPA with Hibernate, Hibernate, JDBC.

        How do you perform batch processing with Java EE?

        Right now, with Java. There are a number of batch processing frameworks.
        Later, JSR 352.

        How do you avoid vendor lock in?

        The same way you do it with Spring. Do not use proprietary container services. A Spring application that uses proprietary container services is no more portable than a Java EE application that uses proprietary container services.

  3. phillips1021 Says:

    If my development team’s has an excellent Spring knowledge base (including the new version) and the original project is Spring based – why (besides that Java EE 6 is the standard) would my team not upgrade the project to the latest Spring technologies?

    Your article seems very biased against Spring (use the books as monitor stand, prey to the hungry minds of venture capitalists, etc.) and I think your bias has significantly colored your perception.

    Reply

    • rayploski Says:

      I believe your point about technical comparison was replied to above. I will allow the authors of the material comment about their bias. Red Hat spends significantly on ensuring that Spring runs well on JBoss and that Spring and CDI can interoperate.

      Reply

  4. phillips1021 Says:

    I really don’t understand these sentences:

    “The discussion whether or not to use Spring vs. Java EE for new enterprise Java applications is a no-brainer in our opinion. It took a while but Java EE has finally made the leap to be a standard, lightweight, fitting solutions to the vast majority of real-world development challenges in the mainstream enterprise applications space. You should have no single reason beyond choosing the standard. ”

    What does “You should have no single reason beyond choosing the standard.” mean?

    My development team has excellent Spring knowledge, including the latest versions. Spring has worked very well for numerous Java projects. Spring continues to evolve and has a very healthy eco-system. There several Spring libraries besides Spring core (Batch, Spring Data, Spring Social) that help us solve problems and write better code faster and easier.

    I do like what Java EE 6 has done. But I need several much more compelling arguments then “Java EE 6 is the standard” to convince managers and developers to invest time/money/brain cells in learning Java EE 6 in depth and radically changing our tool set.

    Those compelling arguments are not the biased, fear-mongering ones (“fallen a prey to the hungry minds of Venture Capitalists and finally into the hands of a virtualization company called VMware”) you make.

    Will my applications be more secure, more maintainable, more feature rich, and faster if I migrate them from Spring to Java EE 6?

    Please keep in mind that we will also need to change from using Tomcat to using a full-blown application server which will also involve time/money/resources/brain cells. So my arguments to management must really be convincing for them to make these far-reaching changes to a model that has worked very well.

    Reply

  5. zynasis Says:

    Dont forget who the writer works for.

    Reply

  6. sivalabs Says:

    JavaEE just copied the ideas from Spring and now all these JavaEE gurus are writing these kind of articles.

    What you great JavaEE rockstars were doing when Rod Johnson was writing those books??? Playing in kinder garden???

    Reply

    • Shane K Johnson Says:

      I think it is safe to say that none of them were still in kindergarten. However, I would not be surprised if some of them were still in college.

      That book was published 10 years ago. A decade represents a lot of change in the software industry.

      Reply

    • Paul Bakker (@pbakker) Says:

      Spring has no doubt played a huge role in moving the programming model we know today forward. Just like technologies such as Hibernate and Seam it would be better if innovation would be brought back to a standard however.

      Reply

    • JavaDev Says:

      Spring framework brought many welcome changes to java programming model. However DI existed well before Spring was born. ATG (Dynamo) was using DI & ORM (in the form of Nucleus framework) way before Spring and Hibernate were born. Well it was proprietary and we needed to pay even for documentation for that reason it was not made popular. This point is brought up here just to say that there is nothing wrong about taking inspiration from technologies (Rod Johnson may not have copied from ATG Dynamo :-) )

      Reply

      • Peeyush Says:

        Truely agree with you. ATG DAF and Repository concept does exactly what Spring and Hibernate does much before.

      • Jonathan Says:

        Having come from an ATG background I remember way back in 2000 looking with horror at the complexities of the JEE standard at the time, I was pleased that Interface21 actually brought a whole load of change and realisation to eventually change the course where JEE was going even though some of the concepts in the ATG Dynamo platform, which was incidentally the first commercial application server on the market without EJB’s, sadly never really appeared outside of ATG and those concepts of Nucleus, Repositories, components+configuration, configuration config layering and combining are still going strong in the majority of the top worldwide retailers generating billions in revenue every year. I think that’s why I will always tend to support the Spring tribe like I always supported Steve Jobs @NeXT and Apple who have done the same with computers.

        I must say I’m also really impressed with the Typesafe and the Play framework written in Scala that further kicks the academic Servlet API out of the building with a proper way of embracing HTTP using a non blocking asynchronous simple API. One huge step in the right direction.

        Its just a shame that we have to go to these lengths to convince the owners of the Java Specs to actually listen and see what is being built around them before they take any action to bring that into the product.

        I agree with the earlier comments that the Oracle examples are always based on their products and map of the world, but then again, IBM and VMware would be too, right? This was another reason why the Spring tribe were so successful in that they charismatically embraced the pain where developers were at the time mostly using Eclipse. Since working in the field from 1995 consulting with many different clients I have only ever met 1 person who used NetBeans. Oracle, wake up and smell the coffee if you want to support the Java community.

        Thanks for sharing the article.

  7. Jai Hamilpur Says:

    Excellent one. This article supports my interest to develop application as per J2EE standards.

    Reply

Trackbacks/Pingbacks

  1. JavaOne Moscow « oracle fusion identity - April 19, 2012

    [...] http://howtojboss.com/2012/04/17/article-series-migrating-spring-applications-to-java-ee-6-part-1/ [...]

  2. Bert Ertman and Paul Bakker on Spring to Java EE 6 Migration Podcast « oracleidentitymanagement - June 5, 2012

    [...] The complete podcast is always fun but feel free to jump to 3:49 minutes into the show if you’re in a hurry. They authored a series of article on the exact same topic starting here. [...]

  3. No benefit in migrating from Spring to Java EE | Enhance ICT :: Web Applications - June 6, 2012

    [...] Oracle is providing a podium for people (you know who you are) who are telling you that you should migrate from Spring to Java EE. The first articles making that case started appearing a year and half or so [...]

  4. 20120822Migrate Spring Application to Java EE6阅读心得 | doublehero - August 22, 2012

    [...] http://howtojboss.com/2012/04/17/article-series-migrating-spring-applications-to-java-ee-6-part-1/ [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 115 other followers

%d bloggers like this: