1. It picks the first capability it finds with a match - it won't tell you there's an ambiguity.
2. If the capability entries have unique URIs, you should be okay. The capability object will be 'initialized' twice, but if your logic is idempotent (or you check for this case), it will load fine and requests will be delegated without a problem. 3. Spreading N logical capabilities across one actual capability implementation class is, in general, okay. Trying to spread one logical capability across multiple classes is not really possible - you'll need a wrapper class that can delegate to the various classes. "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 06/28/2007 03:11:33 AM: > I have two questions: > > 1) Suppose I have two capabilities which contain the same method name > and signature. If a client invokes that operation, how does Muse know > which capability to call? > > 2) Does Muse allow a resource to have two instances of the same > capability type attached to it? So far, in muse.xml, each capability > must have a unique URI. But related to question #1 above, if I have two > same capability classes listed, but each with a unique URI, can Muse > still handle this properly? > > I have a situation where, on the same resource instance, subscriptions > created by a remote client and those created internally must be kept > separate. So notifications going to the client's subscriptions must not > go to the internally generated subscriptions, and vice versa. The > easiest way approach would be to have two NotificationProducer > capabilities, and one will be accessed internally only. But, I don't > believe this will work because I don't think Muse would know which > capability to call for a client's request.
