Hi Glen, I really like the idea, but one of the reason to introduce that factory was to support clustering requirements. They wanted to have a single place of creating all the Contexts , then they have only one place to worry about. They wanted to have some triggering mechanism when when creating Contexts that is why we introduced that. All the communications are happen in the mailing list , I think Chamikra might remember more than me. I can not exactly remember which mail thread we had that conversation [1] , [2] or some other.
[1] - http://marc.info/?t=117174713500003&r=1&w=2 [2] - http://marc.info/?w=2&r=1&s=clustering+prototype+available&q=t Thanks Deepal Glen Daniels wrote: > Hi folks! > > Recently I was in the midst of writing a test which used ServiceClient > directly (i.e. not a Stub). I wanted to get at the last > OperationContext by using client.getLastOperationContext() but it > wasn't working... turns out this was because there are (at least) two > ways of making an OperationContext and associating it with a > ServiceContext. You could call serviceContext.createOperationContext() > (which as it happens was the place where the code to cache the > lastOperationContext lived), OR you could call > ContextFactory.createOperationContext(AxisOperation, ServiceContext) > directly, which did NOT have the caching code - and this is what was > happening when you used the ServiceClient directly (via > ServiceClient.createClient()). I took a look into this, and came to > the following conclusion. > > I'd like to get rid of ContextFactory entirely, for a few reasons. > First it's confusing to have multiple ways of doing things, and that's > why the above problem occurred. Second, since contexts depend on each > other (it doesn't make sense to have a MessageContext without a > ConfigurationContext, for example), it is a little odd that there are > currently a bunch of ways to build contexts with inappropriately > disconnected references. I think we should be as flexible as > possible, but it should not be possible to build context hierarchies > that aren't really usable (i.e. an OperationContext without a > ServiceContext). Finally, the Factory pattern > (http://en.wikipedia.org/wiki/Factory_method_pattern) isn't really > reflected by ContextFactory - it's neither generating potentially > different versions of a base class interface, nor is it doing a lot of > setup work for you. In fact the work it does could (and should) be > more easily accomplished by simply putting factory methods in the > Context classes themselves. I believe this also simplifies the code. > > So I'm thinking the context generation should work as follows. The > methods which take args should all be protected against nulls. > > cc = new ConfigurationContext() // this one you can just make > > mc = configContext.createMessageContext() > > sgc = configContext.createServiceGroupContext(AxisServiceGroup) > > sc = serviceGroupContext.createServiceContext(AxisService) > > oc = serviceContext.createOperationContext(AxisOperation) > > mc = operationContext.createMessageContext(AxisMessage) > > Thoughts? > > Thanks, > --Glen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Thanks, Deepal ................................................................ "The highest tower is built one brick at a time" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
