Hi Hasitha, Ideally, we should be able to use Andes as a library. If it requires any config parameters, we should be able to provide them programmatically through the API, similar to how Mina, Netty frameworks works. All the config file processing part should be done in a single component in carbon-business-messaging since that's where we write carbon related components.
On Fri, Sep 15, 2017 at 1:29 PM, Hasitha Hiranya <[email protected]> wrote: > Hi Asanka/Vinod, > > Andes can be considered as the transport whereas Carbon-business-Messaging > can be seen as the functional component. > > >> Should we allow AMQP transport (Andes) to be configured separately? > >> Will other protocols be introduced in future (i.e MQTT) so we have to > keep their configs separately? > >> All other broker related functional configs (monitoring/JMX/Users) can > be kept in as CBM configurations? > > Thanks > > On Fri, Sep 15, 2017 at 11:57 AM, Vinod Kavinda <[email protected]> wrote: > >> Hi Asanka, >> I was referring to the configs that are used in Andes (by reading from >> broker.xml). Yes, we don't need to keep them in the server config. >> >> Regards, >> Vinod >> >> On Fri, Sep 15, 2017 at 11:54 AM, Asanka Abeyweera <[email protected]> >> wrote: >> >>> Hi Vinod, >>> >>> What do you mean by the client configs here? Can you give an example? >>> Ideally, we should not keep any client specific configs in >>> deployment.yml (or broker.xml) since the client can reside in a completely >>> different server instance. >>> >>> On Fri, Sep 15, 2017 at 11:32 AM, Vinod Kavinda <[email protected]> wrote: >>> >>>> Hi All, >>>> I'm working on providing support for yaml based configuration in MB4 >>>> based on the C5 model. >>>> >>>> In C4, we had a component in the Andes to read configurations from the >>>> broker.xml file. With the C5 model, there will be only one config >>>> (deployment.yaml) and components can define their own configs with an >>>> object model using a unique namespace. >>>> >>>> So, where should we add the configuration models in MB4? >>>> >>>> 1. We cannot add in Carbon-business-messaging(CBM) component since >>>> this will introduce a circular dependency with the Andes component, >>>> because >>>> Andes also need to read configurations and CBM already depends on Andes. >>>> 2. We can add the configs in Andes component. This is the existing >>>> architecture. But, since we have plans to keep Andes only as the client >>>> in >>>> the future, it will look ugly too when CBM component is reading configs >>>> via >>>> Andes. >>>> 3. We can separate the configurations with two namespaces >>>> (broker,andes) and keep the respective configuration models in both >>>> places. >>>> However, the configs will end-up in the same deployment.yaml file with >>>> different namespaces. >>>> >>>> I would prefer the third option. Because eventually, we will have to do >>>> this any way, to separate out the client and broker configs. >>>> >>>> Please share your thoughts. >>>> >>>> Regards, >>>> Vinod >>>> >>>> >>>> >>>> >>>> Vinod Kavinda >>>> Senior Software Engineer >>>> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* >>>> Mobile : +94 (0) 712 415544 >>>> Blog : http://soatechflicks.blogspot.com/ >>>> [image: http://wso2.com/signature] >>>> <http://wso2.com/signature> >>>> >>>> >>> >>> >>> -- >>> Asanka Abeyweera >>> Associate Technical Lead >>> WSO2 Inc. >>> >>> Phone: +94 712228648 <+94%2071%20222%208648> >>> Blog: a5anka.github.io >>> >>> <https://wso2.com/signature> >>> >> >> >> >> -- >> Vinod Kavinda >> Senior Software Engineer >> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* >> Mobile : +94 (0) 712 415544 >> Blog : http://soatechflicks.blogspot.com/ >> [image: http://wso2.com/signature] >> <http://wso2.com/signature> >> >> > > > -- > *Hasitha Abeykoon* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > > -- Asanka Abeyweera Associate Technical Lead WSO2 Inc. Phone: +94 712228648 Blog: a5anka.github.io <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
