On Oct 22, 2013, at 1:35 PM, Aaron Titus <ati...@fwdco.com> wrote: > Ok, so I've been trying to track down where in the source code it produces > the WSDL. My services are bottom-up using annotations in the classes. I > don't have a pre-defined WSDL. Can someone point me to the class(es) which > are responsible for generating the WSDL that you get when you go to a URL > of this format: > > http://<hostname>/<webcontext>/services/<ServiceNamePort>?wsdl
That would be the WSDLGetInterceptor, but most likely that's NOT what you want. For the schemas that go into the types, that would most likely be in the JAXBContextCache along with the stuff in the JAXBDataBinding. In particular, the generateJaxbSchemas call in the that creates the DOM's from the JAXBContext. Dan > Thanks in advance! > > > > On Tue, Oct 15, 2013 at 10:48 AM, Aaron Titus <ati...@fwdco.com> wrote: > >> Hi Dan, so this is what I was afraid of. It's not pulling the classes >> from the actual service impl class but rather scanning the entire package. >> Ugh. I cannot remove the object factory (at least I don't think I can) >> because JAXB marshaling will break down. >> >> I would like to look at the CXF code and try to determine the criteria >> exactly for how its pulling in the types -- I would really like to find a >> solution for this because most of the consumers of our API are using SOAP >> typically with .NET, and when they import the WSDL it will create >> duplicates of every type for each service, resulting in hundreds of >> unnecessary duplicate classes. >> >> If necessary I will consolidate everything to a single WSDL, but I'd >> really like to avoid that if I can. >> >> >> >> On Mon, Oct 14, 2013 at 10:19 AM, Daniel Kulp <dk...@apache.org> wrote: >> >>> >>> On Oct 14, 2013, at 9:39 AM, Aaron Titus <ati...@fwdco.com> wrote: >>> >>>> Hi Jason, Thanks for the response, but this does not appear to work for >>>> me, at least not in CXF 2.7.6. I set this property but the WSDL still >>>> includes every single jaxb class within the types section in the WSDL >>> even >>>> though my service doens't even reference them at all. >>> >>> If the classes are JAXB generated from schema, I don't think there is an >>> easy way. JAXB generates an ObjectFactory in the package which pretty >>> much references everything. If the ObjectFactory is found, that's used to >>> grab the types and thus everything would be included. >>> >>> You MAY be able to delete the ObjectFactory and thus avoid that. Not >>> really sure. >>> >>> Dan >>> >>> >>> >>> >>>> >>>> *Aaron Titus* >>>> >>>> On Fri, Oct 11, 2013 at 7:13 PM, Jason Pell <ja...@pellcorp.com> wrote: >>>> >>>>> There is a parameter you can define to prevent this very thing. >>>>> >>>>> <jaxws:properties> >>>>> <entry key="jaxb.scanPackages" value="false" /> >>>>> </jaxws:properties> >>>>> >>>>> See here for an example: >>>>> >>>>> >>>>> >>> https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/resources/META-INF/scanPackagesContext.xml >>>>> >>>>> Sent from my Android phone >>>>> On 12/10/2013 1:25 AM, "Aaron Titus" <ati...@fwdco.com> wrote: >>>>> >>>>>> I am using CXF 2.7.6 and deploying bottom-up web service, using jax-ws >>>>>> annotated classes. I have a half a dozen web services, with 1 to 6 >>>>>> operations each. I noticed that when viewing the WSDL for any one of >>> the >>>>>> services, that it always includes the type definitions for EVERY >>> entity >>>>>> class in the package, even the ones which are never referenced by the >>>>>> specific service. >>>>>> >>>>>> Is there any option to prevent this? In my situation it makes the WSDL >>>>> very >>>>>> large, and it also adds confusion to the developers who are the >>> consumers >>>>>> of the service -- most of them will be inexperienced with web >>> services. >>>>>> >>>>>> Thanks, >>>>>> Aaron >>>>>> >>>>> >>> >>> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
