On Sun, Apr 20, 2014 at 11:35 PM, Chan <[email protected]> wrote: > > > > On Sun, Apr 20, 2014 at 7:26 PM, Madhuka Udantha <[email protected]> wrote: > >> >> >> >> On Sun, Apr 20, 2014 at 12:48 PM, Amila Maha Arachchi <[email protected]>wrote: >> >>> An alternative solution can be proposed based on the nature of the >>> jaggery app. i.e. is it available in the product itself, similar to >>> publisher and store apps of APIM or is it an app you deploy in to AppServer >>> or any other server. >>> >>> 1. If it is packed with the product, you can simply keep the site.json >>> file as a template in puppet or in a suitable way if you are using any >>> other config management mechanisms. >>> >> +1 >> > > How about keeping the configurations in the registry? I don't know how > well puppet plays with config jsons in registry though. >
Puppet cannot deal with registry stuff. But could be done with some amount of work (may be using registry check-in check-out client). IMO, it is an unnecessary thing. > > > >> >>> 2. If the app is deployed in to a server, then it is somewhat difficult >>> to manage the config files. Then, one option is to bundle the correct >>> config file at the build time (using some maven params or ant stuff). >>> >>> I don't think we should change the way how the config is read. This >>> could be done with alternatives according to your requirements. But, there >>> is no concrete solution IMO. >>> >>> >>> On Fri, Apr 18, 2014 at 11:07 PM, Manuranga Perera <[email protected]>wrote: >>> >>>> *Current Implementation* >>>> We currently keep configuration files for jaggery apps within the app >>>> itself (eg: site.json). >>>> >>>> *Issue with Current Implementation* >>>> But this is creating some difficulties in multi environment >>>> deployments. Since the configuration files will contain some environment >>>> specific information (eg: SSO IDP URL), this makes the artifacts >>>> un-portable across environments. >>>> >>>> *Suggested Solution* >>>> We can implement a mechanism where the configuration is read from an >>>> outside location (eg: repository/conf) at deployment time and keep it in >>>> the application context and reuse it. >>>> >>>> >>>> Let's discuss the feasibility of this solution. alternative solutions >>>> are welcome. >>>> >>>> -- >>>> With regards, >>>> *Manu*ranga Perera. >>>> >>>> phone : 071 7 70 20 50 >>>> mail : [email protected] >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> *Amila Maharachchi* >>> Senior Technical Lead >>> WSO2, Inc.; http://wso2.com >>> >>> Blog: http://maharachchi.blogspot.com >>> Mobile: +94719371446 >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Madhuka* Udantha >> Senior Software Engineer >> Development Technologies >> WSO2 Inc. : http://wso2.com >> >> *Mobile*: +94774066336 >> *Blog*: http://madhukaudantha.blogspot.com/ >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Chan (Dulitha Wijewantha) > Software Engineer - Mobile Development > WSO2Mobile > Lean.Enterprise.Mobileware > * ~Email [email protected] <[email protected]>* > * ~Mobile +94712112165 <%2B94712112165>* > * ~Website dulitha.me <http://dulitha.me>* > * ~Twitter @dulitharw <https://twitter.com/dulitharw>* > *~Github @dulichan <https://github.com/dulichan>* > *~SO @chan <http://stackoverflow.com/users/813471/chan>* > -- *Amila Maharachchi* Senior Technical Lead WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
