Pushpalanka Jayawardhana Software Engineer
WSO2 Lanka (pvt) Ltd [image: Facebook]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.facebook.com%2Fpushpalanka> [image: Twitter]<http://s.wisestamp.com/links?url=http%3A%2F%2Ftwitter.com%2FPushpalanka> [image: LinkedIn]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.linkedin.com%2Fprofile%2Fview%3Fid%3D75175642%26trk%3Dtab_pro> [image: Blogger]<http://s.wisestamp.com/links?url=http%3A%2F%2Fpushpalankajaya.blogspot.com%2F> [image: SlideShare]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2FPushpalanka> Mobile: +94779716248 <http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Dc984892c0c4ca423%26v%3D3.13.2%26t%3D1361257731639%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10> 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. > - 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. > Yes, this will not be a functionality that will be used frequently. But will be useful when we want to add or edit a User Store Configuration, in a environment where shutting down a server is costly. I am not aware of a real production use case at the moment. CCing to Prabath to have some inputs. > > > >> >> >>> 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 ? > The use of UM_DOMAIN_ID is still a mystery to me. I am saying UM_DOMAIN_NAME has to be UNIQUE just because it will rise conflicts in uniquely identifying users. For example if two domains have the same user name 'user1' in each, it's only the DOMAIN_NAME that will differ them (PRIMARY/user1, SECONDARY/user1). It is the DOMAIN_NAME that is used here, not the DOMAIN_ID, as I have seen in the latest version. Thanks a lot for the ideas! > > Thanks, > --Pradeep > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
