@HasithaH - Regarding move of store configs to broker.xml , this will leave us with only qpid specific properties in virtualhosts.xml.
So will it be ideal to move the "qpid-virtualhost" stuff to "qpid-config.xml" and get rid of "virtualhosts.xml" ? That way, we can completely abstract qpid to one configuration file. WDYT ? On Fri, Nov 14, 2014 at 1:16 PM, Hasitha Amal De Silva <[email protected]> wrote: > @Pamod & Ramith - Noted. Will not have a seperate config file for mqtt > since we can re-use broker.xml configurations. Thanks. > > @HasithaH - Thank you for sharing the qpid config information. I will > study if these properties are used now and share the findings soon. > > > > On Fri, Nov 14, 2014 at 6:40 AM, Pamod Sylvester <[email protected]> wrote: > >> Hi Ramith, >> >> The main properties we would have is transport related, such as host and >> the port the server will be bound to this will be included in the >> broker.xml. >> >> in comparison to AMQP, in MQTT all the other properties will be >> dynamically defined by the client (publisher or subscriber) when the >> connection is established. I.e KEEPALIVE time, which will be defined during >> the time client connects. >> >> What's meant is that we do not have much properties pre defined by the >> server which will be applicable to all the clients. >> >> Thanks. >> Pamod >> >> On Thu, Nov 13, 2014 at 11:43 PM, Ramith Jayasinghe <[email protected]> >> wrote: >> >>> What are the properties we need to have for mqtt? >>> >>> On Thu, Nov 13, 2014 at 9:22 PM, Pamod Sylvester <[email protected]> wrote: >>> >>>> Hi HasithaA, >>>> >>>> For MQTT since the transport properties etc will be included in the >>>> broker.xml we might not need a separate config (mqtt-config.xml) IMO. >>>> Cause in MQTT most of the semantics are specified to the server during the >>>> time it connects, AFAIK there're no other pre defined properties for it. >>>> >>>> Thanks, >>>> Pamod >>>> >>>> On Thu, Nov 13, 2014 at 8:57 PM, Hasitha Amal De Silva < >>>> [email protected]> wrote: >>>> >>>>> I am working on $subject and have identified different types of >>>>> configuration parameters within our current pack in [1] >>>>> <https://drive.google.com/file/d/0B1soNraLsHdmLW1manJFaDNDcjg/view?usp=sharing>. >>>>> >>>>> >>>>> *Expectations from the revamp* >>>>> >>>>> - To maintain and unify all MB specific configurations through a >>>>> single access point with a uniform access pattern. >>>>> >>>>> >>>>> - To use more meaningful names for properties. >>>>> >>>>> >>>>> - To organize properties in a sensible hierarchical manner for >>>>> intuitive reference. >>>>> >>>>> >>>>> - Separate external configurations coming from qpid sources >>>>> >>>>> >>>>> - Verify and remove unused configurations (e.g. hector and >>>>> zookeeper related ones) and cluster enabling from "andes-config.xml" >>>>> (cos >>>>> its now done with hazelcast) >>>>> >>>>> >>>>> - Add new configurations introduced in v3.0.0 >>>>> >>>>> >>>>> *Current status of configuration files * >>>>> >>>>> According to the new model the main "broker.xml" will contain links to >>>>> the following sub configuration files : >>>>> >>>>> 1. mqtt-config.xml (@Pamod - Need to check what we have to include >>>>> in this. for now this is empty.) >>>>> 2. qpid-config.xml >>>>> 3. virtualhosts.xml >>>>> >>>>> Please refer attached xml files for modified configuration properties. >>>>> These are still a work-in-progress. Do share your feedback on how it can >>>>> be >>>>> further improved. >>>>> >>>>> *Removing unused properties* >>>>> >>>>> I have removed properties that are read but not used anywhere in code. >>>>> But there's still a few more to carefully remove. >>>>> >>>>> @HasithaH - I noticed that even a few qpid properties are obsolete. >>>>> e.g. "advanced.enableJMSXUserID" in "qpid-config.xml". Should we keep them >>>>> as-is to respect qpid's seperation, or remove after verifying ? >>>>> >>>>> >>>>> *Naming conventions * >>>>> >>>>> I have attempted to break down properties into semantic parent tags as >>>>> much as possible. e,g, instead of using "andesContextStore" in >>>>> virtualhosts.xml we can just use "contextStore". instead of using >>>>> "slotWindowSize" I have added a slot tag in which the "windowSize" >>>>> property >>>>> resides. >>>>> >>>>> The camelCase naming pattern is used throughout. There are few misses >>>>> in attached configs, will be correcting them. >>>>> >>>>> >>>>> *New Properties (Code must be modified to act upon these)* >>>>> >>>>> - virtualhost.xml : "virtualhost.nodeID" - To override the default >>>>> node ID generated through hazelcast (IP + UUID). >>>>> >>>>> >>>>> - broker.xml : "transports.minaEnabled" and >>>>> "transports.nettyEnabled" - To disable the two transports selectively >>>>> in a >>>>> scenario that only one is being used (only mqtt or only amqp*)* >>>>> >>>>> *Explanatory comments* >>>>> >>>>> I have added purposeful comments for some. This is still in progress. >>>>> >>>>> *Access Pattern* >>>>> >>>>> Right now configuration properties are being accessed mainly from the >>>>> "org.wso2.andes.server.configuration.ServerConfiguration" class. This >>>>> class >>>>> was originally from qpid and has been modified to include our >>>>> configurations too. The andes-virtualhosts.xml is read from the >>>>> "business-messaging" component. >>>>> >>>>> The new model exposes all these properties through a Singleton >>>>> container and it is based on apache commons Configuration features [2] >>>>> <http://www.code-thrill.com/2012/05/configuration-that-rocks-with-apache.html> >>>>> [3] <http://java.dzone.com/articles/managing-configurations-apache>. >>>>> >>>>> - Given that "broker.xml" contains links to the sub config files, >>>>> it is loaded as the primary configuration. >>>>> >>>>> >>>>> - All sub configuration files are then combined reading through >>>>> the "links" tag in "broker.xml" >>>>> >>>>> >>>>> - Since the CompositeConfiguration class allows us to access any >>>>> property from all the files after combining, We can then use XPath to >>>>> read >>>>> from the loaded CompositeConfiguration object. >>>>> >>>>> All configuration properties are defined using an Enum format where >>>>> each property has the following attributes : >>>>> >>>>> - keyInFile : xpath expression to find the property from >>>>> CompositeConfiguration object. >>>>> >>>>> >>>>> - dataType : expected datatype of the property >>>>> >>>>> >>>>> - defaultValue : specified default value for the property in case >>>>> it is not set in the files. >>>>> >>>>> This enum-oriented design was based on [4] >>>>> <http://sett.ociweb.com/sett/settNov2012.html>. IMO it reduces code >>>>> duplication and gives a cleaner way to access properties than using string >>>>> literals. >>>>> >>>>> Given this design, a property can be parsed to its expected type and >>>>> accessed by anywhere with the following statement : >>>>> >>>>> >>>>> AndesConfigurationManager.getInstance().getConfigurationValue(BrokerConfiguration.PERFORMANCE_TUNING_SLOTS_WINDOW_SIZE) >>>>> >>>>> Refer attached image "ConfigAccessPattern_MB_3_0_0.png" for more >>>>> details. >>>>> >>>>> *Testing* >>>>> >>>>> Since we use enums to define the properties, A single test case that >>>>> iterates through all properties and reads them should be sufficient to >>>>> verify if any properties are faulty. >>>>> >>>>> However, key MB functionalities should be also verified through >>>>> existing test suite to make sure nothing unexpected is broken. >>>>> >>>>> *TODO* >>>>> >>>>> Refactor "andes" and "business-messaging" code to use the new Access >>>>> Pattern. Remove obsolete code. >>>>> >>>>> Implement actions based on new configuration properties. >>>>> >>>>> Dig into qpid source and identify unused but read properties and >>>>> remove as necessary >>>>> >>>>> Add automated test case for configuration verification. >>>>> >>>>> Review and finalize comments in the configuration files and follow up >>>>> with doc team. >>>>> >>>>> [1] : >>>>> https://drive.google.com/file/d/0B1soNraLsHdmLW1manJFaDNDcjg/view?usp=sharing >>>>> <https://drive.google.com/a/wso2.com/file/d/0B1XfuoFd-MhEeWxiNkFNNk5NMzg/view?usp=sharing> >>>>> [2] : >>>>> http://www.code-thrill.com/2012/05/configuration-that-rocks-with-apache.html >>>>> [3] : http://java.dzone.com/articles/managing-configurations-apache >>>>> [4] : http://sett.ociweb.com/sett/settNov2012.html >>>>> >>>>> -- >>>>> Cheers, >>>>> >>>>> Hasitha Amal De Silva >>>>> Software Engineer >>>>> Mobile : 0772037426 >>>>> Blog : http://devnutshell.tumblr.com/ >>>>> WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. ) >>>>> >>>> >>>> >>>> >>>> -- >>>> *Pamod Sylvester * >>>> *Senior Software Engineer * >>>> Integration Technologies Team, WSO2 Inc.; http://wso2.com >>>> email: [email protected] cell: +94 77 7779495 >>>> >>> >>> >>> >>> -- >>> Ramith Jayasinghe >>> Technical Lead >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> E: [email protected] >>> P: +94 777542851 >>> >>> >> >> >> -- >> *Pamod Sylvester * >> *Senior Software Engineer * >> Integration Technologies Team, WSO2 Inc.; http://wso2.com >> email: [email protected] cell: +94 77 7779495 >> > > > > -- > Cheers, > > Hasitha Amal De Silva > Software Engineer > Mobile : 0772037426 > Blog : http://devnutshell.tumblr.com/ > WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. ) > -- Cheers, Hasitha Amal De Silva Software Engineer Mobile : 0772037426 Blog : http://devnutshell.tumblr.com/ WSO2 Inc.: http://wso2.com ( lean.enterprise.middleware. )
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
