On Sat, Apr 21, 2012 at 1:45 PM, Afkham Azeez <[email protected]> wrote:
> > > On Sat, Apr 21, 2012 at 1:34 PM, Hiranya Jayathilaka <[email protected]>wrote: >> >> On a related note, the way we handle service metadata is, we give >>> precedence to the metadata stored in the metadata repository (earlier this >>> was the config registry). But when the original artifact was changed or >>> re-uploaded, we used to clear out all the data in the metadata repo, and >>> give precedence to the metadata in the uploaded artifact. If the UI is >>> going be there, we should have something similar. Yesterday, we had an >>> issue with the UI based depsync config, then tried to change the settings >>> in the carbon.xml, and were in for a surprise when it was not picked up. >>> Then we had to go into the implementation, and figure out that we would >>> need to go to the registry browser and remove the depsync configuration. >>> This sort of thing may be too much for an average user. >>> >> >> Ok got the point. Up until now we have been recommending users to use one >> of the provided ways to set this up. Trying to use a bit of this and bit of >> that usually leads to conflicts such as the one you have described. >> Implementing something like service persistence is tricky here, since there >> is no 'artifact' object involved with this to detect changes from. What we >> can do is to flip the priority order and give prominence to carbon.xml when >> the synchronizer seems to be enabled in both fronts. I think that should >> take care of the situation you have described and might even be useful when >> somebody first tries out a configuration through UI and then wants to move >> it to carbon.xml. >> > > Yes this was a user error, but we must try to make it difficult for users > to make such mistakes. Looking at some recent support queries, I have > realized that people make all sorts of mistakes when setting up & > configuring clusters, and then raise support queries. It is difficult to > pint point exactly what went wrong, so we have to use an exhaustive > approach to find the issue, which is time consuming and can be frustrating > to the user as well as support personnel. So, perhaps what we could do is, > if depsync is enabled in carbon.xml, give precedence to it, and disable the > DepSync UI with a message that mentions that the UI is deactivated because > the depsync has been enabled in carbon.xml, and ask the user to disable it > in carbon.xml if he want to use the UI. This should be only for the > configuration part. With regards to the part where we show last checked out > time and so on, this also does not make sense in a clustered setup since > that information will vary from node to node in the cluster. > +1 to the proposal. Nuwan D, would you be able to incorporate these improvements for the next release? Thanks -- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
