[jboss-jira] [JBoss JIRA] Moved: (JBCOMMON-80) Add support for nested property refs to StringPropertyReplacer

Add support for nested property refs to StringPropertyReplacer -------------------------------------------------------------- Key: JBCOMMON-80 URL: https://jira.jboss.org/jira/browse/JBCOMMON-80 Project: JBoss Common Issue Type: Patch Security Level: Public(Everyone can see) Components: common-core (2.x) Reporter: Mike Lueders Assignee: Scott M Stark Attachments: EmbeddedStringPropertyReplacer.java, EmbeddedStringPropertyReplacerTest.java, StringPropertyReplacer.java We're using JBossMQHA and have two, nearly-identical deployments. In addition to the usual host/port differences, we've also got JGroups (JBossCache) to configure. While this can be done using the ServiceBindingManager, (as I understand) it requires complete duplication of the server configurations w/in the bindings file. This is less than ideal, especially when it comes to the JGroups configuration (xslt). We don't need multiple server configurations defined, just need the ability to change the property values based on the active server. For example.. ... <service-config name="jboss:service=Naming" delegateClass="org.jboss.services.binding.ExtendedAttributeMappingDelegate" > <delegate-config portName="Port" hostName="BindAddress"/> <binding port="${jboss.naming.port.${jboss.server.name}}" host="${jboss.bind.address}"/> </service-config> ... Assuming two server deployments ('nodeA', 'nodeB'), we have the following properties declared elsewhere (which JBoss loads before deploying ServerBindingManager).. jboss.naming.port.nodeA=1099 jboss.naming.port.nodeB=2099 The upshot is our JBossMQHA/HAJNDI/JBossCache configuration is all of about 20 lines and is alongside the rest of our application configuration. All that was required to implement this functionality was a different StringPropertyReplacer implementation that supports embedded properties. Unfortunately, the use of that class is via static methods, so I had to copy/rename several services and point them to my implementation. Again, less than ideal. What I'd like is the ability to change/specify the StringPropertyReplacer behavior at deployment time. What I'm not sure about is the best way to get it. Attached is the ExtendedStringPropertyReplacer w/ support for embedded properties, as well as a slightly refactored StringPropertyReplacer which allows for runtime behavior change. If anyone's got ideas on how to better integrate the behavior swithing, I'd be happy to implement.