OK, I wasn't fully up to speed on the new ClusterManager interface. You make a good point... though if someone were to do the Factory work I'd still be +1 :-)
Oh, where is the ClusterManager interface so I can have a better look at it? Thanks, David On 24/10/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi David, I understand that if we were were trying to put some code that is dependent on a particular clustering implementation into Axis2, we need to hide that code. But the situation here is a bit different. What we introduced was a ClusterManager interface. This will live within Axis2. Now should the rest of the Axia2 code be completely unaware of this interface. I think it should not. In this particular scenario i'm talking about some method of Axis2 Context classes which can be called for serializing their states (sorry abt calling it 'replicate' may be we should simply call it 'serializeState'). If somebody have configured Axis2 to enable clustering and if somebody have mentioned an ClusterManager implementation in the axis2.xml. Some methods of it will be also called. I think introducing a factory to create Contexts will introduce an unnecessary complexity. Still there may be many other places where we may directly have to call the methods of the ClusterManager interface. Chamikara On 10/23/06, David Illsley <[EMAIL PROTECTED]> wrote: > > 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] > >
-- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
