Hi Rajith, We are using a similar method (retrieveConfig), https:// github.com/wso2/product-microgateway/blob/master/ components/micro-gateway-cli/src/main/resources/templates/ httpEndpoint.mustache#L2
Bdw, what is the use of instanceId in getConfigValue method? Other than that, those two methods are the same it seems. Thanks! On Tue, Jul 17, 2018 at 11:54 PM, Rajith Roshan <[email protected]> wrote: > Hi Malintha/Chamila > > On Thu, Jun 28, 2018 at 12:11 AM Malintha Amarasinghe <[email protected]> > wrote: > >> Hi Chamila, >> >> A small suggestion for the implementation: I think this will be >> relatively easier if we define a function to get a particular config from >> env variable name (input 1) or from the default value (input 2) (if env >> variable is not defined). Then we can use this function name straight in >> the codegen templates. I think the function can be defined in the ballerina >> lib sources in the gateway core so that can be reused easily. >> > > We already has the function in [1]. For me this feature is a simple three > line fix to call this function in httpEndpoint.mustache, > failoverEndpoin.mustache and lbEndpoint.mustache template files :) > > Thanks! > Rajith > > [1] - https://github.com/wso2/product-microgateway/blob/master/ > components/micro-gateway-core/src/main/ballerina/gateway/ > utils/utils.bal#L293 > >> >> Thanks! >> >> On Thu, Jun 28, 2018 at 12:18 PM, Chamila Adhikarinayake < >> [email protected]> wrote: >> >>> Hi All, >>> >>> I'm implementing a dynamic backend endpoint feature which will provide >>> users the capability to define dedicated backends for the same API. >>> >>> >>> >>> >>> >>> This feature is a bit similar to what we have in API Manager where we >>> define endpoints with variables and resolve it during the runtime (say we >>> set backend endpoint as http://{uri.var.host}:{uri.var.port}/apis/weather >>> and resolve them using system variables, etc). >>> >>> Similarly, We plan to provide a method to override the backend endpoint >>> uri from the API. But this method doesn't depend on whether the URL is >>> defined with template structure (with {uri.var.host}, etc). >>> >>> For example, If there is an API with TestAPI and version 1.0, we could >>> define *TestAPI-1.0.prod.**ep* , *TestAPI-1.0.sand.ep* as environment >>> variables, value in the TOML format or as command-line parameters and >>> override the existing related endpoint during the startup time. If the >>> properties are not provided, then we use endpoint defined in the API as the >>> default endpoint. >>> >>> This way, a user can start the micro-gateway with the default backend >>> endpoint or he can override it during the startup time. This will give the >>> capability to call dedicated endpoints for each environment >>> >>> Chamila. >>> >>> -- >>> Regards, >>> Chamila Adhikarinayake >>> WSO2, Inc. >>> Mobile - +94712346437 >>> Email - [email protected] >>> Blog - http://helpfromadhi.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Malintha Amarasinghe >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Rajith Roshan > Senior Software Engineer, WSO2 Inc. > Mobile: +94-717-064-214 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Malintha Amarasinghe *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
