Significant progress has been made on this campaign.  The interfaces for
interacting with JPA have been created and the new ResourceHome implementation
is written.  At the moment, however, this campaign is being set aside in order
to focus on bug 5613 (http://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=5613)

The scope of this bug has been clarified.  As part of this bug a new Interface
called ResourceStore has been created which abstracts the storage of resources.
 Three ResourceStore implementations are slated for completion.  The first is a
simple In-Memory Store which has transient storage of resources in a
ConcurrentHashMap.  When the container is shutdown, the resources in this Store
will disappear.  The second Store implementation is a FileSystem store.  This
store persists resources to the file system using the excellent Xstream
library.  As a result, the resources are in human readable xml (if there is
such a thing).  The resource will be saved in 3 separate files within a zip
file.  There will be a document for the key, a document for the resource
lifetime (if applicable) and a document for the actual resource.  This will
make searching for resources simpler and faster.  The FileSystem will be
supported by cache services provided by the EHCache library.  This is an
extremely high performance caching system which is commonly used in J2EE
applications.  It also is compatible with Terracotta, so caching could be
distributed down the line.  The final Store will use JPA as originally
specified in this bug, as the mechanism of storage.  These three storage
mechanisms should provide most users what they need for persistence, but
implementing a custom ResourceStore is quite easy.

The implementation exists in th branch bug_5616.  The base implementation is
fully backwards compatible with previous versions of java wsrf core.  However,
a couple of changes have been made.  The homemade version of the cache code has
been replaced with the excellent EHCache project.  This provides a lot of
flexibility and reliability to our caching.  Also, the synchronized collections
have been replaced with ConcurrentHashmap from the java concurrent backport.

The new persistence code has been implemented using the JPOX JDO implementation
and JPA implementation.  The focus for the moment is on the JDO implementation
because it does not rely on Java 5, making this code backwards compatible. 
However, the JPA (Java 5 persistence) is also available.  JDO provides a rich
persistence mechanism with XML metadata. 

Documentation on how to upgrade service persistence to use the new mechanism
will be available soon.

I have merged in the updates for this campaig into trunk.  There are 4
implementations present: PersistentResource, Xstream, JDO, and JPA. They all
rely on the new ResourceStore interface which extends the current ResourceHome
interface.  ResourceHomeImpl has been deprecated, although ResourceHome has not
and will not be.  Existing code should work fine, but for more details on a
specific migration path to the new code, see
http://www-unix.mcs.anl.gov/~trhowe/WSRF_Globus/WSRF_Persistence/index.html

Tom,

I see no commits to trunk from you and don't see any new classes in my trunk
checkout after a update -dP. I see commits to bug branch. Did you merge with
trunk? 

Rachana

I specified the wrong link in my last update (and then got sick).  Here is the
link for the docs.

http://www-unix.mcs.anl.gov/~trhowe/persistence/index.html

>I specified the wrong link in my last update (and then got sick)

That will teach you to specify the wrong link.

Code has been merged into both trunk and the 4.2.0 branch