Russell,
I assume the metadata you are referring to includes parameter names, parameter modes, SOAPAction value and input/output namespaces. I don't see any of this data in my generated deploy.wsdd files. Looking at the DTD for WSDD, I don't see where this information could be specified. You know much more about this than me. Is this just a matter of me looking at an outdated DTD for WSDD?
> -----Original Message-----
> From: Russell Butek [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 10, 2002 2:23 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Skeleton vs deploy.wsdd for metadata
>
>
> There are some of us that don't believe the metadata belongs in the
> deploy.wsdd file. That's ONLY for deploy info, not metadata info. If
> someone extends AXIS to use a different deployment mechanism
> than AXIS's, a
> deployment mechanism that doesn't allow metadata in it, then
> we need to get
> the metadata from somewhere else. The metadata used to be
> (and still IS!)
> on the skeleton. We COULD conceivably get it from some other
> file - say
> something called skeleton.xml or metadata.xml - but even if
> we did, I'm
> leery about completely erasing the idea of a skeleton from AXIS. The
> skeleton sits between the SOAP engine and the target implementation.
> "Anything can be accomplished with one more level of
> indirection." If we
> ever discover that we'd really like to do something in that
> narrow space,
> the skeleton idea will be there waiting for it. For example,
> at one point,
> before the runtime was aware of holders, the skeleton handled the
> translation to/from holders (so did the stub on the other
> side). This was
> a rather pleasant way of introducing holders without having
> to change the
> runtime. As AXIS grows, we might find some other task that a skeleton
> could do. So I'd like to leave hooks there for it, just in case.
>
> Russell Butek
> [EMAIL PROTECTED]
>
>
> "Volkmann, Mark" <[EMAIL PROTECTED]> on 04/10/2002
> 01:36:48 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> cc:
> Subject: RE: Skeleton vs deploy.wsdd for metadata
>
>
>
>
>
> Russell,
>
> Currently, it doesn't seem that the generated skeleton
> classes provide any
> benefit. I'm sure you have in mind some future benefits that
> I'm not aware
> of. Can you share some of the benefits you anticipate?
>
> My current mode of operation is to modify the generated
> deploy.wsdd file to
> point to my own implementation class, bypssing use of the generated
> skeleton classes.
>
> > -----Original Message-----
> > From: Russell Butek [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 10, 2002 1:01 PM
> > To: [EMAIL PROTECTED]
> > Subject: Skeleton vs deploy.wsdd for metadata
> >
> >
> > Hey, Glen! I THOUGHT we agreed that:
> > 1. If we don't generate the skel, the metadata is in deploy.wsdd
> > 2. If we generate the skel, the metadata is in the skel and
> > NOT in the
> > deploy.wsdd.
> >
> > Take a look at build/working/test/wsdl/sequence. This test
> > follows #2. It
> > has a skeleton which has metadata which you can get by calling
> > getOperationDescByName. But the deploy.wsdd ALSO has the
> > metadata. What's
> > worse, there is NO CODE in the runtime that calls
> > getOperationDescByName!!!
> > So the metadata ALWAYS comes from the deploy.wsdd.
> >
> > Russell Butek
> > [EMAIL PROTECTED]
> >
>
>
> **************************************************************
> *************************
> WARNING: All e-mail sent to and from this address will be received or
> otherwise recorded by the A.G. Edwards corporate e-mail system and is
> subject to archival, monitoring or review by, and/or disclosure to,
> someone other than the recipient.
> **************************************************************
> *************************
>
>
>
***************************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************************
