1. The method name getOperationDescsByNameInstance is rather awkward, but since, as you say, AXIS won't use it, I won't complain. This method would be used by things outside AXIS, or by extensions to AXIS (I'm having some visions, but they're still a bit foggy, so there's no sense describing them at the moment. It might just be bad peyote.)
2. My concern here has been packaging more than actual dependence. If we ever wanted to package axistools.jar outside of axis.jar, we'd now have to include bits and pieces of axis.jar inside of axistools.jar. If these were ever shipped separately, and then customers put them both on their CLASSPATH, we have the potential of inconsistent classes. Russell Butek [EMAIL PROTECTED] Glen Daniels <[EMAIL PROTECTED]> on 03/31/2002 07:44:09 AM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: Skeletons 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
