Hi all, I started looking at the code and found out, that our requirement of separating the configuration from the server code and using n different configurations with one server installation can not be met with the current code base.
Generally I'm also not a fan of dozens of System Properties, but in this case a single property to control the configuration location seems to be worth from my point of view. To demonstrate my ideas I attached small patches against the 1.7-tag of WSO2 ESB. While this patch should also keep the existing behaviour, it shall allow a user to separate all important configuration files from the webapp and thus enable him to use n different configurations with one ESB installation. There are currently some limitations though: - identity.jks, trust.jks and ui-extensions-config.xml need to stay in webapp/WEB-INF/classes/conf due to some other code dependencies. - context.xml, tomcat-users.xml, and web.xml need to stay in tomcat/conf But all important config files can reside in any location specified via system property esb.config.dir Other existing system properties like synapse.xml or axis2.xml have of course precedence of this property, but this property (if existing) has precedence over init parameters from web.xml. esb.config.dir needs to be further added to classpath instead of webapp/WEB-INF/classes/conf and tomcat/conf I didn't try, but it should be sufficient to put esb.config.dir in CLASSPATH before calling the wso-esb-domain.sh, as the wrapper takes the current classpath as the first entry of it's classpath definition. Asankha, what do you think? Do you see better ways to achieve this goal? Having to hack in a bunch of files in webapp/WEB-INF/classes/conf and tomcat/conf can't be the best configuration approach. This way I currently use a template approach where I put placeholders in all the splattered configuration files and are able to configure everything in one central file. Before each startup I copy the filled templates to a central configuration place and let the WSO2 ESB use these. It's really comfortable, no more digging in axis2.xml, tomcat.properties, synapse.properties, server.xml, log4j.properties, and wrapper conf just to configure ports or manage other important settings. I would be happy if these changes or something serves the same purpose would find it's way to your source repo. Regards, Eric We are generally going to drop use of system properties as much as possible in future, but may keep core properties for backwards compatibility. This is because System properties generally creates issues at deployment time.. However, I am fully open to evaluating suggestions for improvement, and if we could capture a proposal as an enhancement request on our JIRA, we will certainly look at the posibilities
startup.patch
Description: startup.patch
core.patch
Description: core.patch
conf.patch
Description: conf.patch
_______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
