Nah-- I'm using it with SOAP 1.1 on my CXF service. Didn't have to do
anything special (other than normal config stuff). It mainly just
worked.
I've also got .NET clients and Metro clients using MTOM with my SOAP 1.1
service.
-Chris
-Original Message-
From: Benson Margulies
)
Dan
On Thursday 15 November 2007, Christopher Moesel wrote:
Hello,
I am using CXF with my JAX-WS WSDL-first web service. My schema
specifies a mandatory custom credentials element in the SOAP
header
Nope-- the default value for both minOccurs and maxOccurs is 1. So, if
you have neither, it means it expects exactly 1 element.
-Chris
-Original Message-
From: Benson Margulies [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 6:15 PM
To: Daniel Kulp;
It seems to me that maxOccurs should definitely be 1 in this case.
Perhaps that is why VS2005 is choking-- multidimensional arrays?
I have a wsdl-first service using CXF w/JAXB and I haven't had any
problems with a VS2005 client. My WSDL does have some elements with
maxOccurs=unbounded. But I
Hi Matt,
Maybe I'm misunderstanding your question, but I think you just want to
be able to use CXF and Spring MVC in the same application? If that's
it, I've done this simply by mapping the CXFServlet and
DispatcherServlet to two different URL patterns. For example:
?xml version=1.0
Hi Sergey,
The following combination *should* work...
In web.xml, the url-pattern for the servlet-mapping:
/hello/*
In the jaxws:endpoint/@address:
/world
I believe that the difference between implementor and implementorClass
is this:
implementor: a reference to an *instance* of your SEI
Hi Matt,
If you're using the default data binding (JAXB 2.0), then you may want
to check out JAXB's documentation on annotating classes.
For starter's, you can see Kohsuke's blog entry on using JAXB:
http://weblogs.java.net/blog/kohsuke/archive/2005/02/using_jaxb_20_t.htm
l
Then for all the
will be
appreciated.
Thanks
Matt
Christopher Moesel wrote:
Hi Matt,
If you're using the default data binding (JAXB 2.0), then you may want
to check out JAXB's documentation on annotating classes.
For starter's, you can see Kohsuke's blog entry on using JAXB:
http://weblogs.java.net/blog
Hi Rich,
I have not tried Tomcat 6, but I have successfully packaged all the CXF
jars in the WEB-INF/lib of my war in Tomcat 5.5. My shared/lib is
empty. I would suspect that you could do this with Tomcat 6.
So-- it's possible. I don't know if it's the recommended approach, but
it's an
Hi Doug,
Unfortunately, the documentation is wrong in two respects:
(1) It doesn't appear that the jaxws:endpoint element supports a nested
portName element. So... for now... you won't be able to specify
portName there.
(2) Although it *does* support serviceName, the format for specifying
the
Yep-- Metro does have Spring support-- but it is an add-on feature. I
think the original point was that Spring is treated as a first-class
citizen in CXF. Since CXF was designed with Spring in mind, you'll find
that its Spring integration tends to feel a lot more natural (and
complete) than
Hi Jason,
Looking through the code for the java2wsdl goal, it doesn't appear that
there is any way for passing in extra arguments. If this is something
you'd like to see in CXF, I'd suggest submitting an issue to JIRA. It
shouldn't be too hard to add.
http://issues.apache.org/jira/browse/CXF
Hi Dan,
The txAdvice is looking for a transaction manager. Since the spring.xml
doesn't give the txAdvice a reference to a transaction manager, it
defaults to looking for a bean with id transactionManager-- which your
spring.xml does not have.
Spring can allow your transactions to be managed
Hi Jeremy,
I think that
serviceBean=transDataService
should actually be:
implementor=#transDataService
-Chris
-Original Message-
From: Jeremy Isikoff [mailto:[EMAIL PROTECTED]
Sent: Friday, August 03, 2007 11:17 PM
To: cxf-user@incubator.apache.org
Subject: Getting jaxws:server
To: cxf-user@incubator.apache.org
Subject: Re: Getting jaxws:server syntax working for spring
transaction proxying
Yeah thats what dan said originally unfortunately there is no
implementor in the schema document for jaxws:server.
- Original Message
From: Christopher Moesel [EMAIL PROTECTED
You should be able to drop all those same jars into the WEB-INF/lib of
your web application-- then you wouldn't need to copy them into the
Jboss server lib.
-Chris
-Original Message-
From: Erlend Leganger [mailto:[EMAIL PROTECTED]
Sent: Friday, August 03, 2007 8:32 AM
To:
to be done in the circumstances.
-Original Message-
From: Christopher Moesel [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 02, 2007 8:34 AM
To: cxf-user@incubator.apache.org
Subject: RE: Should schema location URLs be valid?
Whoops. Add the word release to my last statement below
Whoops. Add the word release to my last statement below. ;)
-Original Message-
From: Christopher Moesel [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 02, 2007 8:30 AM
To: cxf-user@incubator.apache.org
Subject: RE: Should schema location URLs be valid?
It should also be noted
It should also be noted that once CXF graduates from the incubator, this
will become a valid URL. This was seen as a better option than having
an incubator URL now and having to change it in a later.
-Chris
-Original Message-
From: Willem Jiang [mailto:[EMAIL PROTECTED]
Sent:
Hello All,
I have two CXF endpoints that implement the same interface. One
endpoint is a live endpoint and the other is a mock endpoint that
returns dummy data. They are configured to use different endpoint
addresses, and CXF serves them up at these different addresses, but...
the WSDL for my
or the documentation or am I reading things wrong? The default
documented above seems more reasonable to me than what's being generated
today.
Thanks again,
Corey
Christopher Moesel wrote:
Hi Corey,
If you are doing a JAX-WS Java-first service, you can use the
@WebParam
annotation to specify web parameter
Hi Corey,
If you are doing a JAX-WS Java-first service, you can use the @WebParam
annotation to specify web parameter names. It's in the documentation
guide here:
http://cwiki.apache.org/CXF20DOC/developing-a-service.html#DevelopingaSe
[EMAIL PROTECTED]
(tiny url: http://tinyurl.com/yr2q2w)
The jaxws.xsd file is packaged in the
cxf-rt-frontend-jaxws-2.0-incubator.jar as well as the uber
cxf-2.0-incubator.jar. In both cases, you can find it under /schemas.
-Chris
-Original Message-
From: gdprao [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 11:35 AM
To:
Hi Jacob,
I'm not sure how to do this without annotations. With annotations, you
would do this the JAX-WS approved way, by adding this to your service
implementation class:
@Resource private WebServiceContext context;
Then you could use the WebServiceContext object to get the message
Hi Samuel,
Have you looked at the MTOM documentation in the user guide?
http://cwiki.apache.org/CXF20DOC/mtom.html
If so, then what information is missing (or incorrect) that you need?
-Chris
-Original Message-
From: Clough, Samuel (USPC.PRG.Atlanta)
[mailto:[EMAIL PROTECTED]
Sent:
me
post new messages some how won't let me reply to existing message.
Thank you Daniel Kulp and Christopher Moesel for your responses. We are
really homing on to CXF as our choice to expose Spring beans as web
services
using JAX-WS. I do have some questions on the next version of CXF.
When
Hi Jorge,
You should be able to configure at least some of these using the
jaxws:endpoint Spring configuration. See these docs for details:
http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html
I think you're required to use annotations for the targetNamespace and
enpointInterface
I've been experimenting with Java-first services (for a friend ;) and
have run into some issues. I am using the latest version off svn HEAD
(the RC has its own set of issues w/ Java-first services). I can break
it in several different and interesting ways.
(1) It appears that I cannot have a
But is the idea here that a client would fetch this WSDL document from
some remote server, or that it will have a WSDL document bundled up,
say, in its JAR?
I ask because fetching the WSDL from a remote server would add one
network round-trip to every client's start-up sequence.
If this is
I ran into this very same issue when trying to run the war using the
maven jetty plugin. It also searched from the working directory instead
of the root of the application context. It worked however, when I tried
it in Tomcat 5.5 and Jboss 4.0 standalone.
In order to get it working in the maven
Hi Steven,
I'm using jaxws:endpoint with the CXFServlet. I got it working by
specifying the address relative to the servlet mapping URL pattern (and
using a leading /). So, in your example, I'd try
address=/my-service.
-Chris
-Original Message-
From: Steven E. Harris [mailto:[EMAIL
+1 on Steve's comment. Does a client need to have access to the actual WSDL at
run-time?
And on a related note, is there a way for a client to specify a different
endpoint URI at runtime? The current API allows you to pass in a URL to a WSDL
file, but what if I just want to use the WSDL I
the service.
The detail code you can find in CXFServlet.java in cxf-rt-transport-http
module.
Cheers,
Willem.
Christopher Moesel wrote:
Hello,
The User Guide has a page on the standalone transport:
http://cwiki.apache.org/CXF20DOC/standalone-http-transport.html
But this page only
Nevermind-- it looks like the problem is caused because I'm trying to
run it from inside my IDE-- which is using the same java process and
already had jetty loaded.
Running it outside of the IDE fixed the problem.
-Chris
-Original Message-
From: Christopher Moesel [mailto:[EMAIL
Hello All,
I would like my CXF service to be able to run standalone or within a web
container, depending on the environment... I am using Spring to do my
configuring. My problem is this:
In the jaxws:endpoint config tag, the address attribute means
different things depending on how the service
Hello,
The User Guide has a page on the standalone transport:
http://cwiki.apache.org/CXF20DOC/standalone-http-transport.html
But this page only demonstrates how to setup an SSL server. Is there
any documentation on setting up a normal HTTP listener? I'd like to
configure the port it runs on,
look into it at some point. I created a JIRA for this:
https://issues.apache.org/jira/browse/CXF-597
- Dan
On 4/24/07, Christopher Moesel [EMAIL PROTECTED] wrote:
I am now using the new WS-MTOMPolicy support (currently in SVN).
Lately I am noticing some strange behavior. Many of my responses
for the wsdl.
Can you try running mvn jetty:run-war and mvn jetty:run-exploded and
see if it's different?
I've honestly never used the embedded jetty stuff so I don't really know
what it's doing.
Dan
On Tuesday 24 April 2007 17:23, Christopher Moesel wrote:
It's a shot in the dark but...
My
?
I don't think round tripping would work though. wsdl2java, then
java2wsdl would probably put the header into a single message.
Dan
On Tuesday 24 April 2007 09:03, Christopher Moesel wrote:
Yes, this would require the code generator to look at the physical
portion of the WSDL
Hello List,
I've encountered an interoperability issue using an Axis2 client to
access an MTOM-enabled CXF service. The issue only occurs when the
service sends a streaming binary attachment to the client.
Here is the error I receive from my Axis 2 client:
java.lang.RuntimeException:
I am now using the new WS-MTOMPolicy support (currently in SVN).
Lately I am noticing some strange behavior. Many of my responses have
xmlns=http://www.w3.org/2005/08/addressing/wsdl; at the root element
under the body, even though the response does not use the WS-Addressing.
Example
Hi Dan K,
I just noticed that you fixed this. Thanks! Now I can separate my WSDL
from my XSDs again!
-Chris
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Monday, April 16, 2007 9:50 AM
To: cxf-user@incubator.apache.org
Cc: Christopher Moesel
Subject: Re
It's a shot in the dark but...
My wsdl-first CXF service specifies the WSDL location like so:
wsdlLocation=WEB-INF/myservice.wsdl
In my project (which uses Maven2), the wsdl file is indeed at:
C:/projects/mywebservice/src/main/webapp/WEB-INF/myservice.wsdl
If I do a mvn:install and hand-deploy
is set. The resulting
SOAP message is the same.
So, doc/literal yes, use it. My opinion is that
jax-ws trying to determine wrapped vs. bare based on a
bunch of rules is absurd. It's really a developer
preference. (I am talking wsdl first development
here).
--- Christopher Moesel [EMAIL
Interceptor
was then responsible for parsing the header and authentication.
I would like to find a better way to do this though. Maybe a flag to
disable
headers inside wsdl2java?
Cheers,
- Dan
On 4/23/07, Christopher Moesel [EMAIL PROTECTED] wrote:
To bring up a point from a couple of weeks ago
though. That should happen later today I would think.
- Dan
On 4/18/07, Christopher Moesel [EMAIL PROTECTED] wrote:
According to the link below, the .NET 2.0 w/ WSE 3.0 server supports a
feature like this:
quote from link
Note: There are three server MTOM modes: optional, always, and
never
quite
yet though. That should happen later today I would think.
- Dan
On 4/18/07, Christopher Moesel [EMAIL PROTECTED] wrote:
According to the link below, the .NET 2.0 w/ WSE 3.0 server supports
a
feature like this:
quote from link
Note: There are three server MTOM modes: optional, always
I am attempting to MTOM-enable my CXF service.
I am using the CXFServlet and Spring configuration.
I have added the following as a child of the jaxws:endpoint element in
the spring config file:
jaxws:properties
entry key=mtom_enabled value=true/
/jaxws:properties
Although my service seems to
this:
jaxws:properties
entry key=mtom-enabled
bean class=java.lang.Boolean
constructor-argvaluetrue/value/constructor-arg/bean
/entry
/jaxws:properties
I'll fix this in SVN as well! (BTW its a - not a _ in the
mtom-enabled
property)
- Dan
On 4/17/07, Christopher Moesel [EMAIL PROTECTED
Hello,
When I send a message to my CXF service using a .NET 2.0 client that is
using WSE 3.0 to enable MTOM capability, I get a server-side stack
trace. It appears it wrongly interprets the content type as: utf-8
(note the quotation mark).
I've pasted the stack trace as well as the contents of
Hello,
I would prefer to keep my schema types in a separate XSD file rather
than define them inside the WSDL file. So, I use an xsd:import to
accomplish this.
This appears to work well in CXF with one exception:
When I view the wsdl at
http://localhost:8080/myapp/services/MyService?wsdl the
Hello Again,
If I go to the root mapping of my CXF servlet (in my case,
http://localhost:8080/myapp/services/), it lists my deployed services.
The links however, are broken. Instead of:
http://localhost:8080/myapp/services/MyService?wsdl
it is:
though
Cheers, Sergey
- Original Message -
From: Christopher Moesel [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Monday, April 16, 2007 4:52 PM
Subject: Accessing Message Context, HttpServletRequest, and
HttpServletResponse
I needed access to the request object from within my
/
soap:body use=literal /
/input
output
soap:body use=literal /
/output
/operation
...
--- Christopher Moesel [EMAIL PROTECTED]
wrote:
So... if the header must be defined as a part in the
message, then it is
impossible to use SOAP headers in a CXF doc/literal
I have a custom authentication type that clients send me through the
SOAP header. In XFire, it generated the service interface with the
header message sent in as a parameter. CXF does not do that.
How can I get access to that data from within my service implementation?
Thanks,
Chris
I have a WSDL-first service and am attempting to run it, but having
problems with the spring config. My current spring config file
contains:
import resource=classpath:META-INF/cxf/cxf.xml /
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml /
import
56 matches
Mail list logo
