]
Adrian Brock moved JBAS-78 to JBCOMMON-80:
------------------------------------------
Project: JBoss Common (was: JBoss Application Server)
Key: JBCOMMON-80 (was: JBAS-78)
Component/s: common-core (2.x)
(was: JMX)
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: