Using properties to configure custom surf endpoints

[rentallect]

I like how Spring offers the nice PropertyPlaceholderConfigurer to facilitate using a properties file to complete the values within tokenized xml config files. I am trying to use this technique in xml I use to establish some custom surf endpoints.

I have xml that resembles this:

<endpoint>
<id>my-endpoint</id>
<connector-id>http</connector-id>
<endpoint-url>http://${webscripts.host}:${webscripts.port}/${webscripts.context}/service</endpoint-url>
...
</endpoint>

and the above xml (see com/rentallect/extensions/webscripts/spring-webscripts-config.xml reference below) is processed by the following config :

   
<bean id="web.configsource" class="org.springframework.extensions.config.source.UrlConfigSource">
 <constructor-arg>
   <list>
     <value>classpath:org/springframework/extensions/webscripts/spring-webscripts-config.xml</value>
     <value>classpath:com/rentallect/extensions/webscripts/spring-webscripts-config.xml</value>
     <value>classpath:META-INF/spring-webscripts-config-custom.xml</value>
     <value>jar:*!/META-INF/spring-webscripts-config-custom.xml</value>
    </list>
  </constructor-arg>
</bean>
<bean id="web.config" class="org.springframework.extensions.config.xml.XMLConfigService">
 <constructor-arg>
  <ref bean="web.configsource" />
 </constructor-arg>
 <property name="properties" value="classpath:webscripts.properties" />
</bean>

My app deploys fine, but when I attempt to invoke a webscript that uses the remote endpoint, things splatter. The problem seems to be that the ${} variables are not replaced with the corresponding values from the properties file.

If what I'm attempting to do above is "wrong", can anyone please point out how I might go about using properties to configure custom surf endpoint values.

Thanks.

[chrislack]

I'm not familiar with XMLConfigService and UrlConfigSource but from memory I'm pretty sure that Surf does not define a PropertyPlaceholderConfigurer bean by default so you may need to define one if you haven't already. Also be aware that Surf contains (or contained - this may now have changed in the trunk) an internal configuration which relies on ${blahblah} not being replaced but left as a literal so you will need to change the prefix that you use for PropertyPlaceholderConfigurer, eg "%{".

[rentallect]

I downloaded and cruised through the Surf source code, and I believe I found the problem.

Although the XMLConfigService sets up a PropertyConfigurer (which is an extension to the familiar PropertyPlaceholderConfigurer), the problem is that the RemoteConfigElementReader does not make use of it. In fact, it has no way to reach it based on the current ConfigElementReader interface implementation.

The only "reader" that does make use of the PropertyConfigurer is the GenericElementReader.

Perhaps someone close to the code can explain why the various xxxReader's do not take advantage of the PropertyConfigurer mechanism.

Meanwhile, I may implement some local changes (change the interface and teh various xxxReader classes to tie into the PropertyConfigurer mechanism) and rebuild Surf so it does indeed honor ${foo} variables in children of the <remote> element (like <endpoint-url>).

Until this is done, I see no way of using properties to externally configure Surf end-points.

[kroast]

Hi,

They don't make use of it because they were developed before we moved to SpringMVC as the wrapper for Surf (i.e. when it became SpringSurf), so not all areas are completely "springified" I will attempt to rectify this for the next release.

Thanks,

Kevin

[rentallect]

Kevin, thanks for confirming my suspicions.

Last night, I wrote the necessary updates to teach Surf to honor properties in <remote> elements. My local build passes all tests, and I'll begin to try things out tonight. I'll use this platform until the official support you hinted about comes out somewhere downstream. Any guesses as to time-frame?

Will you and the rest of the 'Surf Gang' be at the upcoming SpringOne conference?

[kroast]

The RC1 release should come out next week. If you are willing to submit your changes as a SpringSurf JIRA item then I'll take a look and merge them into the trunk.

https://jira.springsource.org/browse/SESURF

Cheers,

Kev