I had exactly the same problem with cxf and swf. And here is the solution you
need:
?xml version=1.0 encoding=UTF-8?
jaxws:bindings wsdlLocation=YOUR_WSDL_LOCATION
xmlns:jaxws=http://java.sun.com/xml/ns/jaxws;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
As Benson mentioned, take a look at the JaxWsServerFactoryBean. When
you are using spring to configure things with jaxws:server, that is the
object that Spring is manipulating. Thus, anything you can configure
there should have appropriate options on the bean.
The other option is to
Thanks Akos, I will try this a later time. For this project we will keep
using metro RI, we don't have time to change that as we are close to the end
of the project.
1 quick question though: the wsdlLocation=YOUR_WSDL_LOCATION should point
to the final destination of your wsdls or is it used
Daniel,
The binding file is ONLY used at code generation time as an option passed
to wsdl2java. It's not used at runtime at all. Thus, it should point
to whatever the development time location would be.
Dan
On Thursday 24 January 2008, daniel.mfreitas wrote:
Thanks Akos, I will try
Hi,
The WSDL pasted at the end of this email contains two methods:
getApprovedTerms, verifyTerm. There signatures are very close, yet,
verifyItem is wrappable and getApprovedTerms isn't...Can somebody please
explain me why?
I am working with CXF 2.0.1 patched. I did update TypeClassSerializer
I need to expose a service (java-first) with CXF with an exception
(EchoComplexException
) that includes an array of object (of class EchoStruct).
The service is setted with: anonymousWrapperType, qualifyWrapperSchema
ad wrapped to true.
The wsdl generated seems to be correct, with a
Fyi, it fails to find the class for
{http://sii.gri.roche.com}:verifyTerm although it was generated. I
believe the bug here is that the operation is not Wrappable but can
somebody confirm?
Thanks
-Original Message-
From: Benjamin Coiffe [mailto:[EMAIL PROTECTED]
Sent: 24 January 2008
Any chance you could check with the 2.0.4 release candidates available
at:
http://people.apache.org/~dkulp/stage_cxf/2.0.4-incubator/
There were definite issues with Exceptions not working correctly with
qualified schemas in 2.0.3. They should (hopefully) be fixed there.
Dan
On Thursday
Thank you Dan for your quick answer.
I already tried with CXF-2.0.4 (RC) but the behaviour seems to be the
same as the 2.0.3
version.
Marco.
Quoting Daniel Kulp [EMAIL PROTECTED]:
Any chance you could check with the 2.0.4 release candidates available
at:
Hello All,
As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing because
the below class could not be found.
I'm using Maven for builds and tests, and am *not* bringing in every
possible CXF dependency as defined here[1].
java.lang.NoClassDefFoundError:
Oops, forgot to mention, this is the exception that caused the class missing
error:
org.springframework.beans.BeanInstantiationException: Could not instantiate
bean class [org.apache.cxf.jaxws.EndpointImpl]: Constructor threw exception;
nested exception is java.lang.NoClassDefFoundError:
Looks to me as if you have a too-old XmlSchema jar file.
On Thu, 2008-01-24 at 08:44 -0800, Glen Mazza wrote:
Hello All,
As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing because
the below class could not be found.
I'm using Maven for builds and tests, and am *not*
You need to update the version of XmlSchema.The version we used in
2.0.2 had too many bugs that we couldn't work around. In 2.0.3, it was
updated to 1.3.2, which STILL has a bunch of bugs we cannot work
around, :-( but it does fix a few others and does provide us an
oportunity to work
It's the JAX-WS spec (which our tools implement) found at:
http://jcp.org/en/jsr/detail?id=224
Specifically, it's section 2.3.1.2. The first table in there, item 5
says:
(v) The wrapper elements only contain child elements, they must not
contain other structures such as wildcards (element
Glen,
Depends. Mavens transitive dependency mechanisms is one of the worlds
depest mysteries (and changes from version to version :-( )
Seriously, if you have two dependencies that depend on different versions
of XmlSchema transitively, what version you get is completely dependent
Ben,
This won't do what you think. The DEFAULT is to enable wrapper style.
The customization you are referring two will allow all operations to be
generated in the bare style. In your case, the verifyTerm would be
changed to match the other item:
VerifyTermResponse
Does not sound to bad...I guess the customization
jaxws:enableWrapperStyle would be in an XML file somewhere in the cxf
JAR.
My final purpose here is to get this soap message:
(Generated in SOAP UI)
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
Hi,
I would like to know if any of you had a successful integration between
these technologies.
Basically, calling CXF Web Services from an EBA platform and calling EBA
web Services from CXF?
Any answer (link to a blog, anything) appreciated,
Thanks
Benjamin Coiffe
I just had a chance to look a little closer at this. It appears that
when we use the CXF servlet transport the mime types for the Accept:
Content-Type: headers are not being propagated into the jax-rs
runtime. I'm currently investigating why this is the case.
BTW I was mistaken on the
I reread my own posting and realized that the problem is not in the
detail element, but in the faultcode element which contains an
arbitrary string, ServerFaultCode, not a QName. The exception says:
No NamespaceURI, SOAP requires faultcode content to be a QName
I believe the faultcode
I'm using CXF 2.0.3-incubator with Maven 2.
I get this exception when I try to use java mail from within my web service
(running on Tomcat 5.5.16) :-
javax.mail.NoSuchProviderException: Provider class does not have a
constructor(Session, URLName): protocol=smtp; type=
[EMAIL PROTECTED];
hi,
in http://cwiki.apache.org/CXF20DOC/aegis-databinding.html it is
suggested to use
org.apache.cxf.aegis.databinding.AegisDatabinding as factory bean for
endpoints.
The described syntax implies the use of a single factory bean for
multiple endpoints, whereas this does not work.
Is this a known
sorry, the factory class is ofcause not
org.apache.cxf.aegis.databinding.AegisDatabinding
but
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
Cheers,
Ron
Ron Piterman wrote:
hi,
in http://cwiki.apache.org/CXF20DOC/aegis-databinding.html it is
suggested to use
Benson Margulies wrote:
On Thu, 2008-01-24 at 13:05 -0500, Frederick N. Brier wrote:
I reread my own posting and realized that the problem is not in the
detail element, but in the faultcode element which contains an
arbitrary string, ServerFaultCode, not a QName. The exception says:
No
Cheers Daniel,
But I read that CXF-927 on your jira. And I am thinking that if I do
that in the wsdl:
operation name=verifyTerm parameterOrder=parameters
jaxws:bindings xmlns:jaxws=http://java.sun.com/xml/ns/jaxws;
jaxws:enableWrapperStylefalse/jaxws:enableWrapperStyle
/jaxws:bindings
On Thursday 24 January 2008, Benson Margulies wrote:
On Thu, 2008-01-24 at 13:54 -0500, Daniel Kulp wrote:
Yea, that definitely won't work. The service factories record way
to much state specific to that endpoint.
That said, you MAY be able to get it to work by doing:
bean
Benjamin,
That would work for wsdl2java generated clients, but not for the
DynamicClient. The DynamicClient thing you are using doesn't do any
JAX-WS extensor processing or anything like that. No matter what you
do, verifyTerm will be unwrapped, the other bare.
Now, that all said, there
I've create a JIRA for this issue at:
https://issues.apache.org/jira/browse/CXF-1405
I've also attached a patch to the JIRA which should resolve this for
you.
best regards,
--Frank
On Thu, 2008-01-24 at 12:58 -0500, Frank Lynch wrote:
I just had a chance to look a little closer at this. It
Hi there,
I was playing around with some JAXWS services in CXF, and am wondering
under what circumstances does a service actually go and read the WSDL
file. In the SOAP/HTTP case it doesn't have to read from the WSDL file -
all the information should be implicit from the annotations in the WSDL
The latter. If there is a wsdlLocation attribute, we always grab the
wsdl. Additionaly, if the config (like spring config) specifies a wsdl
location, we use it.
Dan
On Thursday 24 January 2008, Trenaman, Adrian wrote:
Hi there,
I was playing around with some JAXWS services in CXF,
Dears:
I put some code into a web method to get client IP.
ex:
public boolean recordIP() {
try {
debugInfo.append( ).append(
((HttpServletRequest) ctx
.get(AbstractHTTPDestination.HTTP_REQUEST))
.getRemoteAddr());
31 matches
Mail list logo
