Mailing-List: contact cxf-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jervisliu@gmail.com
 designates 66.249.82.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=R6k0kVoRZAdRzTvHIcH92xWqVtZ1rAkFQ6Ok6zQPNUMOME5JEpRM9OdS/NHXycaMa0Z22wZXSgqOOucUH5PSeonlDR00awQs6l7L1wgZGqSeLKjAzAfI5VROgfvUyUvR6YJngcsqJ3l7Fhblx8qp2/tPhvB5Z8yAclhZCVT0mT4=
Message-ID: <797beb000803240057i6602b099o1a32d52e1a3b11c0@mail.gmail.com>
Date: Mon, 24 Mar 2008 15:57:13 +0800
From: "Jervis Liu" <jervisliu@gmail.com>
To: cxf-user@incubator.apache.org
Subject: Re: Override schemalocation when creating a client
In-Reply-To: <7281ca710803232154x55b72e49y7c332c3b99a88e44@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_8932_24865780.1206345433973"
References: <7281ca710803221628xe82cbc5l7503ec19f064e472@mail.gmail.com>
	 <1206251232.10432.6.camel@gmazza-desktop>
	 <7281ca710803231439i24b9b2e2h74bba61deec46653@mail.gmail.com>
	 <1206316221.11178.6.camel@gmazza-desktop>
	 <7281ca710803232154x55b72e49y7c332c3b99a88e44@mail.gmail.com>

------=_Part_8932_24865780.1206345433973
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Mar 24, 2008 at 12:54 PM, Kalle Korhonen <kalle.o.korhonen@gmail.com>
wrote:

> On Sun, Mar 23, 2008 at 4:50 PM, Glen Mazza <glen.mazza@verizon.net>
> wrote:
>
> > I have not coded that way before, nor needed to.  Can you not just set
> > the ENDPOINT_ADDRESS_PROPERTY as done here[1], step #7?
>
>
> That would work, but I don't think it's any easier or more correct than:
>        QName newServicePort = new QName("urn:some:service", "newport");
>        service.addPort(newServicePort,
> javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING,"http://newserver/service
> ");
>        servicePort = service.getPort(newServicePort,
> ServiceInterface.class
> );


You only use addPort in the case of using Dispatch on your client side. This
is because ports created in this way contain no WSDL port type information.
In the code snippet you gave above, for any port you created by using
service.addPort(), it wont be returned by service.getPort(...). In CXF,
service.getPort(..) only returns these ports that can be initialized
according to the port type information in WSDL.


> Otherwise, the JAX WS 2.1 specification, in Section 5.2.5.4
> > ("Application-Specified Service") seems to define the manner of making
> > web services calls as you do below.  For XSD resolution, it also
> > requires using either the "catalog facility" defined in Section 4.4 or
> > "metadata documents".  I would guess you would want to create the former
> > for your SOAP client calls to work.
>
>
> Thanks for pointing out section 4.4. I didn't really feel like configuring
> the default XML catalog for the xml parser and didn't see any way of
> providing custom entity resolvers. Hadn't noticed META-INF/jax-
> ws-catalog.xml, that looks exactly like what I was looking for.
>
> Kalle
>
>
>
> > Am Sonntag, den 23.03.2008, 14:39 -0700 schrieb Kalle Korhonen:
> > > On Sat, Mar 22, 2008 at 10:47 PM, Glen Mazza <glen.mazza@verizon.net>
> > wrote:
> > >
> > > > I'm not sure, but I think you're trying to create a dynamic client
> > which
> > > > is unfortunately not working for you.  Hopefully someone else can
> > answer
> > > > your specific question on this, but in the meantime, you might wish
> to
> > > > try the more traditional route of getting the WSDL and XSD's on your
> > > > machine locally, running wsdl2java and then coding your SOAP client
> > > > using the wsdl2java artifacts generated, similar to here[1].  Once
> > done,
> > > > any missing XSD's from the server should no longer be a concern for
> > you.
> > > >
> > >
> > > But it is a concern. I have the generated service stubs, but if I
> create
> > the
> > > service by specifying the the server url (Service.create(new
> > > URL("http://<http://some.server/service?wsdl>..."),
> > > it'll try to fetch the xsds and fails because of that. The same
> doesn't
> > > happen if I point to a wsdl from classpath. I need to be able to
> specify
> > the
> > > service location in code, and obviously I can add a new service port
> > > dynamically (Service.addPort) to make it work. But that's not the
> point;
> > I
> > > believe the spec says the schemaLocation is only a hint and
> furthermore,
> > I
> > > should be able to use the service without forced validation, don't you
> > > think?
> > >
> > > Kalle
> > >
> > >
> > > Am Samstag, den 22.03.2008, 16:28 -0700 schrieb Kalle Korhonen:
> > > > > Hello cxfers,
> > > > >
> > > > > I'm trying to consume some web service with jaxws/cxf. I use
> > > > Service.create(new
> > > > > URL("http://some.server/service?wsdl"), SERVICE_NAME). The
> service's
> > > > wsdl
> > > > > imports xsd with a relative schemaLocation (e.g xsd:import
> > > > > namespace="servicens" schemaLocation="servicens.xsd") , but the
> > .xsds
> > > > are
> > > > > not available through the server (from
> > http://some.server/servicens.xsd),
> > > > so
> > > > > constructing the service (client) fails with
> FileNotFoundException.
> > I
> > > > have
> > > > > the xsds but I don't know how to tell cxf's servicefactory where
> the
> > > > xsds
> > > > > are located. I've seen quite a few other threads on the list
> related
> > to
> > > > > resolving references to xsds but the service is not mine so I
> cannot
> > > > change
> > > > > the references or make the xsds available on the server. If I
> point
> > to a
> > > > > local wsdl, the service factory doesn't even try to resolve the
> > schemas;
> > > > > probably because it's setting the validation off, but I don't know
> > how
> > > > to
> > > > > control that. Anybody able to help me?
> > > > >
> > > > > Kalle
> > > >
> > > >
> >
> >
>

------=_Part_8932_24865780.1206345433973--