One of the problems I keep running into with the stock components is that I must always redeploy my .esb archive in order to make what would appear to be runtime configuration changes to our ESB implementation.

For example: Imagine a service that uses the HttpRouter to contact a remote service, the address of which could change occasionally. As my endpointUrl is locked-up inside the jboss-esb.xml file, I must modify that file and redeploy to redirect the HttpRouter to the new address.

Ideally, the HttpRouter endpointUrl would be modifiable by a web gui we write and take effect without a redeploy. Currently, the only way I see to make this config value dynamic is to marshall out the new config to disk and wait for the redeploy.

I guess the point of this post is to propose an alternate configuration method for actions. This dynamic configuration could be accomplished if actions would accept the name of a class that could be interrogated for the required configuration parameters.

<action name="action1" class="com.example....">
 <property name="message" value="I dislike hardwired values."/>
 <property name="echoCount" value="2"/>
</action>

could alternately be expressed as

<action name="action1" class="com.example....">
 <property name="config-bean" value="com.example.FooServiceConfigBean"/>
</action>


public class FooServiceConfigBean() {
 public getMessage();
 public getEchoCount();
}

Of course, this would require some way to flag the config bean as having been updated with a new config value. Otherwise actions would have to reconstruct durable resources for each process() call, which would be horribly inefficient. Access to the config values could be provided through reflection (assuming that the JavaBeans naming standard is adhered to) or by allowing each action to provide a inner public static interface that the config bean would be expected to implement.

I realize that it doesn't make sense to modify many of the stock action config parameters at runtime, but I can't believe that it's necessary to force a redeploy for trivial changes like updating the address of an HttpRouter. Does anybody else have a use for this sort of functionality?

I know, I know, check it in and my wish will be granted.....if I weren't already working overtime, I would happily contribute.