5.2. Packaging

The SpringSource Application Platform supports two OSGi-oriented ways of packaging applications: the Platform Archive (PAR) format and application modules.

An OSGi application is packaged as a JAR file, with extension '.par' for platform archive. 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 manifest specifies following manifest headers:

Table 5.1. PAR file directives

DirectiveDescription
Application-SymbolicNameIdentifier for the PAR which, in combination with Application-Version, uniquely identifies a PAR
Application-NameHuman readable name of the PAR
Application-VersionVersion of the PAR
Application-DescriptionShort description of the PAR


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
	

A module offers OSGi-oriented packaging that supports specific application personalities. In this release, the only supported application personality is "Web".

Platform Archive with Web Personality Module

The most common type of application deployed in SpringSource Application Platform is, not surprisingly, the web application. The platform, therefore, supports a concept of "Web module". A Web module is an OSGi bundle whose manifest includes directives to support various options pertinent to a web application.

Web modules have the following advantages over WAR files:

  • Dependencies can be referenced rather than bundled in WEB-INF/lib
  • Dependencies are accessed via an export signature and so their internals can be controlled
  • External dependencies can be installed once, thus reducing footprint and deployment overhead of the web module
  • Web modules have explicit identifying metadata and so can be handled straightforwardly as exploded directories
  • Web modules are OSGi bundles and so can benefit from dynamic update, fragment attachment for I18N, etc.
  • Web modules can be Spring DM powered.

Web modules are standard OSGi bundles with the following characteristics:

  • Packaged within a PAR as an OSGi bundle with a ".jar" extension.
  • Required bundle manifest headers: 'Platform-ModuleType: Web'.
  • Optional bundle manifest headers (as described in the next table).
  • ApplicationContext:
    • A web module must publish an ApplicationContext configured via standard Spring-DM extender semantics (e.g., /META-INF/spring/*.xml).
    • This application context will actually be an OSGi specific implementation of ConfigurableWebApplicationContext.
    • In addition, this application context will be used as the WebApplicationContext for a DispatcherServlet which will be automatically configured. Thus, the context configuration files loaded by Spring-DM must contain all web related components (e.g., Spring MVC Controllers, Filters, SWF, Spring Security, etc.).
    • There is no need for a /WEB-INF/applicationContext.xml or /WEB-INF/<dispatcher servlet name>-servlet.xml, because
      1. web module will not have a root WebApplicationContext, and
      2. a DispatcherServlet will be automatically configured to use the WebApplicationContext created by Spring-DM
  • Directory structure similar to a standard WAR.

Web modules support the following manifest headers to describe web application defined by a bundle.

Table 5.2. Web module directives

DirectiveDescription
Bundle-SymbolicNameUsed as the 'display-name' for the web application, if the Bundle-Name is not set. It is also used as the 'description' for the web application, if the Bundle-Name and Bundle-Description are not set.
Bundle-NameUsed as the 'display-name' for the web application. It is also used as as the 'description' for the web application, if the Bundle-Description are not set
Bundle-DescriptionUsed as the 'description' for the web application.
Web-ContextPathUsed as the unique context path under which the web module or WAR is deployed in the Servlet Container. Standard syntax rules apply. If not present, the file name for the bundle without the file extension will be used as the context path.
Web-ContextParamsUsed to configure context parameters. It uses the syntax of comma-separated list of: <name>;param-value:="<value>" <name> is the name of the context parameter and <value> is the value of the named context parameter
Web-FilterMappingsUsed to declare a Filter with a given 'filter-name'. The 'filter-class' will be set to a subclass of DelegatingFilterProxy. Thus the supplied name must map to the bean name of the corresponding Filter in the web module's ApplicationContext. For each Filter, you must configure corresponding mappings via the url-patterns directive. It uses the syntax of comma-separated list of: <name>;url-patterns:="<patterns>" where <name> is the filter bean name and <patterns> is a comma-separated list of 'url-pattern' values. The syntax of each individual value is as defined in the Servlet spec. The default value for this header is '*.htm'
Web-ServletsUsed to configure servlets. It has the syntax of a comma-separated list of: <name>;servlet-class:="<class>";load-on-startup:="<startup>";url-patterns:="<patterns>", where <name> is the servlet name, <class> is the fully qualified class name of the servlet, <startup> is an integer representing the "load on startup" order, and <patterns> is a comma-separated list of 'url-pattern' values for servlet mappings. The syntax of each individual value is as defined in the Servlet spec.
Web-DispatcherServletUrlPatternsUsed for mapping request URLs to the auto-configured DispatcherServlet for the web module. It uses the syntax of a comma-separated list of 'url-pattern' values. The syntax of each individual value is as defined in the Servlet spec. The default value for this header is '*.htm'
Web-SessionTimeoutUsed as the 'session-timeout' value. The default value for this directive is 15
Web-WelcomeFilesUsed to specify the welcome files as defined by the servlet specification. The default value for this header is 'index.jsp,index.html'

Let's see use of these headers in an example.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.springframework.showcase.formtags
Bundle-Version: 2.0.8
Bundle-Name: Spring Form Tags - Sample Web Application
Bundle-Description: Sample web application which demonstrates the use of Spring 2.0's
 custom form tag library
Import-Package: org.springframework.osgi.web.context,
 org.springframework.osgi.web.servlet,
 org.springframework.showcase.formtags.domain;version="2.0.8",
 org.springframework.showcase.formtags.service;version="2.0.8",
 org.springframework.showcase.formtags.validation;version="2.0.8",
 org.springframework.showcase.formtags.web;version="2.0.8"
Import-Library: org.springframework_all;version="2.5.3";sharing:=share
Platform-ModuleType: Web
Web-ContextPath: formtags
Web-ContextParams: javax.faces.DEFAULT_SUFFIX;param-value:=".xhtml",foo;param-value:="bar"
Web-Servlets: FacesServlet;servlet-class:="javax.faces.webapp.FacesServlet";
 load-on-startup:="2";url-patterns:="*.faces",
 FooServlet;servlet-class:="com.example.FooServlet";
 load-on-startup:="1";url-patterns:="*.foo"
Web-DispatcherServletUrlPatterns: *.htm
Web-FilterMappings: securityFilter;url-patterns:="*.htm,*.jsp",
 imageFilter;url-patterns:="/image/*"
Web-SessionTimeout: 30
Web-WelcomeFiles: index.jsp, index.htm