On Thu February 19 2009 8:41:21 am Benson Margulies wrote:
> No example that I know of, but here's the path to the candy house in
> the woods. Beware of witches with ovens.
>
> Endpoint.publish returns Endpoint. Endpoint can be cast to
> EndpointImpl. EndpointImpl returns Service. Service returns list of
> ServiceInfo. I don't understand exactly why it's a list, I keep
> meaning to ask Dan. 

I'll blame Diephouse on it being a list as he suggested that solution. 

Basically, in WSDL 2.0, each port/endpoint in each "service" in the wsdl MUST 
implement the same porttype.  Thus, you would only need a singleton.

However, in WSDL 1.1, each port could be a different port type.   However, our 
ServiceInfo object represents a single interface (it holds a single 
InterfaceInfo).    Thus, to model WSDL1.1 properly, we needed a way to map 
that.    One way was to make the ServiceInfo hold a list of InterfaceInfo 
objects, but that created a lot of complexities around mapping service methods 
and such to the right interface.    Thus we went this way of having a list of 
ServiceInfo's each corresponding to all the ports that implement a  particular 
portType.    In MOST cases, all the ports implement the same portType, thus 
you get the singleton list.

Dan



> I believe it will always return a singleton list,
> but if not find your particular service on the list, and then you have
> the item to pass to the function you found, which is extremely
> unlikely to melt.
>
> On Thu, Feb 19, 2009 at 8:30 AM, Andrew Clegg <[email protected]> 
wrote:
> > Yeah, as long as you wouldn't say the API is likely to change in
> > future releases, I'm happy hooking into that. (And even if it does, I
> > can fall back to reading the WSDL myself). Is there an example that
> > demonstrates the necessary breadcrumbs?
> >
> > Cheers,
> >
> > Andrew.
> >
> > 2009/2/19 Benson Margulies <[email protected]>:
> >> Superfically, looks like you could call that API, yes. It's used
> >> internally to set up validation. Of course, you'd need to follow a
> >> trail of breadcrumbs to the CXF-specific Service object to get there.
> >> Is that the issue?
> >>
> >> On Thu, Feb 19, 2009 at 7:55 AM, Andrew Clegg <[email protected]> 
wrote:
> >>> So the EndpointReferenceUtils.getSchema( serviceInfo ) approach is
> >>> only for @WebService classes and not @WebServiceProvider classes?
> >>>
> >>> Andrew.
> >>>
> >>> 2009/2/19 Benson Margulies <[email protected]>:
> >>>> CXF does not precisely have a 'copy' of the WSDL. It has a wsdl4j
> >>>> representation.
> >>>>
> >>>> On the 2.2 branch, there is an XmlSchemaCollection of the schemas. In
> >>>> earlier branches, it has a DOM copy of them.
> >>>>
> >>>> We could, I suppose, expose. I'm hoping that Dan will wade in at this
> >>>> point.
> >>>>
> >>>> On Thu, Feb 19, 2009 at 5:42 AM, Andrew Clegg <[email protected]> 
wrote:
> >>>>> Followup...
> >>>>>
> >>>>> So I've got this working by reading the WSDL myself in the provider
> >>>>> class's constructor:
> >>>>>
> >>>>>
> >>>>> // First read WSDL
> >>>>> ClassLoader loader = this.getClass().getClassLoader();
> >>>>> InputStream wsdlFile = loader.getResourceAsStream( WSDL_NAME );
> >>>>> Document wsdl = org.apache.cxf.helpers.DOMUtils.readXml( wsdlFile );
> >>>>>
> >>>>> // Then get schema body from WSDL -- TODO tighten up query using
> >>>>> namespaces String schemaQuery =
> >>>>> "//*[local-name()='definitions']/*[local-name()='types']/*[local-name
> >>>>>()='schema']"; XPathExpression schemaPath = xp.compile( schemaQuery );
> >>>>> Node schemaNode = ( Node ) schemaPath.evaluate( wsdl,
> >>>>> XPathConstants.NODE );
> >>>>>
> >>>>> // Then compile it and store it
> >>>>> String language = XMLConstants.W3C_XML_SCHEMA_NS_URI;
> >>>>> SchemaFactory sf = SchemaFactory.newInstance( language );
> >>>>> DOMSource ds = new DOMSource( schemaNode );
> >>>>> this.schema = sf.newSchema( ds );
> >>>>>
> >>>>>
> >>>>> This lets me easily validate messages in the invoke() method, for
> >>>>> example:
> >>>>>
> >>>>>
> >>>>> schema.newValidator().validate( domRequest );
> >>>>>
> >>>>>
> >>>>> where domRequest is the DOMSource of the message payload.
> >>>>>
> >>>>> However it still seems a little inelegant to read the WSDL myself
> >>>>> when CXF must have a copy.
> >>>>>
> >>>>> I've found the getSchema() method of the EndpointReferenceUtils class
> >>>>> via an old thread on here, but that requires a ServiceInfo object --
> >>>>> is there any way to acquire one of these for a Provider service?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Andrew.
> >>>>>
> >>>>> 2009/2/16 Andrew Clegg <[email protected]>:
> >>>>>> Hi folks,
> >>>>>>
> >>>>>> From inside a Provider implementation, how can I obtain the schema
> >>>>>> of the service's request/response messages, short of reading the
> >>>>>> WSDL myself and extracting the schema from it?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Andrew.
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> :: http://biotext.org.uk/ ::
> >>>>>
> >>>>> --
> >>>>>
> >>>>> :: http://biotext.org.uk/ ::
> >>>
> >>> --
> >>>
> >>> :: http://biotext.org.uk/ ::
> >
> > --
> >
> > :: http://biotext.org.uk/ ::

-- 
Daniel Kulp
[email protected]
http://www.dankulp.com/blog

Reply via email to