[ http://jira.jboss.com/jira/browse/JBAS-78?page=history ]
Mike Lueders updated JBAS-78:
-----------------------------
Attachment: EmbeddedStringPropertyReplacerTest.java
> simplify deployment; remove duplication in bindings file
> --------------------------------------------------------
>
> Key: JBAS-78
> URL: http://jira.jboss.com/jira/browse/JBAS-78
> Project: JBoss Application Server
> Type: Patch
> 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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
