Java Reference
In-Depth Information
searched automatically, although their default is the same as for normal bundles,
META-INF
/persistence.xml.
CREATING A PERSISTENCE BUNDLE MANIFEST
In addition to specifying the
Meta-Persistence
header, persistence bundles have to
define all of the other
OSG
i metadata you would expect for an
OSG
i bundle. Unlike
the web bundles you migrated in section 11.2.1, persistence bundles are unlikely to
need to specify an internal classpath, because the default is nearly always correct. This
means that persistence bundle manifests are usually simpler to author than web bun-
dle manifests. Importantly, you still need to make sure that the persistence bundle
imports the right packages; for example,
javax.persistence
is almost always needed.
An example persistence bundle manifest is shown in the following listing.
Listing 11.2
Specifying a custom location for the persistence descriptor
Manifest-Version: 1
Bundle-ManifestVersion: 2
Bundle-SymbolicName: basic.persistence.bundle
Bundle-Version: 1.0.0
Meta-Persistence: persistence/descriptor.xml
Import-Package: javax.persistence
If your entity classes are complex, or your persistence bundle contains data access
code as well as the managed classes, you may find that your imports are too complex
to manage by hand. If this is the case, then, as for web applications, we suggest looking
at some of the tooling options described in section 12.1.3.
MISSING IMPORTS FOR JAVAX.PERSISTENCE AND OTHER PACKAGES
If your persistence bundle contains a persistence descriptor and managed classes, but
no code that persists them or retrieves them, then it's likely that you'll only use the
javax.persistence
package to access annotations. Because of the way annotations
work, it's possible to load a class even if the annotations it uses aren't on the classpath.
In this case, the annotations won't be visible to the runtime. This means that it's possi-
ble for your persistence bundle not to import
javax.persistence
, and for your man-
aged classes to still be loadable!
This may seem innocuous, or even helpful, but it can lead to some extremely nasty
problems—many of which are horrendous to debug. What's worse is that some of the
problems can be subtle, or even implementation dependent, and easily missed until
they cause a huge production failure costing thousands, or even millions, of dollars.
What exactly is this problem, and how does it cause such awkward problems?
Annotations are used by a large number of enterprise technologies, such as
JPA
,
EJB
s, servlets, and Spring, to provide configuration and mapping information. This
information is critical if the technology is to work correctly, and so its presence or
absence results in huge behavior changes. The problem with a missing package
import for annotations is that the annotations are still visible if you know where to
look! Any annotation with a retention policy of class or runtime is compiled into the
