[ http://issues.apache.org/jira/browse/MUSE-25?page=all ]
Dan Jemiolo closed MUSE-25.
---------------------------
Resolution: Fixed
I have completed the first part of this item - persistence of resource
instances and the routing table - and am going to close it and open individual
issues for both WSN and WSSG persistence.
In order to set up persistence, one must:
1. Add the <persistence/> element to the muse.xml file, and fill in the
"location" and the class that is handling the persistence.
a. The class muse be an instance of
org.apache.muse.core.routing.RouterPersistence
b. There is a default, org.apache.muse.core.routing.FilePersistence, that
writes EPRs to disk as little XML files. These files are grouped by resource
type (context path).
c. When using FilePersistence, a new EPR XML file will be created for each
resoruce instance, and will be deleted if/when the resource is destroyed.
d. When the app server reboots and the Muse app is started again, the
FilePersistence class will look in the directory specified (and resource type
subdirectories below that) for XML files with EPRs in them. It will create a
resource instance for each one it finds and assign it this pre-existing EPR.
2. If one wishes to auto-create N instances of a particular resource type, he
should no longer use the instances-at-startup attribute - it has been removed.
Instead, simply create the appropriate number of XML files with unique EPRs and
put them in $persistence-location/$context-path, where $context-path is the
same value in the /resource-type/context-path element in muse.xml.
Example:
/test-wsrf
/WEB-INF
/services
/muse
/META-INF
/wsdl
/router-entries <-------------- value from persistence-location
/WsResource <----------- a context-path from muse.xml
resource-instance-1.xml <------- XML file with EPR
in it
resource-instance-2.xml
> Persistence API and implementation for standard capabilities
> ------------------------------------------------------------
>
> Key: MUSE-25
> URL: http://issues.apache.org/jira/browse/MUSE-25
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Resource and Capability APIs
> Affects Versions: 2.0.0 M1
> Environment: Axis2 and OSGi
> Reporter: Dan Jemiolo
> Assigned To: Dan Jemiolo
> Fix For: 2.0.0 M2
>
>
> The requirements are that:
> 1. On shutdown, addressable resource instances be saved so that they can be
> reloaded the next time the Muse-based application is started.
> a. The reloaded instances should have the same identity (in terms of
> WS-A EPR) and state (WSRP and other internal values).
> b. The reloaded instances should be created before any new
> instantiations are performed and any requests are handled.
> 2. The format of the persisted resources should be XML.
> a. The persisted resources should be grouped under one root element
> that will contain all of the resource instances at the time of persistence.
> b. Authors of capabilities should be able to control the way their
> state is persisted without affecting the persistence of other capabilities.
> They can control how much is stored in the XML representation vs. stored in
> some other data store; similarly, on re-load, they may retrieve some values
> from the XML and some from the other data store.
> c. In the case where all of a capability's state is persisted in
> another data store, the user can override the default persistence mechanism
> to perform these read/write tasks, and the XML representation of the
> capability will be empty.
> 3. The persistence feature should reuse Muse's Serializer API to find out how
> to read/write the values of each capability. This will allow us to add in the
> persistence feature without modifying the deployment descriptor schema.
> 4. Users should be able to invoke the persistence API to write/save data
> during non-shutdown times to make sure important changes are recorded.
> 5. It should be possible to provide an optional persistence implementation
> using XStream. The muse-util-xstream module could be updated to contain
> serializers for all of the standard capabilities. The XStreamSerializer class
> could be the foundation for this simple implementation.
> a. XStream has a means of preventing duplicate object instantiation (if
> the object tree turns out to be a graph), but we should be extra diligent in
> our investigation of this to make sure we don't introduce bugs that will take
> a long time to fix.
> i. WS-N NotificationProducer and SubscriptionManager is the
> test case I'm think of.
> I propose that the API and schema additions for persistence look something
> like the ones below. Note that most users should not have to interact much
> with these lower-level APIs - they will use the current Serializer interface
> to provide serialization of their capabilities for the persistence framework.
> In the Muse deployment descriptor:
> <muse>
> <router>
> <java-router-class/>
> <logging/>
> <!-- ADDITION TO CURRENT DESCRIPTOR -->
> <persistence>
> <persistence-file>some-file-name.xml</persistence-file>
> </persistence>
> </router>
> ...
> </muse>
> This file would be overwritten each time the resources were saved. The format
> of the file would be:
> <router-instance>
> <resource-instance>
> <context-path>/the-unique-path</context-path>
> <endpoint-reference>
> some epr type (WSA or derivation)
> </endpoint-reference>
> <capability>
> <capability-uri>the-unique-uri</capability-uri>
> <java-capability-class>the-impl-class</java-capability-class>
> <capability-instance>
> - capability-specific XML that stores properties and other state
> - the user has control over how this looks
> - our XStream serializer could provide this
> </capability-instance>
> </capability>
> ...
> </resource-instance>
> ...
> </router-instance>
> Recording the context-path of the resource allows us to associate with the
> resource-type element in muse.xml, and we can fill in all of the other
> resource fields using that descriptor. the EPR and capability fields are what
> change at runtime, so they are the actual state preservation.
> At initialization time, the resource router would look for the persistence
> file named. If it existed, for each resource instance it found, it would
> create the given resource type and set the resource's EPR to the one in the
> file. The capabilities would then be re-initialized from XML (using
> serializers registered for those types) and added to the resource (using the
> addCapability() method). This whole process would be very similar to the
> auto-creation of new resources at startup.
> At shutdown time, the reverse of these tasks could be used to create the
> file. Once again, the serializer for the capability type would be used to
> create the XML.
> We should try to implement the capability serializers using the
> XStreamSerializer class because it would save us a lot of time, and any
> idiosyncracies would be hidden because the persisted XML is not avaiable to
> remote clients.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
