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. - 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
