Search code examples
javaspringhibernatevaadinvaadin8

Can gradual migration be possible for a Vaadin JavaEE to Vaadin Spring?

We have an existing Vaadin 8 JavaEE webapp that was adapted and heavily modified from the Tickets Dashboard demo. We are in the process of planning a schedule to migrate the app to using Spring (non-boot) and adopt the MVC model for the next version. However, after reading through the Vaadin Spring documentation and going comparing source codes between the current app, the sample bakery app (spring, with Framework 8), and an older project using Hibernate 4 and Spring 4, we still had a few key questions that required to help improve our approach to migration:

  1. Is gradual migration possible where some of the functions are migrated to Spring first followed by others in subsequent minor releases? If yes, which classes should I start modifying / adapt (apart from those below) to Spring first before moving into the smaller releases?

  2. We've established that 75% of our application is using complex native select queries, with 25% on CRUD operations. We are still sticking to Hibernate as most of the dev team are familiar with it. Is it better to stick to using the DAO generics approach (encapsulating the implementation e.g https://www.baeldung.com/simplifying-the-data-access-layer-with-spring-and-java-generics) or just using the JPARepository interfaces as seen in the baker app?

  3. We're deploying the application into Azure cloud with TomEE Plume (an 8.5 equivalent of Tomcat) as a starting deployment. Are there any special settings that should be included to accommodate that deployment?

We have asked this question on gradual migration previously in the Vaadin forum but without any replies: https://vaadin.com/forum/thread/17468362/17468363

Our immediate goals after the planned migration exercise would be:

  1. Making it modular and easier to incorporate subsequent features such as dynamic data routing, circuit breaker /rerouting, email notification, internationalization, keeping the number of manageable instances to a 5-10 in a production level, etc..

  2. Keeping the avenue for upgrading open without having to rewrite everything from scratch e.g (Java 8 to Java 11, Framework 8 to Vaadin 12) within the next few years.

As said above, this is for running at Azure Cloud with MSSQL database and TomEE Plume container.

We've done some preliminary code modifications including:

  1. Modifying the main pom.xml and include a better maven profiling (using https://www.mkyong.com/maven/maven-profiles-example/ as reference)

  2. Moved the hibernate and spring settings to application.properties files

  3. Added the application-context.xml and divide it again to application-context-dao.xml and application-context-service.xml to make it manageable.

Web.xml 

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath*:applicationContext.xml</param-value>
</context-param>

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<listener>
    <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>

<servlet>
    <servlet-name>SycardaDashboard2</servlet-name>
    <servlet-class>com.example.dashboard.DashboardServlet</servlet-class>
    <init-param>
        <param-name>UI</param-name>
        <param-value>com.example.dashboard.DashboardUI</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>SycardaDashboard2</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

application-context.xml

<beans>
    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
            <list>
                <value>classpath*:application-development.properties</value>
                <value>classpath*:application-production.properties</value>
            </list>
        </property>

    </bean>
<import resource="classpath*:applicationContext-dao.xml" />
<import resource="classpath*:applicationContext-service.xml" />

<context:component-scan base-package="com.example.dashboard">
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
</beans>

application-dao-context.xml

<!-- Activates scanning of @Autowired -->
<context:annotation-config/>

<!-- Activates scanning of @Repository -->
<context:component-scan base-package="com.igi.sycarda.dashboard.dao"/>

<bean class="org.springframework.orm.hibernate4.HibernateExceptionTranslator"/>
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

<bean id="sessionFactory" class="org.springframework.orm.hibernate5.LocalSessionFactoryBean" destroy-method="destroy">
    <property name="dataSource" ref="dataSource" />
    <property name="packagesToScan">
        <list>
            <value>com.example.dashboard.entities</value>
        </list>
    </property>
    <property name="hibernateProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}</prop>
            <prop key="hibernate.query.substitutions">true 'Y', false 'N'</prop>
            <prop key="hibernate.cache.use_second_level_cache">true</prop>
            <prop key="hibernate.cache.use_query_cache">true</prop>
            <prop key="hibernate.cache.region.factory_class">org.hibernate.cache.ehcache.EhCacheRegionFactory</prop>
            <prop key="current_session_context_class">thread</prop>

            <prop key="show_sql">${hibernate.show.sql}</prop>
            <prop key="format_sql">${hibernate.format.sql}</prop>
            <prop key="use_sql_comments">${hibernate.use.sql.comments}</prop>
        </props>
    </property>
</bean>

<!-- Transaction manager for a single Hibernate SessionFactory (alternative to JTA) -->
<bean id="transactionManager" class="org.springframework.orm.hibernate5.HibernateTransactionManager">
    <property name="sessionFactory" ref="sessionFactory"/>
</bean>

For a start, after first week of migration, we expect the app to still be 90% JavaEE, and one or two functions will be in Spring. After each week of updates, the number of existing features will shift into using Spring until it is fully incorporated.

Solution

  • Such migration is possible. You have multiple questions in the question I will answer only two of them.

    1. Is gradual migration possible ? Yes it is possible, and you can either center it first on the bottom layers - your DAOs and Repositories in the case of complex monolith. Or you can try to slice your application into small logical units and try to migrate those unit. Example of such slicing would be if we have e-commerce site a service calculating the price of an Item. It is a clearly defined service that can be easily isolated. Doing such approach would also give you better overview over how you would like to modularize your application. Sometimes though such approach may be too difficult with big monoliths where the code is just to sphagetti.
    2. Spring Data usage and migration of existing Daos. It is not a must that you use spring-data. Having DAOS or manually written Repositories is perfectly fine. No need to put extra effort, or doing extra work with such migration in my opinion.

    IMO your main target during the migration should be doing sensible modularisation and spitting the monolith into logical units. I am not talking about separate deployables and microservices, it is not necessary to go so far. But splitting it logically may provide you with migration map.