Allow complex paths

[ChristianLangmann]

Using only one attribute for a path is limiting the uniqueness for sources.
E.g. HTTP-Listener could depend on path and port
AMQP could use keys as queues that are declared at a child of the source-element.

A solution could be to allow the path to contain xpath-expressions, for example.

[manikmagar]

Yes, I realized that recently too. Although not for sources but for operations, a slightly different scenario. For example, http:request may use url instead of path attribute. In that case, generated graph is not representing http:request correctly. There is no fallback for path in current version.

About sources, I wonder if multiple attributes are needed. For HTTP Listener, if application is having multiple listener configs, then probably yes. AFAIK, AMQP and similar connectors use single key for source subscription. However, I agree, there are so many connectors and they may have different behaviors :). Defining a (flexible) path value strategy could be helpful. I appreciate the suggestion of xpath-expressions and will look through more connector examples to understand variations of source paths.

[ChristianLangmann]

I've implemented a solution for this in my fork. Please take a look.
You can use "xpath:" in the path, there are two tests you can look at for examples.
I'm afraid I am not really happy yet, as the name of the path in the model is the same as the XPath. I am thinking whether an additional column wouldn't be better...

[manikmagar]

@ChristianLangmann Thank you for the work. I looked at your fork (via commit comparison). Tests were helpful to understand what is being done there. Would you like to raise a Draft PR so we can review/discuss it?

as the name of the path in the model is the same as the XPath

I am not sure if I followed you there correctly. Are you referring to the MuleComponent.path vs XPath:@path?