axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <bu...@us.ibm.com>
Subject RE: Skeletons
Date Sun, 31 Mar 2002 17:35:27 GMT
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
butek@us.ibm.com


Glen Daniels <gdaniels@macromedia.com> on 03/31/2002 07:44:09 AM

Please respond to axis-dev@xml.apache.org

To:    "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
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



Mime
View raw message