Migration and integration - Enterprise OSGi in Action - page 279

Working out what other imports your WAR needs can be simple, or it can be difficult;
it depends completely on how complex your WAR file is. You may need to add imports
for packages used in your servlets, but it's also possible that you may not, if the code is
supplied by a JAR in WEB-INF /lib. There may even be some dependencies needed by the
library JAR s in WEB-INF /lib! If your dependencies are nontrivial, then you can use trial
and error to find out what packages you need, but there are also tools that offer smarter
ways to approach this. Because most portable WAR s have few dependencies (other than
on the servlet API ), we'll leave discussing these tools in detail until section 12.1.3.
The webbundle URL scheme
Another approach you can use to get WAR files running in an OSGi framework is the
webbundle URL scheme. The OSGi Web Applications Specification defines a URL
handler for URLs that start with webbundle: . If you install a bundle using this URL,
then the WAR file it points at will be automatically converted into a WAB. The web-
bundle URL scheme is a compound URL, so the first thing after the webbundle: is
the real URL to the WAR. After this part of the URL, you can add one or more param-
eters using URL query syntax. These parameters can be used to configure manifest
headers for things like the WAB context root, as in the following example:
webbundle:file://myFolder/myWarFile.war?Web-ContextPath=myContextRoot
Although the webbundle URL scheme might seem like an easy option for using a WAB
in OSGi, we wouldn't recommend it as a primary option. The reason for this is simple.
You never get an OSGi bundle! Having installed your WAR using the webbundle URL
scheme, you never get access to the generated WAB. This makes the WAB hard to
debug and hard to reuse.
EVOLVING BETTER MODULARITY
You may remember that back in section 5.3.1 we recommended avoiding library JAR s
in OSG i WAB s. The main reason for this is that it reduces the degree to which you can
share classes and bundles in the runtime. If you're bringing a WAR into OSG i, then
you're likely to have libraries inside it. We don't think it's reasonable to ask you to
completely remove all of these library JAR s immediately, which is why we added them
to the bundle classpath. If the WAR file is going to be really modular, then you
shouldn't be packaging JAR s inside it.
What you can do is to break out the library JAR s one at a time. Removing a library
from the WAB will require you to add some more package imports to the WAB (unless
the JAR wasn't being used), but it will allow other bundles to share the same library
instance, reducing the memory footprint. In some cases, you may find that the library
you're using isn't available as an OSG i bundle. In this case, you can either leave the
library in your WAB or use the information in section 12.1 to help you obtain an OSG i-
bundled version.
Following these guidelines should allow you to migrate any WAR file to OSG i, but
WAR files are only one part of the Java EE specification. What do you do with some of
the other types of modules?