Java Reference
In-Depth Information
Figure 11.5
A typical WAR layout
more easily understandable for WAR developers, and, most critically, it allows the WAR
to continue being used as a WAR and as a WAB !
Changing the default internal classpath of an OSG i bundle can be easily achieved
using the Bundle-ClassPath header. This takes a comma-separated list of classpath
locations, which can either be folders or JAR files, that are specified relative to the root
of the bundle. If you were trying to make the WAR from figure 11.5 work in OSG i, then
you would need to set the classpath as follows:
Bundle-ClassPath: WEB-INF/classes, WEB-INF/lib/myLib.jar,
When your WAR has correctly specified its internal OSG i classpath, then you're much
closer to being able to get it running. In the majority of cases, you still won't be able to
load any of your classes. The internal classpath of a bundle is only a small part of the story.
The key piece of information missing from your WAR is the most fundamental part of
making your WAR into an OSG i bundle; it's the modularity statement, the set of pack-
ages that you want to import. Some of the packages that need to be imported are obvi-
ous; for example, we would wager that your WAR needs to import javax.servlet and
javax.servlet.http .
Supported versions
Over the life of the Java EE specifications, there have been a number of versions of
the Servlet Specification. The OSGi Web Applications Specification defines support
for version 2.5 of the Servlet Specification. As a result, you shouldn't rely on being
able to migrate Servlet 3.0 applications to an arbitrary OSGi web container. On the
other hand, the OSGi Web Applications Specification does allow for implementations
to support Servlet 3.0 applications. If you do need to use Servlet 3.0 in your applica-
tion, then make sure that your container supports it, and also remember that the cor-
rect semantic version for the Servlet 3.0 package is 2.6 .
Search WWH ::

Custom Search