Thanks! Paul
Hubert, Eric wrote: > Hi Paul, > > I have absolutely no problem with this. My approach was to first send > the patches to the mailing list for discussion and after this of course > to create a JIRA with the patches in this or a modified version > attached. > > Anyway I can go ahead and create a JIRA, as we can also discuss it as > part of the JIRA process. > > Regards, > Eric > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED] > >> On Behalf Of Paul Fremantle >> Sent: Monday, July 28, 2008 9:45 AM >> To: [email protected] >> Subject: Re: [esb-java-dev] Using one Synapse installation with >> > different > >> configurations >> >> 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 >> > > _______________________________________________ > 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
