Eric Thanks very much for the patches.
I'm sorry to load you with our process, but we can only accept patches that are attached to a JIRA with the "Grant License" checkbox ticked. If you could please create a JIRA and attach these files to that, we would really appreciate it! Thanks Paul Hubert, Eric wrote: > 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 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Esb-java-dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair VP, Apache Synapse Office: +44 844 484 8143 Cell: +44 798 447 4618 blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
