I suspect the DTD for WSDD is out of date. Glen? Comments? For an example of a deploy.wsdd with metadata, look at any of various tests. A particularly useful one is build/work/test/names/deploy.wsdd because it shows a need for metadata. The actual XML operation names are different than the Java names for those methods and, therefore, cannot be discovered by mere introspection.
Russell Butek [EMAIL PROTECTED] "Volkmann, Mark" <[EMAIL PROTECTED]> on 04/10/2002 02:44:21 PM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: Skeleton vs deploy.wsdd for metadata 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. ***************************************************************************************
