Hi Ruchira,

Please share the storagePath element's values for these RXTs.

Thanks,
Senaka.

On Sun, Sep 30, 2012 at 12:50 AM, Ruchira Wageesha <[email protected]> wrote:

> My use case is as below, please give your comment/a better approach if I
> am doing something wrong.
>
> I have 3 rxts called, provider, endpoint, rule.
>
>    - provider can have multiple endpoints.
>    - endpoint can have multiple rules.
>
> Flow is like this. First a provider named "provider1" is created. Then
> "endpoint1" is created. When an endpoint is created, we specify who is the
> provider of that endpoint. Then, it will be stored under provider1. Then
> "rule1" is created. When rule is created, we specify what is the endpoint
> of that rule. Then, rule will be stored under endpoint1.
>
> Then, I want to get all rules under provider1. There is not a direct way
> to get that information except iterating through all endpoints under
> provider1. Hence I wanted to create an association between provider1 and
> rules under endpoint1(automatically when the rule1, rule2.. are created).
> Then, I can get all rules of provider1 by getting those associations.
>
> This cannot be done without specifying relative paths as both provider and
> endpoint values are dynamic for a rule. As I am using the registry WS  API,
> iterating through all endpoints would be inefficient too. In that case, I
> preferred to have an automatic association among provider and rules.
>
> interface
> ├── provider1
> │   ├── endpoint1
> │   │   ├── rule1
> │   │   ├── rule2
> │   │   └── rule3
> │   ├── endpoint2
> │   │   ├── rule4
> │   │   └── rule6
> │   └── endpoint3
> ├── provider2
> └── provider3
>
>
>
>
>
> On Sat, Sep 29, 2012 at 11:52 PM, Senaka Fernando <[email protected]> wrote:
>
>> Hi Ruchira,
>>
>> No we don't support relative paths. As we always understood, it is always
>> possible to normalize the relative path into a full-path, since you are in
>> fact specifying the full-path in the RXT. For example, in this case, it
>> would be /providers/provider.xml (if providers reside inside
>> /_system/governance. I don't think there is a use-case for supporting this.
>>
>> Thanks,
>> Senaka.
>>
>> On Sat, Sep 29, 2012 at 11:50 PM, Eranda Sooriyabandara 
>> <[email protected]>wrote:
>>
>>> Hi Ruchira,
>>>
>>> On Sat, Sep 29, 2012 at 11:03 PM, Ruchira Wageesha <[email protected]>wrote:
>>>
>>>> Is there a particular reason for $subject? If we allow it, then
>>>> automatic association creation would be more useful. i.e. we can specify
>>>> paths like,
>>>>
>>>> <association type="uses"
>>>> target="@{overview_provider}/../../providers/provider.xml"/>
>>>>
>>>
>>> AFAIK, target or source which can be specialized here should be a
>>> complete path. So there won't be any calculation when adding the
>>> association. That's why these are not allowed.
>>> For me its a good to have one, but what is the actual use case of this
>>> improvement?
>>>
>>> thanks
>>> Eranda
>>>
>>>  *
>>> *
>>>
>>>
>>
>>
>> --
>> *Senaka Fernando*
>> Member - Integration Technologies Management Committee;
>> Technical Lead; WSO2 Inc.; http://wso2.com*
>> Member; Apache Software Foundation; http://apache.org
>>
>> E-mail: senaka AT wso2.com
>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>> Linked-In: http://linkedin.com/in/senakafernando
>>
>> *Lean . Enterprise . Middleware
>>
>>
>
>
> --
> *Ruchira Wageesha
> Senior Software Engineer & Member, Management Committee, Development
> Technologies*
> *WSO2 Inc. - lean . enterprise . middleware |  wso2.com*
> *
> email: [email protected],   blog: ruchirawageesha.blogspot.com,   mobile: +94
> 77 5493444*
>
>


-- 
*Senaka Fernando*
Member - Integration Technologies Management Committee;
Technical Lead; WSO2 Inc.; http://wso2.com*
Member; Apache Software Foundation; http://apache.org

E-mail: senaka AT wso2.com
**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
Linked-In: http://linkedin.com/in/senakafernando

*Lean . Enterprise . Middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to