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.
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
