Stomp

Description of services.xml metadata.

Stomp is designed to make persistence as transparent as possible. As such, the services.xml metadata required by Stomp is as short as possible. This metadata serves three purposes.

- Tag the classes that need to be enhanced, the ones that you actually want to store in the databases.

- Provide details about how this object should be put into the database, in cases where such details cannot be determined from the source code alone.

- Defines the set of method-level services that should be transparently added to method calls on the enhanced objects.

This last requirement is somewhat advanced and is explained in the docs on configuring and extending Stomp. It is an optional feature of Stomp that you may never need. The first two requirements though, are exactly what JDO vendors need to know to put your objects in the database. As such, the services.xml file is used to auto-generate the package.jdo metadata that your JDO vendor requires. Let’s look at some examples.

Say you had a simple object Foo, which had one persistent field, an int. In this case, your services.xml file would look like this:

<Foo/>

</services>

You are just tagging Foo as a persistent object. All the details of persisting the object can be determined from the source code. Now imagine you had a second object, Bar, which existed in the same package as Foo, and had a persistent Collection of Foos. Your metadata might look like this:

<Foo/>

<Bar>

</field>

</persistence>

</Bar>

</services>

JDO requires that you identify the type of the persistent objects that are going to populate the Collection in metadata, since it cannot be determined from the source code alone. In general, stuff that would normally be placed in a package.jdo file goes under the ‘persistence’ element in your services.xml metadata. In fact, the children of this element are just lifted and placed directly into the auto-generated services.xml file.

As a final example, let’s imagine that you had a third object, FooBar, in a different package. It has a Map of Strings to Bars, and it has a Foo that you don’t want to save in the database. Since FooBar is in a different package, you’ll have a new services.xml file, which will be found in that same package. It might look like this:

</field>

</persistence>

</FooBar>

</services>

Hopefully you get the idea. Just these examples of Collections and Maps should cover most of the cases in which you’ll have to declare anything extra in your services.xml metadata. Refer to the JDO specification for more details about other things that can go under that persistence element. If you have any questions, check out the main page for a place to send them.