AbstractWsResourceCapability private members

[Rosberg Mattias <Ma...@tetrapak.com>]

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

Re: AbstractWsResourceCapability private members

[Daniel Jemiolo <da...@us.ibm.com>]

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" <Ma...@tetrapak.com> 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org