Good to know.

Sent from my Android phone
On 23/10/2013 8:05 AM, "Daniel Kulp" <dk...@apache.org> wrote:

>
> 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
>
>

Reply via email to