Apache Muse - The Abstract WSRF Capability
Spec name and port type: WS-ResourceFramework v1.2 (and any capability that depends on it)
Capability URI: Provided by concrete capability types.
Description: Muse defines an abstract base class that provides a simple feature in addition to those offered by the core Capability and AbstractCapability types. AbstractWsResourceCapability ensures that any resource class that is using the concrete capability is of type WsResource, and thus has a ResourcePropertyCollection. Based on this knowledge, the abstract class tries to discover and validate the resource properties defined by the concrete capability during its initialization.
Java interface: org.apache.muse.ws.resource.WsResourceCapability
JAR file: muse-wsrf-api.jar
Default Java implementation: org.apache.muse.ws.resource.impl.AbstractWsResourceCapability
JAR file: muse-wsrf-impl.jar
Action on initialize(): For each property name returned by the
getPropertyNames() method, the class will determine if there is a appropriate
getter (method of form getFoo()) and setter (method of form setFoo()).
There must at least be a getter; setters are only needed if the property is
writeable.
Assuming the appropriate getter and setter are available, the class then
registers the capability with the resource's ResourcePropertyCollection; this
action will result in the ResourcePropertyCollection delegating all WSRP
operations for the capability's properties to the its get/set methods.
Action on initializeCompleted(): None.
Action on prepareShutdown(): None.
Action on shutdown(): None.
Non-Core Dependencies:
- org.apache.muse.ws.resource.WsResource
- org.apache.muse.ws.resource.properties.ResourcePropertyCollection
Behavior and Limitations:
The getter and setter methods for the resource
properties must be of the form get{LocalName} and set{LocalName},
where {LocalName} is the local name of the property's QName. Assuming
each capability defines its properties in its own schema namespace, there
should be no name clashes with other capabilities' properties and methods.
The {LocalName} portion of the method must be the exact local name,
even if the property has a cardinality greater than zero; in other words, if
a property can have multiple values, its getter and setter name cannot use the
plural form of the name. For example, if a capability defines a property
{http://ws.apache.org/muse/test/example}Foo, the getter and setter for the
property must be named getFoo() and setFoo() even if the property is [0..n]. The
names getFoos() or setFoos() will result in an initialization error.
Properties with a cardinality greater than one should be represented in their
getters and setters with arrays. Users may use whatever they like to store the
values internally (Java Collections Framework, persistent data store, etc.),
but the values must come in and out as arrays.
When the class encounters a property that has a cardinality of [0..1] and
is also nillable, the getProperty() method will return an empty Element
(null value) to the ResourcePropertyCollection if the value of the property
is null. This is not 100% correct because the property could have no value,
so returning one value (null) would be wrong. In general, it is best to
avoid this ambiguity when defining your property schemas. However, if you
must have such ambiguity, and the default behavior is not what you want,
you can change the behavior by overriding the getProperty() method and
taking special action for the property in question; just remember to call
super.getProperty() to deal with the other properties in the capability!
Initialization parameters: None.