Hi Manu, What do we are going to keep in repository/conf? Is it all configurations for that app or just the env dependent configs? My point is, if apps have env independent configs, where do we keep them. If we keep them too in repository/conf, then that would not be scalable. So, are we going with two locations for configs or ??
How about loading configs from each app by looking at the repository/conf directory? i.e. They can override the config from repository/conf directory. If it has one, then that will be picked, else what can be seen within the app will be picked. But, not sure how would be the experience when we have the same config in two places. /Ruchira On Fri, Apr 25, 2014 at 12:16 PM, Manuranga Perera <[email protected]> wrote: > Hi Chintana, Sagara, > you are correct about the user written apps. this discussion is about > jaggery apps we ship by default with wso2 products. > > > On Thu, Apr 24, 2014 at 4:14 PM, Chintana Wilamuna <[email protected]>wrote: > >> First of all I think the subject of the mail is a bit misleading or my >> understanding of Jaggery is incomplete. Jaggery, to me should always be >> like PHP or NodeJS. There shouldn't be any impose from the platform for >> rigid config locations. This comes from the Java app server mindset. >> >> Application developer should have the freedom to have any config file in >> any format anywhere. Is it not? >> >> -Chintana >> >> >> On Fri, Apr 18, 2014 at 10:37 AM, 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 >>> >>> >> >> >> -- >> Chintana Wilamuna >> Architect - Solutions Architecture >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> phone: +94 72 145 4545 >> blog: http://engwar.com/ >> photos: http://flickr.com/photos/chintana >> linkedin: http://www.linkedin.com/in/engwar >> twitter: twitter.com/std_err >> > > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > -- *Ruchira Wageesha**Associate Technical Lead* *WSO2 Inc. - lean . enterprise . middleware | wso2.com <http://wso2.com>* *email: [email protected] <[email protected]>, blog: ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, mobile: +94 77 5493444*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
