Re: Re : WSDL generate using url ../EchoService?wsdl
Hi, I think they are same, we use the same piece of code in generating the wsdl. However, with java2wsdl you got the extra functions, like generating the jaxb binding files automatically, if your class has a java.util.Date or java.util.Calendar class, Something like that, and also it will generate the wrapper beans, fault beans in case of jaxws. James Hi, It work using like: http://localhost:8080/ecm_syn/services/EchoService?wsdl But I still have the question : Is it a good approach to generate wsdl using an url or using tool java2wsdl is better ? Thanks for your advice Willy - Message d'origine De : "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> À : cfx liste Envoyé le : Vendredi, 13 Juillet 2007, 18h32mn 14s Objet : WSDL generate using url ../EchoService?wsdl Hi, I am using Spring (2.0) and I tried XFire and cxf. With xFire I could get wsdl using an url like: http://localhost:8080/ecm_syn/services/EchoService?wsdl I could not find in documentation how to do the same behaviour with cxf. another question: Is it a good approach to generate wsdl like this or should I use java2wsdl ? below the Spring configuration: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";; xmlns:jaxws="http://cxf.apache.org/jaxws";; xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";;> id="echoService" implementor="ch.vd.dsi.syn.ws.server.EchoServiceImpl" address="/services/EchoService" /> Willy _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
RE: WSDL service-name
Yes.
> -Original Message-
> From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 14, 2007 12:17 AM
> To: cxf-user@incubator.apache.org
> Subject: Re: WSDL service-name
>
> I'm pretty sure that per the JAX-WS spec, the serviceName goes on the
impl
> class regardless. So I think you still need @WebService on the impl
and on
> the interface. Does that answer your question?
>
> - Dan
>
> On 7/13/07, Benson Margulies <[EMAIL PROTECTED]> wrote:
> >
> > Out of curiosity, if I wanted the primary source of annotations to
be
> > the interface, then the cure would be to put endpointInterface on
the
> > interface?
> >
> > > -Original Message-
> > > From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, July 13, 2007 5:46 PM
> > > To: cxf-user@incubator.apache.org
> > > Subject: Re: WSDL service-name
> > >
> > > If you take away the serviceFactory.setServiceclass() line I think
> > it'll
> > > fix
> > > your problem. Effectively you're telling CXF not to look at the
> > > @WebService
> > > annotation on the NameIndexServiceImpl, which I don't think is
what
> > you
> > > want
> > > to do :-). CXF will automatically introspect the service bean and
find
> > the
> > > endpoint interface via the @WebService.endpointInterface
annotation,
> > so
> > > that
> > > line is completely not needed.
> > >
> > > Cheers,
> > > - Dan
> > >
> > > On 7/13/07, Benson Margulies <[EMAIL PROTECTED]> wrote:
> > > >
> > > > This annotation is on the implementation class (named
> > > > NameIndexServiceImpl)
> > > >
> > > > @WebService(serviceName = "NameIndex", endpointInterface =
> > > > "com.basistech.rnm.index.ws.NameIndexService",
> > > > targetNamespace="urn:com.basistech.rnm.index.ws")
> > > >
> > > > This annotation is on the interface (named NameIndexService)
> > > >
> > > > @WebService(name="NameIndex",
> > > > targetNamespace="urn:com.basistech.rnm.index.ws")
> > > >
> > > > The startup looks like this:
> > > >
> > > > serviceFactory.setAddress("http://localhost:"; + port +
> > > > "/NameIndex");
> > > > serviceFactory.setServiceBean(new
> > > > NameIndexServiceImpl(configPath));
> > > > serviceFactory.setServiceClass(NameIndexService.class);
> > > >
> > > > And the wsdl comes out like this: ...
> > > >
> > > > > > > targetNamespace="urn:com.basistech.rnm.index.ws">
> > > >
> > > > How do I get rid of the extra 'service'?
> > > >
> > > >
> > >
> > >
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
Re: Using CXF
Hi Jacob, I would go with something like: org.apache.cxf cxf-rt-frontend-jaxws 2.0-incubator org.apache.cxf cxf-rt-transports-http 2.0-incubator org.apache.cxf cxf-rt-transports-http-jetty 2.0-incubator That will set you up to use the JAX-WS style annotated web services with JAXB. Spring is included by default. Let us know if you have more questions. I'll try to add this to the xfire user's guide. - Dan On 7/13/07, Jacob Marcus <[EMAIL PROTECTED]> wrote: I am an XFire user planning to evaluate CXF for my project. What is the maven dependency for CXF to be used? While using XFire, I had the following dependencies. org.codehaus.xfire xfire-jaxb2 1.2.5 org.codehaus.xfire xfire-spring 1.2.5 org.springframework spring org.codehaus.xfire xfire-java5 1.2.5 Do we have something similar for CXF? I use spring. -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: customizing the HTTP transport factory
Hi Benson,
You're very close to getting it to work :-) If you look at the
cxf-extension-http-jetty.xml file you'll see that we associate several
transport IDs with that transport:
http://schemas.xmlsoap.org/soap/http
http://schemas.xmlsoap.org/wsdl/http/
http://schemas.xmlsoap.org/wsdl/soap/http
http://www.w3.org/2003/05/soap/bindings/HTTP/
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/bindings/xformat
In code form, this is equivalent to:
Set tids = new HashSet();
tids.add("http://schemas.xmlsoap.org/soap/http";);
... etc for all transport ids
httpTransport.setTransportIds(tids);
for (String tid : tids) {
dfm.registerDestinationFactory(tid, httpTransport);
}
We should really write some docs on the transport layer, but hopefully this
will get you going in the meantime.
Thanks,
- Dan
On 7/13/07, Benson Margulies <[EMAIL PROTECTED]> wrote:
I set out to replace JettyHTTPTransportFactory with a slightly modified
version. So, I wrote the code below.
The effect is an NPE when my factory object is asked for its
transportIds, of which it has none. When I don't try to set this up, the
default transport factory does not get asked for its transport ids,
apparently because other things that aren't initialized protect it from
being asked.
I think I see what the transport Id has to be for SOAP, so I can just
set it, but is this idea supposed to work without that?
Bus bus = BusFactory.getDefaultBus();
DestinationFactoryManager dfm =
bus.getExtension(DestinationFactoryManager.class);
JettyHTTPTransportFactoryForStaticContent transportFactory = new
JettyHTTPTransportFactoryForStaticContent();
transportFactory.setBus(bus);
dfm.registerDestinationFactory("http://cxf.apache.org/transports/http/co
nfiguration", transportFactory);
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: customizing the HTTP transport factory
BTW, you may also be interested in this code that I wrote to serve out
static HTML files once upon a time:
private static void serveHTML() throws Exception {
Bus bus = BusFactory.getDefaultBus();
DestinationFactoryManager dfm = bus.getExtension(
DestinationFactoryManager.class);
DestinationFactory df = dfm.getDestinationFactory("
http://cxf.apache.org/transports/http/configuration";);
EndpointInfo ei = new EndpointInfo();
ei.setAddress("http://localhost:8080/test.html";);
Destination d = df.getDestination(ei);
d.setMessageObserver(new MessageObserver() {
public void onMessage(Message message) {
try {
// HTTP seems to need this right now...
ExchangeImpl ex = new ExchangeImpl();
ex.setInMessage(message);
Conduit backChannel = message.getDestination().
getBackChannel(message, null, null);
MessageImpl res = new MessageImpl();
res.put(Message.CONTENT_TYPE, "text/html");
backChannel.prepare(res);
OutputStream out = res.getContent(OutputStream.class);
FileInputStream is = new FileInputStream("test.html");
IOUtils.copy(is, out, 2048);
out.flush();
out.close();
is.close();
backChannel.close(res);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
Ugly, but it works ;)
- Dan
On 7/14/07, Dan Diephouse <[EMAIL PROTECTED]> wrote:
Hi Benson,
You're very close to getting it to work :-) If you look at the
cxf-extension-http-jetty.xml file you'll see that we associate several
transport IDs with that transport:
http://schemas.xmlsoap.org/soap/http
http://schemas.xmlsoap.org/wsdl/http/
http://schemas.xmlsoap.org/wsdl/soap/http
http://www.w3.org/2003/05/soap/bindings/HTTP/
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/bindings/xformat
In code form, this is equivalent to:
Set tids = new HashSet();
tids.add("http://schemas.xmlsoap.org/soap/http";);
... etc for all transport ids
httpTransport.setTransportIds(tids);
for (String tid : tids) {
dfm.registerDestinationFactory(tid, httpTransport);
}
We should really write some docs on the transport layer, but hopefully
this will get you going in the meantime.
Thanks,
- Dan
On 7/13/07, Benson Margulies <[EMAIL PROTECTED]> wrote:
>
> I set out to replace JettyHTTPTransportFactory with a slightly modified
> version. So, I wrote the code below.
>
> The effect is an NPE when my factory object is asked for its
> transportIds, of which it has none. When I don't try to set this up, the
>
> default transport factory does not get asked for its transport ids,
> apparently because other things that aren't initialized protect it from
> being asked.
>
> I think I see what the transport Id has to be for SOAP, so I can just
> set it, but is this idea supposed to work without that?
>
>
>
>Bus bus = BusFactory.getDefaultBus();
> DestinationFactoryManager dfm =
> bus.getExtension(DestinationFactoryManager.class);
> JettyHTTPTransportFactoryForStaticContent transportFactory = new
> JettyHTTPTransportFactoryForStaticContent();
> transportFactory.setBus(bus);
>
> dfm.registerDestinationFactory("http://cxf.apache.org/transports/http/co
> nfiguration", transportFactory);
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Trouble with creating RESTful Service deployed to Jetty - need help!
Because of the way unwrapped mode works, a method like this cannot be
mapped:
@Get
@HttpResource(location = "/clients/{id}")
public Client getClient( long id );
Unwrapped mode states that the thing in the brackets ({id}), must be mapped
to a property on the method parameter (i.e. the first parameter of
getClient). Which means you need to have a method like this:
@Get
@HttpResource(location = "/clients/{id}")
public Client getClient(GetClient client);
public class GetClient {
private long id;
... getter/setter
}
See the unwrapped vs wrapped mode section of the docs for more explanation:
http://cwiki.apache.org/confluence/display/CXF20DOC/HTTP+Binding
Hope that helps,
- Dan
On 7/13/07, Jason Mihalick <[EMAIL PROTECTED]> wrote:
I just tried the 2.1-incubator-SNAPSHOT and I got this instead of the NPE:
"You can not map a URI parameter to a simple type when in unwrapped mode!"
The URL I was trying to hit was:
http://localhost:8080/iat-services/client-service/clients
which works fine in wrapped mode.
Which brings me to a new question...
When I run in wrapped mode, I get the wrapper XML markup as your
documentation states. I.e.,
http://iat.jcol.com";>
http://iat.jcol.com";>
Is there anyway at all to control this and eliminate the outer wrapping
markup? I'd much prefer to just see:
http://iat.jcol.com";>
When I run in wrapped mode, for some reason GETs on this URL:
http://localhost:8080/iat-services/client-service/clients/1
end up invoking my getClients() method instead of my getClient(long id)
method. It seems to ignore the @HttpResource annotation, which looks like
this on my getClient(long) method:
@Get
@HttpResource(location = "/clients/{id}")
public Client getClient( long id );
Thanks again,
Jason
>From: "Dan Diephouse" <[EMAIL PROTECTED]>
>Reply-To: cxf-user@incubator.apache.org
>To: cxf-user@incubator.apache.org
>Subject: Re: Trouble with creating RESTful Service deployed to Jetty -
need
>help!
>Date: Fri, 13 Jul 2007 10:24:06 -0600
>
>Bizarre... If you had a moment, I improved that line of code post 2.0 and
>included some better error reporting. Any chance you'd be willing to try
>out
>a snapshot quick and let us know if it works correctly?
>http://incubator.apache.org/cxf/download.html
>
>Otherwise I'll take a stab at figuring out whats going on soon.
>Thanks,
>-Dan
>
>On 7/12/07, Jason Mihalick <[EMAIL PROTECTED]> wrote:
>>
>>LOL, know just what you mean. ;-)
>>
>>Actually, while I was tinkering with it here I figured that out too. I
>>realized that my URL should have had clients (plural) in it instead of
>>client (singular). After I corrected that, I started getting a
>>NullPointerException:
>>
>>INFO: URIParameterInterceptor handle message on path [/clients] with
>>content-type [null]
>>Jul 12, 2007 3:35:06 PM org.apache.cxf.phase.PhaseInterceptorChain
>>doIntercept
>>INFO: Interceptor has thrown exception, unwinding now
>>java.lang.NullPointerException
>> at
>>org.apache.cxf.binding.http.IriDecoderHelper.buildDocument(
>>IriDecoderHelper.java:213)
>> at
>>
>>
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.mergeParams
>>(URIParameterInInterceptor.java:129)
>> at
>>
>>
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.handleMessage
>>(URIParameterInInterceptor.java:105)
>>
>>
>>But wait ... there's more. I decided to drop kick my service for the
>>moment
>>and pull in your CustomerService example from
>>apache-cxf-2.0-incubator/samples/restful_http_binding. After I got all
of
>>the configuration set up for that sample service, doing a get against
this
>>URL worked:
>>
>>http://localhost:8080/iat-services/ws/customer/customers
>>
>>Hmmm. Something screwy here. So, I started comparing my webservice to
>>yours piece by piece and my NullPointerException went away when I added
a
>>targetNamespace to my @WebService tag in my ClientService interface:
>>
>>@WebService(targetNamespace = "http://iat.jcol.com";)
>>
>>Adding that made the NPE go away, and now it's working! Does this make
>>any
>>sense? Why would that fix it, I wonder, h. I've checked it a
couple
>>of
>>times and adding/removing that namespace causes the NPE to
>>disappear/reappear.
>>
>>Hope this helps in your understanding. Let me know if there is any
other
>>info I can provide to you. Appreciate the help.
>>--
>>Jason
>>
>>
>> >From: "Dan Diephouse" <[EMAIL PROTECTED]>
>> >Reply-To: cxf-user@incubator.apache.org
>> >To: cxf-user@incubator.apache.org
>> >Subject: Re: Trouble with creating RESTful Service deployed to Jetty -
>>need
>> >help!
>> >Date: Thu, 12 Jul 2007 13:32:48 -0600
>> >
>> >Wow, I think I'm losing it - I forgot how my code works. It turns out
>>(as
>> >the logs suggest) that the correct URL is:
>> >
>> >http://localhost:8080/iat-services/ws/clients/10<
>>http://localhost:8080/iat-services/ws/client/10>
>> >
>> >(clientS not client)
>> >
>> >Cheers,
>> >- Dan
>> >
>>
Re: Trouble with creating RESTful Service deployed to Jetty - need help!
Hi Dan. I appreciate the clarification on unwrapped mode. Can you also
answer my question below about running in wrapped mode?
Thanks again,
Jason
From: "Dan Diephouse" <[EMAIL PROTECTED]>
Reply-To: cxf-user@incubator.apache.org
To: cxf-user@incubator.apache.org
Subject: Re: Trouble with creating RESTful Service deployed to Jetty - need
help!
Date: Sat, 14 Jul 2007 13:05:46 -0500
Because of the way unwrapped mode works, a method like this cannot be
mapped:
@Get
@HttpResource(location = "/clients/{id}")
public Client getClient( long id );
Unwrapped mode states that the thing in the brackets ({id}), must be mapped
to a property on the method parameter (i.e. the first parameter of
getClient). Which means you need to have a method like this:
@Get
@HttpResource(location = "/clients/{id}")
public Client getClient(GetClient client);
public class GetClient {
private long id;
... getter/setter
}
See the unwrapped vs wrapped mode section of the docs for more explanation:
http://cwiki.apache.org/confluence/display/CXF20DOC/HTTP+Binding
Hope that helps,
- Dan
On 7/13/07, Jason Mihalick <[EMAIL PROTECTED]> wrote:
I just tried the 2.1-incubator-SNAPSHOT and I got this instead of the NPE:
"You can not map a URI parameter to a simple type when in unwrapped mode!"
The URL I was trying to hit was:
http://localhost:8080/iat-services/client-service/clients
which works fine in wrapped mode.
Which brings me to a new question...
When I run in wrapped mode, I get the wrapper XML markup as your
documentation states. I.e.,
http://iat.jcol.com";>
http://iat.jcol.com";>
Is there anyway at all to control this and eliminate the outer wrapping
markup? I'd much prefer to just see:
http://iat.jcol.com";>
When I run in wrapped mode, for some reason GETs on this URL:
http://localhost:8080/iat-services/client-service/clients/1
end up invoking my getClients() method instead of my getClient(long id)
method. It seems to ignore the @HttpResource annotation, which looks like
this on my getClient(long) method:
@Get
@HttpResource(location = "/clients/{id}")
public Client getClient( long id );
Thanks again,
Jason
>From: "Dan Diephouse" <[EMAIL PROTECTED]>
>Reply-To: cxf-user@incubator.apache.org
>To: cxf-user@incubator.apache.org
>Subject: Re: Trouble with creating RESTful Service deployed to Jetty -
need
>help!
>Date: Fri, 13 Jul 2007 10:24:06 -0600
>
>Bizarre... If you had a moment, I improved that line of code post 2.0
and
>included some better error reporting. Any chance you'd be willing to try
>out
>a snapshot quick and let us know if it works correctly?
>http://incubator.apache.org/cxf/download.html
>
>Otherwise I'll take a stab at figuring out whats going on soon.
>Thanks,
>-Dan
>
>On 7/12/07, Jason Mihalick <[EMAIL PROTECTED]> wrote:
>>
>>LOL, know just what you mean. ;-)
>>
>>Actually, while I was tinkering with it here I figured that out too. I
>>realized that my URL should have had clients (plural) in it instead of
>>client (singular). After I corrected that, I started getting a
>>NullPointerException:
>>
>>INFO: URIParameterInterceptor handle message on path [/clients] with
>>content-type [null]
>>Jul 12, 2007 3:35:06 PM org.apache.cxf.phase.PhaseInterceptorChain
>>doIntercept
>>INFO: Interceptor has thrown exception, unwinding now
>>java.lang.NullPointerException
>> at
>>org.apache.cxf.binding.http.IriDecoderHelper.buildDocument(
>>IriDecoderHelper.java:213)
>> at
>>
>>
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.mergeParams
>>(URIParameterInInterceptor.java:129)
>> at
>>
>>
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.handleMessage
>>(URIParameterInInterceptor.java:105)
>>
>>
>>But wait ... there's more. I decided to drop kick my service for the
>>moment
>>and pull in your CustomerService example from
>>apache-cxf-2.0-incubator/samples/restful_http_binding. After I got all
of
>>the configuration set up for that sample service, doing a get against
this
>>URL worked:
>>
>>http://localhost:8080/iat-services/ws/customer/customers
>>
>>Hmmm. Something screwy here. So, I started comparing my webservice to
>>yours piece by piece and my NullPointerException went away when I added
a
>>targetNamespace to my @WebService tag in my ClientService interface:
>>
>>@WebService(targetNamespace = "http://iat.jcol.com";)
>>
>>Adding that made the NPE go away, and now it's working! Does this make
>>any
>>sense? Why would that fix it, I wonder, h. I've checked it a
couple
>>of
>>times and adding/removing that namespace causes the NPE to
>>disappear/reappear.
>>
>>Hope this helps in your understanding. Let me know if there is any
other
>>info I can provide to you. Appreciate the help.
>>--
>>Jason
>>
>>
>> >From: "Dan Diephouse" <[EMAIL PROTECTED]>
>> >Reply-To: cxf-user@incubator.apache.org
>> >To: cxf-user@incubator.apache.org
>> >Subject: Re: Trouble with creating RESTful
RE: customizing the HTTP transport factory
Dan, The most interesting thing that dawned on me is that a JettyHTTPHandler \is a/ Jetty \Handler/. Thus, I can instantiate Jetty's standard static content handler and call it from a subclass of JettyHTTPHandler, since the same arguments that come into JettyHTTPHandler can be delegated to the handlers in Jetty and thus avoid the need for what you sent. To use what you sent, I'd need to fill in the suffix-to-mime-type department. Not the end of the world, and borrowable from Jetty, but still clumsy compared to just using Jetty's stuff. I appreciate your coaching on the transport factory. You presumably saw the JIRA I created when I tried to reduce the number of extra classes I had to create by registering my own subclass of the server engine factory as the bus extension instead of using my own transport factory to return my own server engine factory to return my own server engine. Ironically, I want to get rid of the program I have that uses the embedded server and replace it with a spring deployment inside a WAR inside Jetty. However, it was going to be easier on various people if I got it working, instead. I have this feeling that I don't have an adequate design understanding of the relationship between the bus, the spring wiring, and the hardcoded defaults, so please excuse anything goofy I send. --benson
