Replacing Hibernate /Spring / Spring MVC stack with Hibernate / Guice / Wicket

I have an application which are using Hibernate / Spring and Spring MVC, but as a motivation to learn and also compare the differences I want to port the application to an Hibernate / Guice / Wicket.

The questions I have are pretty basi开发者_JS百科c, but where do I start. Should I start with replacing the Spring layer, then the Spring MVC layer?

Can the two work i the same environment, so that I can start with editing just one controller/view and then expand, and how do I do this?

1. Start with the view:

   Spring MVC won't work without Spring anyway. And since other layers don't depend on its API (well, shouldn't, at least), the presentation layer should be the easiest to change (although the one that will take most of the effort, since it will consist in a complete reimplementation).

2. Go after Spring:

   a) If you don't use much of Spring's utility classes (*Template, *DaoSupport, etc.) or infrastructure (transaction management, security), migrating to Guice would probably be a matter of rewriting (XML- or annotation-based) configuration in Guice modules/annotations, since pure dependency injection, if not portable, is pretty much directly mapped between the frameworks.

   b) If you do use Spring's utility classes and infrastructure (which you probably do, since that's the whole point of using Spring instead of no-value-added-yet-another-dependency-injection-containers...), you'll have to migrate them to Guice somehow. If you plan to do this incrementally, you could look for some integration between the two (probably using the Spring infrastructure from Guice), and after you migrated the depedencies, switch to Guice-native interceptor implementations (and test, test, test, since little differences in behavior could break your application). This other question may provide some tips on this.

3. Then, Hibernate:

   Since you'll be keeping Hibernate, its configurations shouldn't be affected by the transition. Only its bootstrap will change when you migrate your infrastructure and configuration to Guice. I don't recommend keeping two parallel SessionFactories, if you can avoid it.

The gradual transition from one framework to the other seems possible for the development but not for production. The issues you'll have to face doing a page by page replacement in a single environment.

1. url mapping

   The bootstrapping of springMVC+spring+hibernate and wicket+guice+hibernate is done using url patterns. You have to tell the server if springmvc or wicket will serve the request.

   You should completely separate the contexts by using a root pattern. Therefore, during the migration phase, the urls will be difficult to reconcile. The spring version can not reference urls version wicket.

2. data synchronization

   Two hibernate mappings will operate in parallel. Do not use cache and reload all the information on each page request to be sure not to have problems with data synchronization.

A disadvantage of this solution is the starting time of the server due to the double load hibernate mapping.

You should start by adding a wicket-guice application in your web.xml:

<filter>
    <filter-name>guiceFilter</filter-name>
    <filter-class>com.google.inject.servlet.GuiceFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>guiceFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<listener>
    <listener-class>com.app.web.guice.MyGuiceServletContextListener</listener-class>
</listener>