Override schemalocation when creating a client
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
Re: Override schemalocation when creating a client
On Sat, Mar 22, 2008 at 10:47 PM, Glen Mazza <[EMAIL PROTECTED]> 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
>
>
Re: Override schemalocation when creating a client
On Sun, Mar 23, 2008 at 4:50 PM, Glen Mazza <[EMAIL PROTECTED]> 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
);
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 <[EMAIL PROTECTED]>
> 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
> > >
> > >
>
>
Re: Override schemalocation when creating a client
On Sun, Mar 23, 2008 at 7:57 PM, Jervis Liu <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 24, 2008 at 5:39 AM, Kalle Korhonen <
> [EMAIL PROTECTED]>
> > On Sat, Mar 22, 2008 at 10:47 PM, Glen Mazza <[EMAIL PROTECTED]>
> > > 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
> > 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,
>
> You've got it almost right. You need to point your client to use a local
> copy of wsdl file and xsds etc. But you do not need to hard code the wsdl
> location in your client. Take a look into any CXF sample, for example,
> samples\hello_world. You can see the WSDL location is passed in from
> command
> line or from ant script as below:
>
I think you misunderstood what we are talking about here; not the the wsdl
location but the location of the service (port) (and originally, how
references to imported resources can and should be resolved).
Kalle
Re: Override schemalocation when creating a client
On Mon, Mar 24, 2008 at 12:57 AM, Jervis Liu <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 24, 2008 at 12:54 PM, Kalle Korhonen <
> [EMAIL PROTECTED]>
> wrote:
> > On Sun, Mar 23, 2008 at 4:50 PM, Glen Mazza <[EMAIL PROTECTED]>
> > 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.
>
Ok, ENDPOINT_ADDRESS_PROPERTY it is then. Related to your earlier response;
I don't know the service location at compile time and modifying a local wsdl
at run-time just for the address would be a rather cumbersome approach.
Kalle
> 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 <[EMAIL PROTECTED]>
> > 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
> > > >
> > > >
> >
> >
>
