Add 'value' attribute to the 'uri-variable' sub-element [INT-2463]

[spring-operator]

Gunnar Hillert opened INT-2463 and commented

In order to better align the 'uri-variable' sub-element with other similar elements such as e.g. the 'property' sub-element for the enrichers - "<introperty name="" value="" expression=""/>",
add the 'value' property to provide static parameters.

---

Affects: 2.1 GA

Issue Links:

• Document using the "path" attribute with HTTP inbound adapters [INT-2443] #6422 Document using the "path" attribute with HTTP inbound adapters
  ("depends on")
• Reference Doc - Make Http Components sections more generic [INT-2456] #6437 Reference Doc - Make Http Components sections more generic
  ("depends on")
• Document Timeout Attributes in XML Schema for HTTP Components [INT-2461] #6442 Document Timeout Attributes in XML Schema for HTTP Components
  ("depends on")
• Document "path" Attribute of HTTP Inbound Gateway in XSD Schema [INT-2458] #6439 Document "path" Attribute of HTTP Inbound Gateway in XSD Schema
  ("depends on")
• add support for URI variable population based on expressions in HTTP outbound adapters [INT-1349] #5347 add support for URI variable population based on expressions in HTTP outbound adapters

[spring-operator]

Artem Bilan commented

The similar issue is noticed in the 'uri-variable' sub-element of 'ws:outbound-gateway'.
Also there is no any description about 'uri-variable' ability for 'ws:outbound-gateway' in the 'Web Services Support' paragraph of the Reference Manual.

[spring-operator]

Artem Bilan commented

Changes into manual and XSD should be done after merging 'dependens on' issues.

[spring-operator]

Mark Fisher commented

Sorry to be late to make this comment, but what is the rationale for having 'value' in the uri-variable subelement? If someone is going to use a literal value, they would include it in the url, i.e. there would be no reason to use a placeholder.

[spring-operator]

Artem Bilan commented

Good catch, Mark!
I've also thought before about it as you. However I found some interesting scenarios:
Although we can include values directly into URL, we may provide placeholders like this:

<uri-variable name="foo" expression="'bar'"/>

However we also can make some trick:

<uri-variable name="foo" expression="'#{someBean}'"/>

and use in this case any SpEL-expression, which will be invoked on context startup.

So, Mark, if you think it's enough to use SpEL-evaluation for 'uri-variable', than we just make appropriate changes into Reference Manual as we discuss with Gunnar in the PR #373 and improve WS paragraph as I noticed above.
Nevertheless note we can do the same trick in the 'enricher' 'property':

<enricher>
  <property name="name" expression="'original name'"/>
  <property name="age" value="42"/>
</enricher>

[spring-operator]

Mark Fisher commented

The ability to use init-time SpEL evaluation and property placeholders even for a "value" (not "expression") might justify including the attribute. Although... I haven't checked, but it actually should be possible to include those within the top-level "url" attribute anyways.

One other consideration would be escaping... perhaps that would be handled differently in the "value" attribute than for values (with chars requiring escape) directly in the "url" value?

[spring-operator]

Gunnar Hillert commented

Regarding escaping...Since XML attributes have their own issues, would it make sense to also allow:

<uri-variable name="foo">
<![CDATA[some weird characters !@#!$^&(^&&$^><</]]>
</uri-variable>
?

[spring-operator]

Artem Bilan commented

SpEL evaluation ... within the top-level "url"

Yes, it works

One other consideration would be escaping

Right now 'escaping' is done on the background using org.springframework.web.util.UriTemplate instance.

XML attributes have their own issues

It also works:

<uri-variable name="testString" expression="'some weird characters !@#!$^*&amp;(*^&amp;&amp;$^>&lt;&lt;/'"/>

So, what will we decide? :-)

[spring-operator]

Oleg Zhurakousky commented

Artem, as I stated in the other JIRA the release is immanent so I am moving this to M2. Also, once in M2 let's talk about this one as I am not sure we have to do anything at all simply based on the fact that 'expression' and 'value' are mutually exclusive and you can easily pass the value with expression by simply wrapping it in single quotes. I do understand consistency argument but may be we should start thinking of refactoring other components the other direction (e.g., removing 'value') anyway, let's talk later

[spring-operator]

Artem Bilan commented

The issue is closed as 'Won't fix' in pursuance of described investigations above and plans of removing 'value' attribute at all.