An easier way might be the following:
1. Extend
org.apache.muse.ws.resource.properties.impl.SimpleResourcePropertyCollection
and override these five methods:
deleteResourceProperty(QName, Object)
getResourceProperty(QName)
hasProperty(QName)
insertResourceProperty(QName, Object[], Object)
updateResourceProperty(QName, Object[], Object)
These are the only methods that actually push down on the Capability API
to get/set property values. If you override them to use whatever dynamic
API/system you have for reading/writing properties, you don't need to
worry about loading the property data into the collection. You can just do
all the reads/writes/checks dynamically. Be sure to look at the existing
methods for tips on what types of faults you should throw.
2. Extend org.apache.muse.ws.resource.impl.SimpleWsResource like so:
public class MyWsResource extends SimpleWsResource
{
protected ResourcePropertyCollection createPropertyCollection()
{
return new MyResourcePropertyCollection() // defined in
step 1
}
}
3. Modify muse.xml so that the <java-resource-class/> refers to
MyWsResource instead of SimpleWsResource.
4. build. run.
"Rosberg Mattias" <[EMAIL PROTECTED]> wrote on 02/15/2007
06:57:10 AM:
> As indicated by my previous posts on the Muse forums I'm trying to
create a
> system that uses Muse to create resource properties dynamically,
starting from
> scratch when the system starts up. Since I don't know my properties in
advance
> it's not possible for me to create the corresponding getters and setters
in my
> Capability (that extends AbstractWsResourceCapability)
>
> This gives me problems when initializing my capability since the
reflection
> part in AbstractWsResourceCapability.createGettersAndSetters doesn't
find the
> correct method in my capability.
>
> A solution for me would be to handle my getters and setters in a more
generic
> way like overriding getProperty and setProperty and route all get and
set
> calls to these methods. The problem is that I can't access the
_gettersByQName
> and _settersByQName Maps since they are private in
AbstractWsResourceCapability.
>
> Is it be possible to make these members protected instead (a change
request on
> the code)? Many of the AbstractXXX classes might have similar members
that it
> might be wise to make protected in order to supply enough flexibility
for
> anyone extending these classes to fit their needs. I leave this to the
muse
> developers to decide/comment.
>
> /Mattias
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
