Ok, I am now sure that I use wrapped/doc/lit on both sides, I have
removed the @SOAPBinding on the Java side and the mentioned
RegisterInvokeOptions call instructs Delphi to use document-literal
style and the types for input and output values have not been unwound to
create a method call (from
Yes, they are incompatible, but we're definitely getting
someplace... :-)
SOAP-ENV:Body
ExecuteJob xmlns=http://annuaire.ciss.lu;
JobNameTestFromDelphi/JobName
compared to:
soap:Body
ns1:ExecuteJob xmlns:ns1=http://annuaire.ciss.lu;
Hello Benson,
yes, I did do the changes but still gave me the same problem
(org.apache.cxf.interceptor.Fault: Message part {http://pojo.spring.demo/}sayHi
http://pojo.spring.demo/%7DsayHi was not recognized.)
so I than made the following alterations;
On the server side;
1- in my service
Thank you so much Dan, solution 2) works like a charm ... except that
the string array (second parameter) is still not correctly received.
Just to be sure that I understand the problem, Delphi uses imbricated
string nodes to describe the elements of the array, but Java uses
multiple
G'day all,
I am using WSS4J 1.5.1. I created X509 public keys and certificates from
Sun Microsystems Keytool utility. AFAIK, it created X509v1 certificates.
Please let me know if it creates v3 certificates, which in my opinion
doesn't do.
Looking at the on the wire message sent from client to
Hi,
I'm having a problem trying to build a client for my service with cxf.
My service is up and running, but whenever I try and access it from a
client I'm getting null pointer exceptions. The code to setup my client
looks like this:
// SNIP
JaxWsProxyFactoryBean proxyFactory = new
Unless x.509v3 Certificates are present in your created certificate
there
is no requirement that the certificate version number is 3.
If either the X.509 issuerUniqueID or subjectUniqueID fields are present
the certificate must be at least version 2.
However there is nothing actually stopping
Benson,
Thanks for the tips. I have enabled AegisServiceConfiguration on the
server side, yes, and I admit I was wondered if this was causing the
problem. I had found these docs before and I'd used them to set up
things on the server side (although it's possible I'm doing this wrong),
and
Arundel, Donal wrote:
Unless x.509v3 Certificates are present in your created certificate
there
is no requirement that the certificate version number is 3.
If either the X.509 issuerUniqueID or subjectUniqueID fields are present
the certificate must be at least version 2.
However there is
On Tuesday 26 February 2008, pierre post wrote:
Thank you so much Dan, solution 2) works like a charm ... except that
the string array (second parameter) is still not correctly received.
Just to be sure that I understand the problem, Delphi uses imbricated
string nodes to describe the elements
Sure, assuming you mean from the command line then download the
excellent openssl utility from www.openssl.org.
Then execute:
openssl x509 -in MyCertfile.pem -inform PEM -text
This will give a nice printout of the cert details, including a listing
of the x.509v3 extensions rpesent.
The above
Get rid of the service configuration on the server, or add it to the client.
It changes the rules for mapping packages to and from namespaces. I rewrote
the doc over the last few days to deconfuse this.
On Tue, Feb 26, 2008 at 9:03 AM, Tony Burdett [EMAIL PROTECTED] wrote:
Benson,
Thanks for
It's probably due to the AegisServiceConfiguration stuff that was there
in the docs previously. The tell-tale sign of that is the / on the
end of the mapped namespaces.
Example:
{http://pojo.spring.demo/}sayHi
The default mapping for JAXWS would be:
{http://pojo.spring.demo}sayHi
without
Lists should be completely usable with JAX-WS/JAXB (and Aegis as well) as
long as you properly type the exact instance. Example:
class MyBean {
ListFoo myList;
}
and don't try things like:
class MyBeanT {
ListT myList;
}
of
class MyBean{
List myList;
}
The last one CAN be made
On Monday 25 February 2008, Phil Weighill-Smith wrote:
Dan,
The exception happened with just using command line access - with long
class paths ;n)
Yes, I think we were getting the tooling from a 2.0.1 JAR remnant. But
I couldn't find the tooling in the 2.1 snap...?
Which tooling? The
That's the sort of answer I was looking for. Thanks,
Phil :n)
PS: Was this an RTFM moment?!
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: Tue, 26 Feb 2008 11:25:16 -0700 (MST)
Subject: Re:
On Tuesday 26 February 2008, Phil Weighill-Smith wrote:
That's the sort of answer I was looking for. Thanks,
Phil :n)
PS: Was this an RTFM moment?!
I wish I could say the answer was yes... :-(
I think most of our docs on the wiki at this point are more targetted
toward the 2.0.x toolset
I just started to use CXF with Spring. There're 23 jars required for the
integration of Spring and CXF on the document (
http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html )
Are those all required on client side? Are there any only required for Server
side? Thanks.
On Tuesday 26 February 2008, Li, Weiye wrote:
I just started to use CXF with Spring. There're 23 jars required for
the integration of Spring and CXF on the document (
http://cwiki.apache.org/CXF20DOC/writing-a-service-with-spring.html )
Are those all required on client side? Are there any
In my web service, there is a method which takes an interface as its
parameter, instead of a concrete class. Reference code is at the bottom of
this email.
When I run the client, I get an exception Caused by:
javax.xml.bind.JAXBException: com.passenger.test.ComplexObjectInterface is
not known
I was using WSDLToJava but now I am trying to use JavaToWSDL.
I have a bunch of web-services with the same signature
and they all inherit from a common abstract impl class,
so it seems best to generate the WSDL.
I am trying to deploy on JBoss 4.2.2 / JDK 1.5.0 / CXF 2.0.4
Using the generated
OK, I solved this original problem but I have more questions:
How do you control the soap location.
Right now it is outputing
soap:address location=http://localhost:9090/hello/
which is not correct.
Also, can I override this programmatically in the client?
Thanks,
Dan
p.s. I solved it
I think the answer is no, neither CXF nor GlassFish Metro support
interfaces as parameters. It's either a JAX-WS or JAXB rule, I'm not
certain.
Glen
Am Dienstag, den 26.02.2008, 15:07 -0800 schrieb Ayush Gupta:
In my web service, there is a method which takes an interface as its
parameter,
Phil, I updated the docs for both java2wsdl and java2ws, so others won't
have the same confusion. Sorry this happened to you.
Glen
Am Dienstag, den 26.02.2008, 13:42 -0500 schrieb Daniel Kulp:
On Tuesday 26 February 2008, Phil Weighill-Smith wrote:
That's the sort of answer I was looking
Kohsuke Kawaguchi's blog talked about this , you can get some information
from
this link:
http://weblogs.java.net/blog/kohsuke/archive/2006/06/jaxb_and_interf.html
On Wed, Feb 27, 2008 at 9:25 AM, Glen Mazza [EMAIL PROTECTED] wrote:
I think the answer is no, neither CXF nor GlassFish Metro
Arundel, Donal wrote:
Sure, assuming you mean from the command line then download the
excellent openssl utility from www.openssl.org.
Then execute:
openssl x509 -in MyCertfile.pem -inform PEM -text
This will give a nice printout of the cert details, including a listing
of the x.509v3
Looking at the code (this seems to be some code that came from XFire),
there is some ScopePolicy things that seem to do various things, but
they seem to be very confusing and also won't work with the
JAXWSMethodInvoker anyway due to that singleton factory thing.
There's PROBABLY a
27 matches
Mail list logo
