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 Thanks in advance! On Tue, Oct 15, 2013 at 10:48 AM, Aaron Titus <[email protected]> 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 <[email protected]> wrote: > >> >> On Oct 14, 2013, at 9:39 AM, Aaron Titus <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >> >>> >> >> >> >>
