Re: bug in sec:include / exclude ?
Hi, finally I have had more time to examine the problem: Note, in both cases described bellow the cipher suite loged on client site contains only: SSL_RSA_WITH_NULL_SHA Please let me know if there is some way how to force both server and client to communicate with one specific cipher. First configuration: Server: sec:cipherSuitesFilter sec:include.*WITH_NULL_SHA.*/sec:include /sec:cipherSuitesFilter Client: sec:cipherSuitesFilter sec:includeSSL_RSA_WITH_NULL_SHA/sec:include /sec:cipherSuitesFilter when trying to connect client to server i got in server log: INFO: The cipher suites have been set to SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_DH_anon_WITH_RC4_128_MD5, TLS_DH_anon_WITH_AES_128_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. 2007-12-17 09:59:15.748::INFO: Started [EMAIL PROTECTED]:8090 Exception in thread btpool1-0 java.lang.OutOfMemoryError: Java heap space at com.sun.net.ssl.internal.ssl.InputRecord.init(InputRecord.java:65) at com.sun.net.ssl.internal.ssl.HandshakeInStream.init(HandshakeInStream.java:45) at com.sun.net.ssl.internal.ssl.Handshaker.setEnabledProtocols(Handshaker.java:294) at com.sun.net.ssl.internal.ssl.Handshaker.init(Handshaker.java:139) at com.sun.net.ssl.internal.ssl.Handshaker.init(Handshaker.java:110) at com.sun.net.ssl.internal.ssl.ServerHandshaker.init(ServerHandshaker.java:86) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.initHandshaker(SSLSocketImpl.java:980) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.getServerHandshaker(SSLSocketImpl.java:928) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:288) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253) at org.mortbay.jetty.security.SslSocketConnector.accept(SslSocketConnector.java:169) at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:514) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) Second: configuration: Client same as before Server: sec:cipherSuitesFilter sec:exclude.*WITH_NULL_SHA.*/sec:exclude /sec:cipherSuitesFilter I got the same exception and following CIPHER SUITE on server side: INFO: The cipher suites have been set to SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_RC4_128_MD5, TLS_DH_anon_WITH_AES_128_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. 2007-12-17 10:11:46.635::INFO: Started [EMAIL PROTECTED]:8090 Exception in thread btpool1-0 java.lang.OutOfMemoryError: Java heap space On Friday 14 of December 2007 14:13:54 Fred Dushin wrote: Interesting. I wonder if this is related to https://issues.apache.org/jira/browse/CXF-1222 Could I ask you to check your CPU utilization, while your server comes up? On Dec 14, 2007, at 1:48 AM, Bc. Jiří Mikulášek wrote: Hi all, I wonder this problem when testiong how to force the hanshake to one specific algorithm. The interesting thing is that on client site all works perfectly as expected
Securing server
Hi all, I would like to secure my server and started with first*https sample. Here is my configuration below, but I am still getting this error: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'httpj:engine-factory'. Have somebody any idea? I have also checked xsd in modules and it seems to be ok. thanks a lot beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd; xmlns:http-conf=http://cxf.apache.org/transports/http/configuration; xmlns:sec=http://cxf.apache.org/configuration/security; xmlns:httpj=http://cxf.apache.org/transports/http-jetty/configuration; httpj:engine-factory bus=cxf httpj:engine port=8090 httpj:tlsServerParameters sec:keyManagers keyPassword=[EMAIL PROTECTED] sec:keyStore type=JKS password=[EMAIL PROTECTED] file=/home/mikulasek/Desktop/mcc.jks/ /sec:keyManagers sec:trustManagers sec:keyStore type=JKS password=[EMAIL PROTECTED] file=/home/mikulasek/Desktop/mcc.jks/ /sec:trustManagers sec:cipherSuitesFilter !-- these filters ensure that a ciphersuite with export-suitable or null encryption is used, but exclude anonymous Diffie-Hellman key change as this is vulnerable to man-in-the-middle attacks -- sec:include.*_EXPORT_.*/sec:include sec:include.*_EXPORT1024_.*/sec:include sec:include.*_WITH_DES_.*/sec:include sec:include.*_WITH_NULL_.*/sec:include sec:exclude.*_DH_anon_.*/sec:exclude /sec:cipherSuitesFilter sec:clientAuthentication want=true required=true/ /httpj:tlsServerParameters /httpj:engine /httpj:engine-factory /beans -- Jiri Mikulasek - Developer AURA, s.r.o. Uvoz 499/56; 602 00 Brno ISO 9001 certified company AQAP 2110 (ČOS 051622) tel./fax: +420 544 508 115 e-mail: [EMAIL PROTECTED] http://www.aura.cz -
Re: Securing server
Hi again, sorry I forgot to add new namesapce to schemaLocation also and could not catch this trivial mistake for a long time On Thursday 13 of December 2007 14:22:17 Bc. Jiří Mikulášek wrote: Hi all, I would like to secure my server and started with first*https sample. Here is my configuration below, but I am still getting this error: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'httpj:engine-factory'. Have somebody any idea? I have also checked xsd in modules and it seems to be ok. thanks a lot beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd; xmlns:http-conf=http://cxf.apache.org/transports/http/configuration; xmlns:sec=http://cxf.apache.org/configuration/security; xmlns:httpj=http://cxf.apache.org/transports/http-jetty/configuration; httpj:engine-factory bus=cxf httpj:engine port=8090 httpj:tlsServerParameters sec:keyManagers keyPassword=[EMAIL PROTECTED] sec:keyStore type=JKS password=[EMAIL PROTECTED] file=/home/mikulasek/Desktop/mcc.jks/ /sec:keyManagers sec:trustManagers sec:keyStore type=JKS password=[EMAIL PROTECTED] file=/home/mikulasek/Desktop/mcc.jks/ /sec:trustManagers sec:cipherSuitesFilter !-- these filters ensure that a ciphersuite with export-suitable or null encryption is used, but exclude anonymous Diffie-Hellman key change as this is vulnerable to man-in-the-middle attacks -- sec:include.*_EXPORT_.*/sec:include sec:include.*_EXPORT1024_.*/sec:include sec:include.*_WITH_DES_.*/sec:include sec:include.*_WITH_NULL_.*/sec:include sec:exclude.*_DH_anon_.*/sec:exclude /sec:cipherSuitesFilter sec:clientAuthentication want=true required=true/ /httpj:tlsServerParameters /httpj:engine /httpj:engine-factory /beans -- Jiri Mikulasek - Developer AURA, s.r.o. Uvoz 499/56; 602 00 Brno ISO 9001 certified company AQAP 2110 (ČOS 051622) tel./fax: +420 544 508 115 e-mail: [EMAIL PROTECTED] http://www.aura.cz -
My own TrustManager
Hi all, I need to add some spicific features to my SSL communictaion - so basically I would like to implement my own TrustManager. But when using CXF the code suplying TrustManagers is not under my control. Is there any way how to do it ofr CXF? thanks for any hints -- Jiri Mikulasek - Developer AURA, s.r.o. Uvoz 499/56; 602 00 Brno ISO 9001 certified company AQAP 2110 (ČOS 051622) tel./fax: +420 544 508 115 e-mail: [EMAIL PROTECTED] http://www.aura.cz -
PropertyPlaceHolderConfigurer and cxf.xml
Hi all,
I would like to use PropertyPlaceHolder inc cxf.xml tu enable some parameters
modification from properties.
So I would like to use something like:
http-conf:client AllowChunking=false
property
name=ConnectionTimeoutvalue${ConnectionTimeout}/value/property
property
name=ReceiveTimeoutvalue${ReceiveTimeout}/value/property
/http-conf:client
which obviously doesn't work.
Please give me some advice how to handle this situation correctly.
Thanks a lot
--
Jiri Mikulasek
-
Developer
AURA, s.r.o.
Uvoz 499/56; 602 00 Brno
ISO 9001 certified company
AQAP 2110 (ČOS 051622)
tel./fax: +420 544 508 115
e-mail: [EMAIL PROTECTED]
http://www.aura.cz
-
Re: CRL support
Thanks a lot I will check it out
On Thursday 29 of November 2007 15:24:57 Fred Dushin wrote:
See the http-conf:trustDecider in
https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/transports/
http/src/main/resources/schemas/configuration/http-conf.xsd
You'll need to implement your own
org.apache.cxf.transport.http.MessageTrustDecider, but this will get
called when a connection is established. Unfortunately, because of
the design of the Sun JSSE, this is not a hook into the handshake,
but your trust decider should be called before any application data
is sent down the pipe. That's the idea, at any rate.
-Fred
On Nov 28, 2007, at 4:26 PM, Bc. Jiří Mikulášek wrote:
thanks, because I really need CRL support is there any way how to
handle it on
my own - maybe use some interceptor, which will handle it before each
connection? If there is such possibility, please can somebody give
me few
basic hints, where to start what to care and so...?
Dne středa 28 listopad 2007 21:32 Fred Dushin napsal(a):
CXF does not have support for CRLs.
On Nov 28, 2007, at 6:18 AM, Bc. Jiří Mikulášek wrote:
Hi all,
can somebody give me a hint how to configure or program CRL
(certificate
revocation list) checking before each SSL handshake.
In detail:
I have this configuration on client:
http-conf:conduit
name={http:///}portName.http-conduit;
http-conf:client AllowChunking=false /
http-conf:tlsClientParameters secureSocketProtocol=SSL
sec:trustManagers
sec:keyStore type=JKS password=password
url=someurl/
/sec:trustManagers
sec:keyManagers keyPassword=password
sec:keyStore type=JKS password=password
url=someurl/
/sec:keyManagers
/http-conf:tlsClientParameters
which causes ssl communication, but before each connection I would
like to
check all certificates i keystores for revocation according some
CRL on
filesystem
thanks for any advice
--
Jiri Mikulasek
-
Developer
AURA, s.r.o.
Uvoz 499/56; 602 00 Brno
ISO 9001 certified company
AQAP 2110 (ČOS 051622)
tel./fax: +420 544 508 115
e-mail: [EMAIL PROTECTED]
http://www.aura.cz
-
--
Jiri Mikulasek
-
Developer
AURA, s.r.o.
Uvoz 499/56; 602 00 Brno
ISO 9001 certified company
AQAP 2110 (ČOS 051622)
tel./fax: +420 544 508 115
e-mail: [EMAIL PROTECTED]
http://www.aura.cz
-
CRL support
Hi all,
can somebody give me a hint how to configure or program CRL (certificate
revocation list) checking before each SSL handshake.
In detail:
I have this configuration on client:
http-conf:conduit
name={http:///}portName.http-conduit;
http-conf:client AllowChunking=false /
http-conf:tlsClientParameters secureSocketProtocol=SSL
sec:trustManagers
sec:keyStore type=JKS password=password
url=someurl/
/sec:trustManagers
sec:keyManagers keyPassword=password
sec:keyStore type=JKS password=password
url=someurl/
/sec:keyManagers
/http-conf:tlsClientParameters
which causes ssl communication, but before each connection I would like to
check all certificates i keystores for revocation according some CRL on
filesystem
thanks for any advice
--
Jiri Mikulasek
-
Developer
AURA, s.r.o.
Uvoz 499/56; 602 00 Brno
ISO 9001 certified company
AQAP 2110 (ČOS 051622)
tel./fax: +420 544 508 115
e-mail: [EMAIL PROTECTED]
http://www.aura.cz
-
Re: WSS4jInInterceptor properties
Thanks, I know about this, but it is still not what I am searching for. Imagine that you would like to setup these properties through cxf configuration, then you need to know what are values of these constants (this information is not in javadoc). Ok still I can go through source of wss4j or printout all these constants in simple program. But in a normal world when somewhere is the possiblity to configure some properties, man expects there is a list of them available :-), which seems to be not this case. On Tuesday 23 of October 2007 08:51:45 Mayank Mishra wrote: Bc. Jiří Mikulášek wrote: Hi all, is there any list of possible values and properties if wss4jinterceptors available? I could not find it in the javadoc nor in user guide. Hi Jiri, Have a look at, http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/handler/WSHandler Constants.html This class list various configuration properties which can be passed to WSS4J In and Out interceptor configurations. With Regards, Mayank Yes of course I haven't tried to go trough the source of the interceptor or wss4j ;-( thanks for any advice -- Jiri Mikulasek - Developer AURA, s.r.o. Uvoz 499/56; 602 00 Brno ISO 9001 certified company AQAP 2110 (ČOS 051622) tel./fax: +420 544 508 115 e-mail: [EMAIL PROTECTED] http://www.aura.cz -
Re: JAXB Bindings problem in runtime
Hi, we have migrated to 2.0.2 version and problem seems to be solved. Thanks
for help
On Friday 19 of October 2007 11:20:19 Jim Ma wrote:
This issue is fixed in cxf 2.0.2 . You need to update cxf to 2.0.2 .
Cheers
Jim
Bc. Jiří Mikulášek wrote:
Hi,
we are using cxf 2.0, we are using wsdl provided by SAP in Norway (and
because we don't speak Norwegian and whole application is developed in
english we have done this jaxws and jaxb binding customization).
So, we are developing client side using cxf, soap binding is
document/literal wrapped. We are using soapui to mock the service side
(it is a tool which can import wsdl and simply mock the service). We are
logging from cxf both requests and response.
Jaxb binding is customized both for request and response wrapper. While
generating request, everything is OK and problem is while handling
response.
Our client is started by this code:
NoMilSapNumberLookupService service = new
NoMilSapNumberLookupService(wsdlUrl, serviceName);
service.getZMMMATEXISTMATNRSoapBinding().existSapNumber(
ASKING_SYSTEM,
sapNumber,
status,
nsn,
description);
shortened client stub:
@WebServiceClient(name = ZMM_MAT_EXIST_MATNRService, targetNamespace
= urn:sap-com:document:sap:soap:functions:mc-style)
public class NoMilSapNumberLookupService extends Service {
public NoMilSapNumberLookupService(URL wsdlLocation, QName serviceName) {
super(wsdlLocation, serviceName);
}
}
see wsdl and binding customization in attachment.
On Friday 19 of October 2007 09:58:20 Jim Ma wrote:
Hi ,
Could you tell me more information about this issue ?
Which version CXF did you use ?
How did you start and call this service ?
Cheers
Jim
Bc. Jiří Mikulášek wrote:
Hi all,
I have used wsdl2java with external binding file specified through -b.
My stubs for client have been generated correctly, but I got in trouble
during runtime.
The point is, that have renamed response properties names. But it seems
that cxf ignores jaxb annotations when handling the response wrapper.
More concretly
thanks to this part of external binding file:
jaxws:bindings
node=wsdl:definitions/wsdl:types/xsd:[EMAIL PROTECTED]'urn:sap-
co m:document:sap:soap:functions:mc-style']
jaxb:bindings
node=xsd:[EMAIL PROTECTED]'ZBapiMaterialExistsMatnrResponse']/xsd:complex
Ty pe/xsd:sequence/xsd:[EMAIL PROTECTED]'MaterialFinnes'] jaxb:property
name=existMark /
/jaxb:bindings
/jaxws:bindings
this code is generated:
@XmlElement(name = MaterialFinnes, required = true)
protected String existMark;
public String getExistMark() {
return existMark;
}
public void setExistMark(String value) {
this.existMark = value;
}
but when trying to use this client against some mockservice generated
from the same wsdl I got:
Caused by: java.lang.NoSuchMethodException:
cz.aura.isl.katalog.davky.control.sapnorway.sapnumberlookup.SapNumberLo
ok upResponse.getMaterialFinnes() at
org.apache.cxf.jaxb.WrapperHelper.getWrappedPart(WrapperHelper.java:194
) at
org.apache.cxf.jaxws.interceptors.WrapperClassInInterceptor.handleMessa
ge (WrapperClassInInterceptor.java:136) ... 70 more
--
Jiri Mikulasek
-
Developer
AURA, s.r.o.
Uvoz 499/56; 602 00 Brno
ISO 9001 certified company
AQAP 2110 (ČOS 051622)
tel./fax: +420 544 508 115
e-mail: [EMAIL PROTECTED]
http://www.aura.cz
-
WSS4jInInterceptor properties
Hi all, is there any list of possible values and properties if wss4jinterceptors available? I could not find it in the javadoc nor in user guide. Yes of course I haven't tried to go trough the source of the interceptor or wss4j ;-( thanks for any advice -- Jiri Mikulasek - Developer AURA, s.r.o. Uvoz 499/56; 602 00 Brno ISO 9001 certified company AQAP 2110 (ČOS 051622) tel./fax: +420 544 508 115 e-mail: [EMAIL PROTECTED] http://www.aura.cz -
Re: JAXB Bindings problem in runtime
Hi,
we are using cxf 2.0, we are using wsdl provided by SAP in Norway (and because
we don't speak Norwegian and whole application is developed in english we
have done this jaxws and jaxb binding customization).
So, we are developing client side using cxf, soap binding is document/literal
wrapped. We are using soapui to mock the service side (it is a tool which can
import wsdl and simply mock the service). We are logging from cxf both
requests and response.
Jaxb binding is customized both for request and response wrapper. While
generating request, everything is OK and problem is while handling response.
Our client is started by this code:
NoMilSapNumberLookupService service = new NoMilSapNumberLookupService(wsdlUrl,
serviceName);
service.getZMMMATEXISTMATNRSoapBinding().existSapNumber(
ASKING_SYSTEM,
sapNumber,
status,
nsn,
description);
shortened client stub:
@WebServiceClient(name = ZMM_MAT_EXIST_MATNRService, targetNamespace
= urn:sap-com:document:sap:soap:functions:mc-style)
public class NoMilSapNumberLookupService extends Service {
public NoMilSapNumberLookupService(URL wsdlLocation, QName serviceName) {
super(wsdlLocation, serviceName);
}
}
see wsdl and binding customization in attachment.
On Friday 19 of October 2007 09:58:20 Jim Ma wrote:
Hi ,
Could you tell me more information about this issue ?
Which version CXF did you use ?
How did you start and call this service ?
Cheers
Jim
Bc. Jiří Mikulášek wrote:
Hi all,
I have used wsdl2java with external binding file specified through -b. My
stubs for client have been generated correctly, but I got in trouble
during runtime.
The point is, that have renamed response properties names. But it seems
that cxf ignores jaxb annotations when handling the response wrapper.
More concretly
thanks to this part of external binding file:
jaxws:bindings
node=wsdl:definitions/wsdl:types/xsd:[EMAIL PROTECTED]'urn:sap-co
m:document:sap:soap:functions:mc-style']
jaxb:bindings
node=xsd:[EMAIL PROTECTED]'ZBapiMaterialExistsMatnrResponse']/xsd:complexTy
pe/xsd:sequence/xsd:[EMAIL PROTECTED]'MaterialFinnes'] jaxb:property
name=existMark /
/jaxb:bindings
/jaxws:bindings
this code is generated:
@XmlElement(name = MaterialFinnes, required = true)
protected String existMark;
public String getExistMark() {
return existMark;
}
public void setExistMark(String value) {
this.existMark = value;
}
but when trying to use this client against some mockservice generated
from the same wsdl I got:
Caused by: java.lang.NoSuchMethodException:
cz.aura.isl.katalog.davky.control.sapnorway.sapnumberlookup.SapNumberLook
upResponse.getMaterialFinnes() at
org.apache.cxf.jaxb.WrapperHelper.getWrappedPart(WrapperHelper.java:194)
at
org.apache.cxf.jaxws.interceptors.WrapperClassInInterceptor.handleMessage
(WrapperClassInInterceptor.java:136) ... 70 more
--
Jiri Mikulasek
-
Developer
AURA, s.r.o.
Uvoz 499/56; 602 00 Brno
ISO 9001 certified company
AQAP 2110 (ČOS 051622)
tel./fax: +420 544 508 115
e-mail: [EMAIL PROTECTED]
http://www.aura.cz
-
jaxws:bindings wsdlLocation=ZMM_MAT_EXIST_MATNR.wsdl xmlns:jaxws=http://java.sun.com/xml/ns/jaxws; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:jaxb=http://java.sun.com/xml/ns/jaxb; xmlns:xsd=http://www.w3.org/2001/XMLSchema;
jaxws:package name=cz.aura.isl.katalog.davky.control.sapnorway.services/
jaxws:bindings node=wsdl:definitions/wsdl:[EMAIL PROTECTED]'ZMM_MAT_EXIST_MATNR']
jaxws:class name=NoMilSapNumberLookupServicePortType /
/jaxws:bindings
jaxws:bindings node=wsdl:definitions/wsdl:[EMAIL PROTECTED]'ZMM_MAT_EXIST_MATNRService']
jaxws:class name=NoMilSapNumberLookupService /
/jaxws:bindings
jaxws:bindings node=wsdl:definitions/wsdl:[EMAIL PROTECTED]'ZMM_MAT_EXIST_MATNR']/wsdl:[EMAIL PROTECTED]'ZBapiMaterialExistsMatnr']
jaxws:method name=existSapNumber /
/jaxws:bindings
jaxws:bindings node=wsdl:definitions/wsdl:types/xsd:[EMAIL PROTECTED]'urn:sap-com:document:sap:soap:functions:mc-style']
jaxb:bindings node=xsd:[EMAIL PROTECTED]'ZBapiMaterialExistsMatnr']
jaxb:class name=SapNumberLookupRequest /
/jaxb:bindings
/jaxws:bindings
jaxws:bindings node=wsdl:definitions/wsdl:types/xsd:[EMAIL PROTECTED]'urn:sap-com:document:sap:soap:functions:mc-style']
jaxb:bindings node=xsd:[EMAIL PROTECTED]'ZBapiMaterialExistsMatnr']/xsd:complexType/xsd:sequence/xsd:[EMAIL PROTECTED]'AskingSystem']
jaxb:property name=askingSystem /
/jaxb:bindings
/jaxws:bindings
jaxws:bindings node
Re: Missing prefix in request on IBM
Hi thanks a lot for information. I am not very experienced regarding binding
styles but I presume that we are using doc/lit/wrapped. We are suing stubs
and here is how the stub looks like:
@WebService(targetNamespace = http://sapdev06.webmeth65.osl.no/;, name
= NoMilSapMaterial_WebServicePortType)
public interface NoMilSapMaterialWebServicePortType {
@WebResult(targetNamespace = , name = Material)
@RequestWrapper(localName = Material, targetNamespace
= sapdev06material.com, className = com.sapdev06material.Material)
@ResponseWrapper(localName = Response, targetNamespace
= sapdev06material.com, className = com.sapdev06material.Response)
@WebMethod(operationName = Material)
public
java.util.Listlocalhost.nomilsapmaterial.webservice.senditem.ResponseMaterial
material(
@WebParam(targetNamespace = , name = Item)
java.util.Listcom.sapdev06material.Material.Item item
);
}
What's strange to me, that if I debug a get to the BareOutInterceptor, which
calls JAXBEncoderDecoder. This thing seems to be not consisten with your
described cases. Am I wrong (may be it is the first case)?
I encounter now also one more strange thing: When we ommit saaj-impl from the
classpath on AIX and there is no SOAPFault (because that's the case saaj-impl
is needed), there is prefix generated (we see ns2:Vendor xmlns:ns2=) If
we put this saaj-impl back on classpath, it is generated again without
prefix. Again be aware that this magic happens only on AIX with IBM java :-)
Best Regards
On Wednesday 26 of September 2007 00:21:06 Daniel Kulp wrote:
Well, this area of the serialization should have no JDK differences.
Not sure what would cause it.
That said, some hints:
Is it our normal JAX-WS + JAXB?
Is is wrapped doc/lit and using wrapper objects?
If the answer to both is yes, then it really is completely in the
JAXB runtime to do the serialization. The breakpoint you would want
would be in the JAXBEncoderDecoder marshal method.
If it's RPC/lit, it would be in
RPCOutInterceptor
If it's Doc/Lit/Wrapped without the JAX-WS wrapper types, it would be the
WrappedOutInterceptor (see note about this below)
If it's Doc/Lit/Bare, the BareOutInterceptor, but again probably
delegates to JAXB/Aegis via the writeParts method of the
AbstractOutDatabindingInterceptor superclass.
One thing I must add though:
Check the CXF version. Version 2.0 DID output with the
Vendor xmlns:ns2=some:namespace
form. That was changed for 2.0.1 where the WrappedOutInterceptor was
updated to always namespace prefix the wrapper element. 2.0.2 is being
released today (already at the download location, waiting for sites to
sync before sending the announcment).
Dan
On Tuesday 25 September 2007, Bc. Jiří Mikulášek wrote:
I understand, that's why I am looking for just a hint about the
architecture - can somebody tell me which CXF class or which another
library is responsible for serializing the SOAP request. If I find a
proper point, I can download sources, debug and experiment with it.
There must be some difference in IBM java for AIX and other system
which definetely cause my problem. If I will know who is responsible
for serializing soap request in cxf it will be easy to find which API
from jdk is called and findout the difference then maybe proivde some
patch...
Dne úterý 25 září 2007 23:44 Benson Margulies napsal(a):
This is going to be mighty difficult to make any sense of. I, for
one, have no access to an environment to repro this in.
-Original Message-
From: Bc. Jiří Mikulášek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 3:45 PM
To: cxf-user@incubator.apache.org
Subject: Missing prefix in request on IBM
Hello,
yet another question regarding WS-client development on IBM.
This issue appears only on IBM java on AIX os. Using IBM java on
another operating system everything works fine.
There is missing prefix by operation element in SOAP request. We
are using document/literal wrapped binding
Our request on IBM looks like (without an envelope):
soap:Body
Vendor xmlns:ns2=some:namespace
/Vendor
/soap:Body
but should look like (and looks like on windows or linux):
soap:Body
ns2:Vendor xmlns:ns2=some:namespace
/ns2:Vendor
/soap:Body
The missing prefix is problem for the service part (not developed
by us and
running on webmethods) and the operation couldn't be called - we
got Service :Vendor does not exist.
Please can somebody give me a hint which part of cxf or another
library is responsible for serializing the SOAP request and what
jdk dependent API is used? I must try to findout the primary cause
otherwis this problem cannot be
fixed. Our tests have just proven that the xerces implementation
has no influence
Re: Missing prefix in request on IBM
Hi all,
finally I found the primary cause and fortunately it has nothing with
saaj-impl or cxf at all.
The problem is that all the wars deployed on AIX were obfuscated and know we
have found that when we deploy nonobfuscated wwar, everything is ok.
Still the problem is little bit mysterious, because the obfuscator excludes
all thridparty libraries and so. The only one thing which is obfuscated from
whole CXF client is the generated stub. Now we are trying to configure
obfuscator to exclude these classes from process.
Again thanks a lot for your time and investigation.
On Wednesday 26 of September 2007 09:31:52 Bc. Jiří Mikulášek wrote:
Hi thanks a lot for information. I am not very experienced regarding
binding styles but I presume that we are using doc/lit/wrapped. We are
suing stubs and here is how the stub looks like:
@WebService(targetNamespace = http://sapdev06.webmeth65.osl.no/;, name
= NoMilSapMaterial_WebServicePortType)
public interface NoMilSapMaterialWebServicePortType {
@WebResult(targetNamespace = , name = Material)
@RequestWrapper(localName = Material, targetNamespace
= sapdev06material.com, className = com.sapdev06material.Material)
@ResponseWrapper(localName = Response, targetNamespace
= sapdev06material.com, className = com.sapdev06material.Response)
@WebMethod(operationName = Material)
public
java.util.Listlocalhost.nomilsapmaterial.webservice.senditem.ResponseMater
ial material(
@WebParam(targetNamespace = , name = Item)
java.util.Listcom.sapdev06material.Material.Item item
);
}
What's strange to me, that if I debug a get to the BareOutInterceptor,
which calls JAXBEncoderDecoder. This thing seems to be not consisten with
your described cases. Am I wrong (may be it is the first case)?
I encounter now also one more strange thing: When we ommit saaj-impl from
the classpath on AIX and there is no SOAPFault (because that's the case
saaj-impl is needed), there is prefix generated (we see ns2:Vendor
xmlns:ns2=) If we put this saaj-impl back on classpath, it is
generated again without prefix. Again be aware that this magic happens only
on AIX with IBM java :-)
Best Regards
On Wednesday 26 of September 2007 00:21:06 Daniel Kulp wrote:
Well, this area of the serialization should have no JDK differences.
Not sure what would cause it.
That said, some hints:
Is it our normal JAX-WS + JAXB?
Is is wrapped doc/lit and using wrapper objects?
If the answer to both is yes, then it really is completely in the
JAXB runtime to do the serialization. The breakpoint you would want
would be in the JAXBEncoderDecoder marshal method.
If it's RPC/lit, it would be in
RPCOutInterceptor
If it's Doc/Lit/Wrapped without the JAX-WS wrapper types, it would be the
WrappedOutInterceptor (see note about this below)
If it's Doc/Lit/Bare, the BareOutInterceptor, but again probably
delegates to JAXB/Aegis via the writeParts method of the
AbstractOutDatabindingInterceptor superclass.
One thing I must add though:
Check the CXF version. Version 2.0 DID output with the
Vendor xmlns:ns2=some:namespace
form. That was changed for 2.0.1 where the WrappedOutInterceptor was
updated to always namespace prefix the wrapper element. 2.0.2 is being
released today (already at the download location, waiting for sites to
sync before sending the announcment).
Dan
On Tuesday 25 September 2007, Bc. Jiří Mikulášek wrote:
I understand, that's why I am looking for just a hint about the
architecture - can somebody tell me which CXF class or which another
library is responsible for serializing the SOAP request. If I find a
proper point, I can download sources, debug and experiment with it.
There must be some difference in IBM java for AIX and other system
which definetely cause my problem. If I will know who is responsible
for serializing soap request in cxf it will be easy to find which API
from jdk is called and findout the difference then maybe proivde some
patch...
Dne úterý 25 září 2007 23:44 Benson Margulies napsal(a):
This is going to be mighty difficult to make any sense of. I, for
one, have no access to an environment to repro this in.
-Original Message-
From: Bc. Jiří Mikulášek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 3:45 PM
To: cxf-user@incubator.apache.org
Subject: Missing prefix in request on IBM
Hello,
yet another question regarding WS-client development on IBM.
This issue appears only on IBM java on AIX os. Using IBM java on
another operating system everything works fine.
There is missing prefix by operation element in SOAP request. We
are using document/literal wrapped binding
Our request on IBM looks like (without an envelope):
soap:Body
Vendor xmlns:ns2=some:namespace
/Vendor
alternative to saaj?
Hello, we are developing for IBM java on AIX, which doesn't contain packages like com.sun.org.apache.xerces.*. Unfortunately saaj-impl depends directly on these packages. Is there some possibility to replace saaj implementation with another alternative? I have already tried axis2-saaj implementation but got into deep troubles with many org.w3c.dom.* Exceptions yes I know I can force AIX java to use xercesImpl (containing those packages), but it is not clean and therefore we prefer to remove the ugly library saaj-impl Best Regards -- Jiri Mikulasek - Developer AURA, s.r.o. Uvoz 499/56; 602 00 Brno ISO 9001 certified company AQAP 2110 (ČOS 051622) tel./fax: +420 544 508 115 e-mail: [EMAIL PROTECTED] http://www.aura.cz -
Missing prefix in request on IBM
Hello, yet another question regarding WS-client development on IBM. This issue appears only on IBM java on AIX os. Using IBM java on another operating system everything works fine. There is missing prefix by operation element in SOAP request. We are using document/literal wrapped binding Our request on IBM looks like (without an envelope): soap:Body Vendor xmlns:ns2=some:namespace /Vendor /soap:Body but should look like (and looks like on windows or linux): soap:Body ns2:Vendor xmlns:ns2=some:namespace /ns2:Vendor /soap:Body The missing prefix is problem for the service part (not developed by us and running on webmethods) and the operation couldn't be called - we got Service :Vendor does not exist. Please can somebody give me a hint which part of cxf or another library is responsible for serializing the SOAP request and what jdk dependent API is used? I must try to findout the primary cause otherwis this problem cannot be fixed. Our tests have just proven that the xerces implementation has no influence. Thank you Jiri Mikulasek
Re: Missing prefix in request on IBM
I understand, that's why I am looking for just a hint about the architecture - can somebody tell me which CXF class or which another library is responsible for serializing the SOAP request. If I find a proper point, I can download sources, debug and experiment with it. There must be some difference in IBM java for AIX and other system which definetely cause my problem. If I will know who is responsible for serializing soap request in cxf it will be easy to find which API from jdk is called and findout the difference then maybe proivde some patch... Dne úterý 25 září 2007 23:44 Benson Margulies napsal(a): This is going to be mighty difficult to make any sense of. I, for one, have no access to an environment to repro this in. -Original Message- From: Bc. Jiří Mikulášek [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 3:45 PM To: cxf-user@incubator.apache.org Subject: Missing prefix in request on IBM Hello, yet another question regarding WS-client development on IBM. This issue appears only on IBM java on AIX os. Using IBM java on another operating system everything works fine. There is missing prefix by operation element in SOAP request. We are using document/literal wrapped binding Our request on IBM looks like (without an envelope): soap:Body Vendor xmlns:ns2=some:namespace /Vendor /soap:Body but should look like (and looks like on windows or linux): soap:Body ns2:Vendor xmlns:ns2=some:namespace /ns2:Vendor /soap:Body The missing prefix is problem for the service part (not developed by us and running on webmethods) and the operation couldn't be called - we got Service :Vendor does not exist. Please can somebody give me a hint which part of cxf or another library is responsible for serializing the SOAP request and what jdk dependent API is used? I must try to findout the primary cause otherwis this problem cannot be fixed. Our tests have just proven that the xerces implementation has no influence. Thank you Jiri Mikulasek
