Moving to a factory creation style which allows the base Axis2 implementations to not contain any clustering code sounds simplest and most attractive to me.
David On 21/10/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi Rajith, Please see my comments below. On 10/20/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > Deepal, > > Thanks for your answers, I really appreciate it. > > >There is an id associate with ServiceGroupContext , so once you have SGC > >from the you can get the service context . Then the id of the SC will be > >the name of the corresponding AxisService. > That is what I did so far, but service name is not a unique id. > However can a service by the same name can exist in a diffrent service group ??? > > For now I use service group id + service name as a unique key. > > >>How big is the jar ? > Deepal we should not have dependency on tribes as our clustering implementation. So even if it's a samll jar we should decouple the clustering impl from the kernal. > Sanjiva also has an idea of using Richochet in the future, so we should be able to implement that without doing too much work. > > >What do you mean by all over th place , as I know all of them are > > created inside instance dispatcher. > > > Sorry if I didn't explain the point properly. > > For example ServiceContext is created inside the getServiceContext() method in the ServiceGroupContext class > then ServiceGroupContext is created inside ConfigurationContext in the method fillServiceContextAndServiceGroupContext () > > What I really wanted to highlight was, not where the places we do a new XXXContext(), but rather if we wanted to control the creation through a factory class then all we have to do is to change it there. Now we have to track down all the places we do new XXXContext() if want to control the creation and we can't avoid to create new type of context, for example ReplicatedServiceContext without introducing a dependency. > > What I would have liked to see is ( if possible) to hide the creation of the context behind a Factory class, so that during creation we could serve a Replicated context instead of a normal context transparently to the code. There is another way. We can introduce a 'replicate' method to the AbstractContext. Each context can override this and have its own replication logic. A a parent 'replicate' method may recursively call it for all the childs. So even if we want to replicate the whole context hierarchy it will be simple as calling this method from the ConfigurationContext instance (we may not want to do that always). BTW is it possible for you to commit the code to some place (scratch?) so that we can see what areas we can help on. Chamikara
-- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
