4.2 Creating PARs and WARs

The SpringSource dm Server supports two OSGi-oriented ways of packaging applications: the PAR format and application modules (including personality-specific modules). The dm Server also supports three distinct WAR deployment and packaging formats: standard Java EE WAR, Shared Libraries WAR, Shared Services WAR.

The also supports plans as a way to describe an application. This method is similar to a PAR in that it encapsulates all the artifacts of an application as a single unit, but differs in that a plan simply lists the bundles in an XML file rather than packaging all the bundles in a single JAR file. The use of plans offers additional benefits to using PARs; for this reason, SpringSource recommends their use. For details, see Creating Plans.

PARs

An OSGi application is packaged as a JAR file, with extension .par. A PAR artifact offers several benefits:

  • A PAR file has an application name, version, symbolic name, and description.
  • The modules of a PAR file are scoped so that they cannot be shared accidentally by other applications. The scope forms a boundary for automatic propagation of load time weaving and bundle refresh.
  • The modules of a PAR have their exported packages imported by the synthetic context bundle which is used for thread context class loading. So, for example, hibernate will be able to load classes of any of the exported packages of the modules in a PAR file using Class.forName() (or equivalent).
  • The PAR file is visible to management interfaces.
  • The PAR file can be undeployed and redeployed as a unit.

A PAR includes one or more application bundles and its manifest specifies the following manifest headers:

Table 4.1. PAR file headers

HeaderDescription
Application-SymbolicNameIdentifier for the application which, in combination with Application-Version, uniquely identifies an application
Application-NameHuman readable name of the application
Application-VersionVersion of the application
Application-DescriptionShort description of the application


The following code shows an example MANIFEST.MF in a PAR file:

Application-SymbolicName: com.example.shop
Application-Version: 1.0
Application-Name: Online Shop
Application-Description: Example.com's Online Shopping Application
			

Web Modules

As discussed earlier, Web Modules are no longer supported in dm Server. Instead, we recommend that you use Shared Service WARs or Web Bundles that are compliant with the OSGi Web Container specification.

Migrating to a Web Bundle from a Web Module

To move from a Web Module to a Web Container-compliant Web Bundle you need to follow these four steps:

  1. Remove the Module-Type manifest header
  2. Replace any Web-DispatcherServletUrlPatterns header with the corresponding servlet entries in web.xml
  3. Replace any Web-FilterMappings header with the corresponding filter entries in web.xml
  4. Move all content in MODULE-INF to the root of the WAR

Removing Web-DispatcherServletUrlPatterns

To remove a Web-DispatcherServletUrlPatterns header such as Web-DispatcherServletUrlPatterns: *.htm, start by declaring a DispatcherServlet in web.xml:

<servlet>
    <servlet-name>dispatcher.myapp</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>

For every mapping in the DispatcherServletUrlPatterns header, create the corresponding servlet-mapping:

<servlet-mapping>
    <servlet-name>dispatcher.myapp</servlet-name>
    <url-pattern>*.htm</url-pattern>
</servlet-mapping>
Removing Web-FilterMappings

To remove a Web-FilterMappings header such as Web-FilterMappings: myfilter;url-patterns:="*.htm", start by declaring DelegatingFilterProxy in web.xml for each filter listed:

<filter>
	<filter-name>myfilter</filter-name>
	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

For every mapping listed for the filter create the corresponding filter-mapping:

<filter-mapping>
    <filter-name>myfilter</filter-name>
    <url-pattern>*.htm</url-pattern>
</filter-mapping>