On Sat, Apr 21, 2012 at 3:05 PM, Hiranya Jayathilaka <[email protected]>wrote:
> > > 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? > Yes. Will finish off the remaining stuff so that we are good to go 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 > Thanks, -- Nuwan Dias Software Engineer - WSO2, Inc. Integration Technologies Team email : [email protected] Phone : +94 777 775 729
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
