The final step in the migration is that of a full blown
OSGi application with web support. The SpringSource dm Server introduces a
new packaging and deployment format: the PAR.
A PAR is a standard JAR with a "
file extension which contains all of the modules of your
application (e.g., service, domain, and infrastructure bundles
as well as a WAR for web applications) in a single deployment unit.
Moreover, a PAR defines both a physical and logical application boundary.
The PAR sample is comprised of four directories, as shown below.
formtags-par directory is a build project that
understands how to create the PAR from its constituent bundles.
Achieving the appropriate level of granularity for your OSGi application is more of an art than a science. It helps to look at the different requirements:
Table 6.1. Granularity drivers
|Domain/Technical Layering||Applications can be split either by domain (i.e., by use case or vertically) or by their technical layers (i.e., horizontally). Since the Form Tags application essentially has only a single use case, the bundles are split by technical layering (i.e., domain, service, and web).|
|Refreshability||A major benefit of OSGi is that of refreshability: if one bundle is changed, only bundles that have a dependency upon the exported types need to be refreshed. This has a high impact on development time costs as well as production costs. However, this can lead to lots of smaller, fine grained bundles. An example of this granularity would be to separate out the service API and implementation into two different bundles. This means that a change in the implementation wouldn’t require any other bundles to be refreshed.|
Ultimately the right level of granularity will depend upon your particular application and team.
|This topic will be revisited in greater detail later in the Programmer Guide in a chapter covering how to build a PAR from scratch.|
The service bundle is identical (except for the
Bundle-SymbolicName) to that
in the shared-services variation of the sample.
The PAR has also separated out the domain classes into their own bundle.
When layering by technical considerations, it is again
somewhat of an unofficial convention to have a
Finally we need to construct the PAR itself. The following are the contents of the exploded PAR.
You can see that the PAR itself doesn’t contain any resources or Java classes: it simply packages together a related set of bundles as a single, logical unit.
The PAR does however, contain its own
Manifest-Version: 1.0 Application-SymbolicName: org.springframework.showcase.formtags-par Application-Version: 1.0.0 Application-Name: FormTags Showcase Application (PAR)
For more information on the contents of the PAR’s
/META-INF/MANIFEST.MF, please consult
Chapter 4, Developing Applications.
You can now deploy the PAR on the dm Server, for example by copying
/dist/formtags-par*.par to the dm Server’s
You should then see console output similar to the following:
The console output has been reformatted to fit this document.
[2009-07-01 15:13:43.306] fs-watcher <SPDE0048I> Processing 'CREATED' event for file 'formtags-par-2.0.0.RELEASE.par'. [2009-07-01 15:13:44.060] fs-watcher <SPDE0010I> Deployment of 'formtags-par' version '2.0.0.RELEASE' completed. [2009-07-01 15:13:44.068] Thread-20 <SPWE0000I> Starting web bundle '/formtags-par'. [2009-07-01 15:13:45.212] Thread-20 <SPWE0001I> Started web bundle '/formtags-par'.
Navigate to http://localhost:8080/formtags-par to see the welcome page.
Note that the web application’s context path is explicitly defined via the