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://..."),
> > > 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 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.
> 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://..."),
> > > 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 Mon, Mar 24, 2008 at 1:00 PM, Kalle Korhonen <[EMAIL PROTECTED]>
wrote:
> 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://..."),
> > > 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).
I thought the problem you ran into is that the service your client wants to
consume somehow does not come with xsds. Then you work around this by using
a local copy of WSDL and xsds. You do not need to reset endpoint address as
long as you have set it correclty in your local WSDL, e.g "http://localhost:9000/XMLService/XMLPort"/>". In case you want to
override endpoint address, you can use ENDPOINT_ADDRESS_PROPERTY as this is
the most standard way to do it.
Another thing is that I dont think you need to use Service.create(new
URL("http://..."). You have run wsdltojava
to generate client stubs, havent you? A concrete service implementation
class should have been generated by wsdltojava (per JAX-WS 2.1 spec 4.1.1.2,
Static case), its easier to use this class directly instead of using
Service.create(). eg:
StockQuoteService ss = new StockQuoteService(wsdlURL, serviceQname);
Greeter port = ss.getSoapPort();
other than
Service ss = Service.create(new URL("http://<
http://some.server/service?wsdl>", serviceQname);
Greeter port = (Greeter)ss.getPort();
Having said that, the StockQuoteService indeed calls Service.create(...)
internally. So if you really want to use Service.create(...) direclty, just
make sure you provide it with a local copy of wsdl, also make sure the
endpoint address in your local wsdl is correct.
Cheers,
Jervis
>
> 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://..."),
> > 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 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://..."),
> > 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
Hi Kalle, comment in-line.
Cheers,
Jervis
On Mon, Mar 24, 2008 at 5:39 AM, Kalle Korhonen <[EMAIL PROTECTED]>
wrote:
> 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://..."),
> 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:
public static void main(String args[]) throws Exception {
if (args.length == 0) {
System.out.println("please specify wsdl");
System.exit(1);
}
URL wsdlURL;
File wsdlFile = new File(args[0]);
if (wsdlFile.exists()) {
wsdlURL = wsdlFile.toURL();
} else {
wsdlURL = new URL(args[0]);
}
System.out.println(wsdlURL);
SOAPService ss = new SOAPService(wsdlURL, SERVICE_NAME);
Greeter port = ss.getSoapPort();
.
}
> 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
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?
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.
HTH,
Glen
[1] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1
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://..."),
> 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 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://..."),
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
The catalog manager might help, but, really, Glen's suggestion will lead to
much faster performance.
On Sun, Mar 23, 2008 at 1:47 AM, 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.
>
> HTH,
> Glen
>
> [1] http://www.jroller.com/gmazza/date/20070929
>
>
> 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
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.
HTH,
Glen
[1] http://www.jroller.com/gmazza/date/20070929
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
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
