Hi Russell!
> 1. I would prefer that the Skeleton interface contain the method > getOperationDescsByName. It doesn't cost much. The > skeletons can still > implement the static method, and the instance methods could > do nothing more > than call the static method, but the instance method DOES buy > us something. > It allows us to call the method directly rather than > introspect on it if we > have the skeleton class itself. I assume you mean "the skeleton object itself", and I'm not sure there's really going to be a case where we will, since the introspecting is all happening on a Class level. I guess I'll leave it for now, but I'll call it getOperationDescsByNameInstance(), because I think it's nicer to leave the "core" name on the static method as that'll be the one most used. > 2. I had hoped at one time that we could keep the emitters > separate from > the runtime. But I've virtually lost this battle over time. They've > gotten more and more interdependent. Replacing the WSDL generation > framework's introspection with the ServiceDesc introspection > is just one > more nail in this coffin. Since it seems a hopeless case to pull the > emitters and runtime apart, maybe I should just stop whining. > Just felt > like whining one more time. Hmm... I'm not sure that your concern here is really warranted. If you think about it, what's going on is that we're putting a design around the concept of "a structure that represents services/classes, operations/methods, and their XML-related metatadata". This stuff doesn't tie in to the whole Handler architecture, or to the Serializer/Deserializer system, or even to the MessageContext or Message structure - it's really quite well modularized, I think. If you take a look at the code in ClassRep/MethodRep/etc, you'll note some really striking similarities to what we're now doing in ServiceDesc - so I just want to coalesce all this into using a single model. I don't think that ties the Emitter code particuarly tighter to the rest of the engine, only to this model. > One question: you still believe it should be a fault if the meta data > exists in BOTH WSDD and skeleton, right? So WSDL2Java will emit the > metadata in either the deploy.wsdd OR in the skeleton, but never both. Yup. --Glen
