On Fri, May 10, 2013 at 12:29 PM, Pradeep Fernando <[email protected]> wrote:
> > Hi, > > >> After the first start up, UI will be the only way to edit the >> configuration (Except for go and change the storage). That limitation have >> negative points >> But the use of UI is to allow user to add a new configuration without a >> need to restart the server to get it effected. So will it be a big issue? >> > > - Once i configure the server with provided UI, I should be able to use > the server as a building block and populate similar environments. Of course > I can use user-mgt.xml, but if we are providing a new feature it must have > a consistent story across the platform. > - During dev test cycles we often re-start server with cleared database. > So this UI is not usable in day to day test scenarios as well. > This is not a valid argument.. in that case you need to have right db scripts to repopulate the DB.. Thanks & regards, -Prabath > - Do you find a real production use case for this functionality. > Organizations do not configure their use-stores then and there. More often > than not it is a one time thing. In that sense this looks like only a > 'demo' friendly feature. Please prove me wrong. > > > > >> >> >>> IMHO, proper approach would be to de-serialize/serialize from/to the >>> user-mgt.xml. Did you evaluate the option ? may be you encountered >>> technical issues, if so what are they. >>> >> This option was considered. But did not properly evaluated between using >> persistent storage and editing user-mgt.xml itself. >> A point to note will be, >> >> - The order of the uncommented User Store Managers matters, as it >> implies which is the Primary store and the order of Secondary >> stores.(Accordingly should decide on file appending or replacing the whole >> file with the new configuration.) So the flexibility we can provide >> through >> UI, in defining new configurations will be limited accordingly. >> >> This looks like a issue in configuration language. In the provided tables > you are maintaining a field to track the order of user-stores. Likewise the > config xml file should also maintain the same. Here I'm not questioning > the use of order in the configuration as the mechanism for deciding the > priority, It looks fine at the moment. But if you find a real use case, you > can alter the existing configuration language. > > > > UM_DOMAIN_ID is an already existing auto increment column in the >> dbscript. I guess it is used as a counter. >> UM_DOMAIN_NAME is also already defined. With the alteration this will >> also marked as UNIQUE as now the users are stored with the relevant domain. >> (Eg, PRIMARY/user1) >> > Dumb question. Why two unique fields ? > > > Thanks, > --Pradeep > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
