| :virgo-name: Virgo |
| :version: 3.7.0.RC01 |
| |
| :umbrella-virgo-name: Eclipse Virgo |
| :tomcat-product-name: Virgo for Apache Tomcat |
| :tomcat-product-name-short: VTS |
| :jetty-product-name: Virgo Jetty Server |
| :jetty-product-name-short: VJS |
| :kernel-product-name: Virgo Kernel |
| :kernel-product-name-short: VK |
| :nano-product-name: Virgo Nano |
| :nano-product-name-short: VN |
| :user-guide: link:../../virgo-user-guide/html/index.html[User Guide] |
| :tooling-guide: link:../../virgo-tooling-guide/html/index.html[Tooling Guide] |
| |
| :gemini-blueprint-guide: https://www.eclipse.org/gemini/blueprint/documentation/reference/2.0.0.RELEASE/html/index.html[Eclipse Gemini Blueprint Reference Guide] |
| |
| :spring-framework-version: 4.2.9.RELEASE |
| |
| :homepage: https://www.eclipse.org/virgo |
| :ebr: http://www.eclipse.org/ebr[EBR] |
| |
| :imagesdir: assets/images |
| |
| anchor:migrating-to-osgi[Migrating to OSGi] |
| |
| == Migrating to OSGi |
| |
| Taking on a new technology such as OSGi may seem a bit daunting at first, |
| but a proven set of migration steps can help ease the journey. Teams |
| wishing to migrate existing applications to run on the {tomcat-product-name} |
| will find that their applications typically fall into one of the following |
| categories. |
| |
| * *Web Application*: for web applications, |
| this chapter provides an overview of the steps required to migrate |
| from a Standard WAR to a Shared Services WAR. Furthermore, the following |
| chapter provides a detailed case study involving the migration |
| of the Spring 3.0 Form Tags show case application. |
| * *Anything else*: for any other type |
| of application, you will typically either deploy your application |
| as multiple individual bundles, as a single PAR file, or as a plan, |
| which is the recommended approach for deploying applications on |
| the {tomcat-product-name}. See xref:migrating-to-osgi-par-plan for details. |
| |
| anchor:migrating-to-osgi-web[] |
| |
| === Migrating Web Applications |
| |
| Many applications may start with the standard WAR format for web applications and |
| gradually migrate to a more OSGi-oriented architecture. Since the {tomcat-product-name} |
| offers several benefits to all supported deployment formats, it provides a smooth |
| migration path. Of course, depending on your application's complexity and your |
| experience with OSGi, you may choose to start immediately with an OSGi-based |
| architecture. |
| |
| |
| anchor:migrating-to-osgi-web-standard-war[] |
| |
| ==== Standard WAR |
| |
| If you are not yet familiar with OSGi or simply want to deploy an existing web application on the {tomcat-product-name}, |
| you can deploy a standard WAR and leverage the {tomcat-product-name-short} with a minimal learning curve. In fact reading the |
| {user-guide} |
| is pretty much all that you need to do to get started. Furthermore, you will gain |
| familiarity with the {tomcat-product-name}, while preparing to take advantage of the other formats. |
| |
| anchor:migrating-to-osgi-web-shared-libraries-war[] |
| |
| ==== Shared Libraries WAR |
| |
| The *Shared Libraries WAR* |
| format is the first step to reaping the benefits of OSGi. In this phase, you dip your toes into OSGi-based dependency |
| management by removing JAR files from the WAR and declaring dependencies on corresponding OSGi bundles. |
| |
| anchor:migrating-to-osgi-web-shared-services-war[] |
| |
| ==== Shared Services WAR |
| |
| In this phase, you take the next step toward a fully OSGi-based architecture by separating your web artifacts |
| (e.g., Servlets, Controllers, etc.) from the services they depend on. |
| |
| anchor:migrating-to-osgi-web-summary[] |
| |
| ==== Web Migration Summary |
| |
| The following diagram graphically depicts the migration path from a Standard WAR to a Shared Services WAR. |
| As you can see, the libraries (*libs*) move from within the deployment artifact |
| to the Bundle Repository. |
| Similarly, the services move from within the WAR to external bundles and are accessed via the |
| OSGi Service Registry. In addition, the overall footprint of the deployment artifact decreases |
| as you move towards a Shared Services WAR. |
| image:migration-path-war-to-shsrv.png[] |
| |
| anchor:migrating-to-osgi-par-plan[] |
| |
| === Migrating to a Plan or a PAR |
| |
| The first steps to migrating an existing application to a plan or a PAR are the same: deciding on the bundles that make up the application and ensuring that their `Import-Package`, `Import-Library`, and `Import-Bundle` manifest headers are correct. Once you have the list of bundles that make up your application, you then decide whether you want to JAR them all into a single application file (PAR) or create a plan that simply lists the bundles by reference. Creating a plan is the recommend way to create an application, although PARs also have benefits that might suit your needs better, as described in xref:migrating-to-osgi-parplan-decide[]. |
| |
| anchor:migrating-to-osgi-parplan-bundles[] |
| |
| ==== Creating the Application Bundles |
| |
| When migrating an existing application to the PAR packaging and deployment format or a plan, |
| you consider modularity as the prime objective. Following the ideas discussed in |
| xref:architecture-forming-bundles[], you refactor the application into multiple bundles. |
| You may start conservatively with a small number of bundles and then further refactor those bundles. |
| |
| If the original code is crafted following good software practices such as separation of concerns and use of |
| well-defined interfaces, migration may involve modifying only configuration and packaging. In other words, |
| your Java sources will remain unchanged. Even configuration is likely to change only slightly. |
| |
| For example, the following diagram depicts a typical web application that has been refactored and |
| packaged as a PAR. The blue elements within the *Application* box constitute |
| the bundles of the application. Each of these bundles imports types from other bundles within |
| the PAR using `Import-Package`. The green elements in the left column represent |
| *libraries* installed on the {tomcat-product-name-short}. The PAR's bundles reference these |
| libraries using `Import-Library`. The purple element in the left column |
| represents a bundle within the {tomcat-product-name-short}'s bundle repository which is imported by the DAO |
| bundle using `Import-Bundle`. In contrast to a traditional, monolithic |
| WAR deployment, the PAR format provides both a logical and physical application boundary |
| and simultaneously allows the application to benefit from both the OSGi container and the {tomcat-product-name}. |
| image:migrating-to-osgi-par-structure.png[] |
| |
| anchor:migrating-to-osgi-parplan-decide[Plan or PAR?] |
| |
| ==== Plan or PAR? |
| |
| Once you have refactored your existing application into separate OSGi bundles, you then must decide whether to package the bundles into a single PAR file or create a plan that lists the bundles by reference. As described in more detail in preceding sections of this guides, PARs and plans have similar benefits, such as: |
| |
| * Scoping |
| * Atomicity, or the ability to deploy and control the bundles as a single unit |
| * Versioning |
| * Improved serviceability |
| |
| Plans, the method most recommended by us to create your application, has the following added benefits: |
| |
| * Guaranteed order of deployment, based on the order in which they are listed in the plan's XML file |
| * Ease of sharing content between plans and updating individual plans without having to physically repackage, due to the artifacts being listed by reference. |
| * Ability to disable scoping and atomicity, if desired. |
| |
| The main benefit of PARS is that, because they physically contain all the required artifacts, you know exactly what bundles are deployed when you deploy the PAR file, in contrast to plans that allow content to be substituted or lost. |
| |
| For details about creating plans and PARs, see xref:developing-applications-plans[] and xref:developing-applications-packaging[], respectively. |