Re: Href attribute support in soap envelope body
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 the Delphi doc).
But the Web service call from Delphi always produces null values as
incoming parameters in my Java Web service, without any exceptions or
warnings on the CXF side. This is the request that Delphi sends now:
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
ExecuteJob xmlns=http://annuaire.ciss.lu;
JobNameTestFromDelphi/JobName
JobParamsIn
stringvalueDelphi1/string
stringvalueDelphi2/string
/JobParamsIn
JobParamBean
keykeyDelphi/key
value2/value
/JobParamBean
/ExecuteJob
/SOAP-ENV:Body
/SOAP-ENV:Envelope
The Java client (which still works correctly) sends the following request:
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body
ns1:ExecuteJob xmlns:ns1=http://annuaire.ciss.lu;
JobNameTestFromJava/JobName
JobParamsInvalueJava1/JobParamsIn
JobParamsInvalueJava2/JobParamsIn
JobParamBean
keykeyJava/key
value1/value
/JobParamBean
/ns1:ExecuteJob
/soap:Body
/soap:Envelope
As there are some minor differences, is the request from Delphi
incorrect / incompatible? If so, I will perhaps continue to investigate
the issue on a Delphi forum resp. send a bug report to Codegear.
Thanks in advance.
Pierre
Daniel Kulp wrote:
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string
SOAP-ENV:stringArray
Umm... why would the string and stringArray things be in the SOAP-ENV
namespace? That DEFINITELY looks bad. Looks like some more Delphi
configuration is needed somehow.
That said, you should definitely use a wrapped/doc/lit, not bare. So
the message should look something like;
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
ns1:executeJob xmlns:ns1=..
JobNameTestFromDelphi/JobName
/ns1:executeJob
/SOAP-ENV:Body
/SOAP-ENV:Envelope
Dan
On Monday 25 February 2008, pierre post wrote:
Thanks for pointing me in the right direction, Ian. I also suspected
that it's an encoding problem but I wasn't sure.
Unfortunately, after some more trialerror tests, I didn't come to a
positive result. Removing the @SOAPBinding i.e. using wrapped
document/literal/wrapped generates a far more complex Delphi unit
(that would be the least of the problems) but furthermore, now no
parameters at all are correctly received in the Java Web service (only
null values).
I looked up the Delphi documentation and after a little research added
the line
InvRegistry.RegisterInvokeOptions(TypeInfo(JobService), [ioDocument,
ioLiteral]);
in my Delphi client, so Delphi *should* definitively use
document/literal encoding. But no change.
But, if I use the document/literal/bare encoding, I receive the
following error message from CXF:
25-Feb-2008 11:05:07 org.apache.cxf.phase.PhaseInterceptorChain
doIntercept INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Message part
{http://schemas.xmlsoap.org/soap/envelope/}string was not recognized.
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLi
teralInInterceptor.java:178) at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rChain.java:208) at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
tionObserver.java:77) ...
Delphi sends the following SOAP request:
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string
SOAP-ENV:stringArray
stringvalueDelphi1/string
stringvalueDelphi2/string
/SOAP-ENV:stringArray
JobParamBean xmlns=http://annuaire.ciss.lu;
keykeyDelphi/key
value2/value
/JobParamBean
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This whole encoding issue is getting rather frustrating for me, having
in mind Web services should improve
Re: Href attribute support in soap envelope body
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; JobNameTestFromJava/JobName In the second case, JobName is unqualifed in that it doesn't have a namespace associated with it. Delphi is sending it out with the default namespace set so that JobName is qualified. There are two ways to approach how to get it working for you: 1) Research more in Delphi to figure out how to get it to send unqualified requests.Note: the ExecuteJob element SHOULD be qualified, but the children shouldn't. 2) Change the CXF server to expect it to be qualified. With 2.0.4, #2 isn't very hard. In the packages where your service is defined and where your java beans are defined, add a package-info.java that contains something like: @javax.xml.bind.annotation.XmlSchema( namespace = http://annuaire.ciss.lu;, elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED) package lu.ciss.annuaire; That should flip CXF to using qualified schemas. Dan On Tuesday 26 February 2008, pierre post wrote: 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 the Delphi doc). But the Web service call from Delphi always produces null values as incoming parameters in my Java Web service, without any exceptions or warnings on the CXF side. This is the request that Delphi sends now: ?xml version=1.0? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body ExecuteJob xmlns=http://annuaire.ciss.lu; JobNameTestFromDelphi/JobName JobParamsIn stringvalueDelphi1/string stringvalueDelphi2/string /JobParamsIn JobParamBean keykeyDelphi/key value2/value /JobParamBean /ExecuteJob /SOAP-ENV:Body /SOAP-ENV:Envelope The Java client (which still works correctly) sends the following request: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:ExecuteJob xmlns:ns1=http://annuaire.ciss.lu; JobNameTestFromJava/JobName JobParamsInvalueJava1/JobParamsIn JobParamsInvalueJava2/JobParamsIn JobParamBean keykeyJava/key value1/value /JobParamBean /ns1:ExecuteJob /soap:Body /soap:Envelope As there are some minor differences, is the request from Delphi incorrect / incompatible? If so, I will perhaps continue to investigate the issue on a Delphi forum resp. send a bug report to Codegear. Thanks in advance. Pierre Daniel Kulp wrote: SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string SOAP-ENV:stringArray Umm... why would the string and stringArray things be in the SOAP-ENV namespace? That DEFINITELY looks bad. Looks like some more Delphi configuration is needed somehow. That said, you should definitely use a wrapped/doc/lit, not bare. So the message should look something like; SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body ns1:executeJob xmlns:ns1=.. JobNameTestFromDelphi/JobName /ns1:executeJob /SOAP-ENV:Body /SOAP-ENV:Envelope Dan On Monday 25 February 2008, pierre post wrote: Thanks for pointing me in the right direction, Ian. I also suspected that it's an encoding problem but I wasn't sure. Unfortunately, after some more trialerror tests, I didn't come to a positive result. Removing the @SOAPBinding i.e. using wrapped document/literal/wrapped generates a far more complex Delphi unit (that would be the least of the problems) but furthermore, now no parameters at all are correctly received in the Java Web service (only null values). I looked up the Delphi documentation and after a little research added the line InvRegistry.RegisterInvokeOptions(TypeInfo(JobService), [ioDocument, ioLiteral]); in my Delphi client, so Delphi *should* definitively use
AW: Aegis DataBinding does not work
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 interface/impl used jax-ws annotations.
2- in my spring config used the latest changes as defined at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
On the client side;
1- in my client code used JaxWsProxyFactoryBean factory = new
JaxWsProxyFactoryBean();
2- left the code as factory.getServiceFactory().setDataBinding(new
AegisDatabinding());
Now it works H... ??? Any thoughts on this?
I am not sure if this work around is safe because I shall next attempt using
complex types (e.g. Vector) on the interface methods.
Cheers
Tezcan
-Ursprüngliche Nachricht-
Von: Benson Margulies [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 25. Februar 2008 14:17
An: Dilshener, Tezcan (ext.)
Betreff: Re: Aegis DataBinding does not work
Did you see my message to the list about AegisServiceConfiguration?
Please take that our of your spring config and try again.
On Mon, Feb 25, 2008 at 6:54 AM, [EMAIL PROTECTED] wrote:
Hi Benson,
I saw your note on updated documentation.
I have corrected my spring-config accordingly but it did not
make any difference.
I am still receiving the following error
org.apache.cxf.interceptor.Fault: Message part {http://pojo.spring.demo/}sayHi
http://pojo.spring.demo/%7DsayHi was not recognized.
Any more ideas?
1-) my cfx version is 2.0.4
2-) my client is trying to connect to server by using Aegis
Databinding as per example defined at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html ,
my service is HelloWorld example (without annotations) and
loaded upon startup via the spring config defined at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
INFO: Outbound Message
---
Encoding: UTF-8
Headers: {Accept=[*], SOAPAction=[]}
Messages:
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodyns1:sayHi
xmlns:ns1=http://pojo.spring.demo/;ns1:arg0Tex/ns1:arg0/ns1:sayHi/soap:Body/soap:Envelope
--
25.02.2008 12:49:26
org.apache.cxf.interceptor.LoggingInInterceptor logging
INFO: Inbound Message
Encoding: UTF-8
Headers: {Server=[WebSphere Application Server/6.1], Date=[Mon,
25 Feb 2008 11:49:25 GMT], transfer-encoding=[chunked],
Content-Language=[de-DE], connection=[Close], content-type=[text/xml;
charset=UTF-8]}
Messages:
Message:
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodysoap:Faultfaultcodesoap:Client/faultcodefaultstringMessage
part {http://pojo.spring.demo/}sayHi http://pojo.spring.demo/%7DsayHi was
not recognized./faultstring/soap:Fault/soap:Body/soap:Envelope
--
org.apache.cxf.binding.soap.SoapFault: Message part
{http://pojo.spring.demo/}sayHi http://pojo.spring.demo/%7DsayHi was not
recognized.
-Ursprüngliche Nachricht-
Von: Dilshener, Tezcan (ext.)
Gesendet: Montag, 25. Februar 2008 11:17
An: [EMAIL PROTECTED]; cxf-user@incubator.apache.org
Betreff: AW: Aegis DataBinding does not work
Hi
1-) my cfx version is 2.0.4
2-) my client is trying to connect to server by using Aegis
Databinding (as per http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html ), my service is
HelloWorld example (without annotations) and loaded upon startup via the spring
config defined at http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
and I think it is jax-ws.
So I am not sure what else I am doing wrong or i should do
further.
Cheers
Tezcan
-Ursprüngliche Nachricht-
Von: Benson Margulies
Re: Href attribute support in soap envelope body
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 JobParamsIn nodes (as you can see in my previous posting). If we look at the schema type definition in the WSDL xs:element maxOccurs=unbounded minOccurs=0 name=JobParamsIn type=xs:string/ it is Delphi that has incorrectly serialized the parameter and created an invalid SOAP request that would not pass validation which is disabled by default, right? Pierre Daniel Kulp wrote: 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; JobNameTestFromJava/JobName In the second case, JobName is unqualifed in that it doesn't have a namespace associated with it. Delphi is sending it out with the default namespace set so that JobName is qualified. There are two ways to approach how to get it working for you: 1) Research more in Delphi to figure out how to get it to send unqualified requests.Note: the ExecuteJob element SHOULD be qualified, but the children shouldn't. 2) Change the CXF server to expect it to be qualified. With 2.0.4, #2 isn't very hard. In the packages where your service is defined and where your java beans are defined, add a package-info.java that contains something like: @javax.xml.bind.annotation.XmlSchema( namespace = http://annuaire.ciss.lu;, elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED) package lu.ciss.annuaire; That should flip CXF to using qualified schemas. Dan On Tuesday 26 February 2008, pierre post wrote: 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 the Delphi doc). But the Web service call from Delphi always produces null values as incoming parameters in my Java Web service, without any exceptions or warnings on the CXF side. This is the request that Delphi sends now: ?xml version=1.0? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body ExecuteJob xmlns=http://annuaire.ciss.lu; JobNameTestFromDelphi/JobName JobParamsIn stringvalueDelphi1/string stringvalueDelphi2/string /JobParamsIn JobParamBean keykeyDelphi/key value2/value /JobParamBean /ExecuteJob /SOAP-ENV:Body /SOAP-ENV:Envelope The Java client (which still works correctly) sends the following request: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:ExecuteJob xmlns:ns1=http://annuaire.ciss.lu; JobNameTestFromJava/JobName JobParamsInvalueJava1/JobParamsIn JobParamsInvalueJava2/JobParamsIn JobParamBean keykeyJava/key value1/value /JobParamBean /ns1:ExecuteJob /soap:Body /soap:Envelope As there are some minor differences, is the request from Delphi incorrect / incompatible? If so, I will perhaps continue to investigate the issue on a Delphi forum resp. send a bug report to Codegear. Thanks in advance. Pierre Daniel Kulp wrote: SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string SOAP-ENV:stringArray Umm... why would the string and stringArray things be in the SOAP-ENV namespace? That DEFINITELY looks bad. Looks like some more Delphi configuration is needed somehow. That said, you should definitely use a wrapped/doc/lit, not bare. So the message should look something like; SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body ns1:executeJob xmlns:ns1=.. JobNameTestFromDelphi/JobName /ns1:executeJob /SOAP-ENV:Body /SOAP-ENV:Envelope Dan On Monday 25 February 2008, pierre post wrote: Thanks for pointing me in the right direction, Ian. I also suspected that it's an encoding problem but I
Usage of X509 certificates in WSS4J
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 server or otherwise, I observe Token Reference, the value of the Valuetype attribute in the KeyIdentifier element is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3; AFAIK, In X.509 Certificate Token Profile 1.1, X509v1 certificates were included in the spec, in X509 Certificate Token Profile 1.0, only X509v3 certificates were there to be used. Also, AFAIK, WSS4J supports X.509 Certificate Token Profile 1.0. Please clarify me if I am wrong. Since, X509v3 certs have some more extension elements over X509v1. It should give some error, when passing X509v1 for cryptos creation. Or, it silently use X509v1, but then the valuetype should be #x509v1 instead of #x509v3. There is a bit of confusion. Kindly clarify. With Regards, Mayank
JAX-WS client proxy returning nulls
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 JaxWsProxyFactoryBean(); proxyFactory.getInInterceptors().add(new LoggingInInterceptor()); proxyFactory.getOutInterceptors().add(new LoggingOutInterceptor()); proxyFactory.setServiceClass(FluxionService.class); proxyFactory.setAddress(serviceURL); proxyFactory.setDataBinding(new AegisDatabinding()); FluxionService fs = (FluxionService)proxyFactory.create(); // SNIP Now, I should be able to do: SetURI uris = fs.getDataSources(); to retrieve a set of URIs from this service. When I make this call, I get the following SOAP request and response: Request: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:getDataSources xmlns:ns1=http://service.fluxion.comparagrid.org/; / /soap:Body /soap:Envelope Response: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:getDataSourcesResponse xmlns:ns1=http://service.fluxion.comparagrid.org/; return ns2:anyURI xmlns:ns2=http://impl.service.fluxion.comparagrid.org/; http://metagenome.ncl.ac.uk/cgdemo.owl /ns2:anyURI /return /ns1:getDataSourcesResponse /soap:Body /soap:Envelope That's exactly what I'd expect. However, the actual SetURI returned in my app is null, so I'm seeing NPEs whenever I try and iterate over this set. What's going on here? I'm relatively new to CXF as I've just ported over from XFire so I'm prepared to admit that I might be missing something fundamental but this looks pretty weird to me. Any advice would be highly appreciated as this is driving me mad! Thanks, Tony -- Tony Burdett Software Developer, ComparaGrid. European Bioinformatics Institute email: [EMAIL PROTECTED] tel: 01223 494624
RE: Usage of X509 certificates in WSS4J
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 somebody creating a certificate with no x.509v3 extensions, and also no issuerUniqueID or subjectUniqueID, ..and having a version of 3. A version of 1 would strictly be more correct though. I don't know offhand if Keytool gives you explicit control over the version number or whether it just calculates the version from the logical certificate request data when creating the certificate. Generally all CA certificates must have extensions indicating that they are CAs, so they should have a version number of 3. Application certs on the other hand may vary depending on their content and anticipated usage. Cheers, Donal -Original Message- From: Mayank Mishra [mailto:[EMAIL PROTECTED] Sent: 26 February 2008 10:44 To: cxf-user@incubator.apache.org Subject: Usage of X509 certificates in WSS4J 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 server or otherwise, I observe Token Reference, the value of the Valuetype attribute in the KeyIdentifier element is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-prof ile-1.0#X509v3 AFAIK, In X.509 Certificate Token Profile 1.1, X509v1 certificates were included in the spec, in X509 Certificate Token Profile 1.0, only X509v3 certificates were there to be used. Also, AFAIK, WSS4J supports X.509 Certificate Token Profile 1.0. Please clarify me if I am wrong. Since, X509v3 certs have some more extension elements over X509v1. It should give some error, when passing X509v1 for cryptos creation. Or, it silently use X509v1, but then the valuetype should be #x509v1 instead of #x509v3. There is a bit of confusion. Kindly clarify. With Regards, Mayank IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-WS client proxy returning nulls
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 I've tried tweaking things based on the new stuff in the Aegis docs. I still haven't managed to solve the problem, though. The thing that was puzzling me is that the SOAP messages being sent/received seem to be correct. I assume this means that my service is configured correctly, and that I haven't set the client up to correctly interpret the response - but I've tried directing my client to use the Aegis databinding in a variety of ways and still seem to be getting this null problem. If I'm doing it incorrectly, does anyone have any code examples of how to do this? I can provide more details about my service/client configuration if that will help. Thanks again, Tony. Benson Margulies wrote: Tony, Please check out the current (newly modified) Aegis doc. Perhaps you have the 'AegisServiceConfiguration' enabled on the server side? On Tue, Feb 26, 2008 at 6:08 AM, Tony Burdett [EMAIL PROTECTED] wrote: 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 JaxWsProxyFactoryBean(); proxyFactory.getInInterceptors().add(new LoggingInInterceptor()); proxyFactory.getOutInterceptors().add(new LoggingOutInterceptor()); proxyFactory.setServiceClass(FluxionService.class); proxyFactory.setAddress(serviceURL); proxyFactory.setDataBinding(new AegisDatabinding()); FluxionService fs = (FluxionService)proxyFactory.create(); // SNIP Now, I should be able to do: SetURI uris = fs.getDataSources(); to retrieve a set of URIs from this service. When I make this call, I get the following SOAP request and response: Request: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:getDataSources xmlns:ns1=http://service.fluxion.comparagrid.org/; / /soap:Body /soap:Envelope Response: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:getDataSourcesResponse xmlns:ns1=http://service.fluxion.comparagrid.org/; return ns2:anyURI xmlns:ns2=http://impl.service.fluxion.comparagrid.org/; http://metagenome.ncl.ac.uk/cgdemo.owl /ns2:anyURI /return /ns1:getDataSourcesResponse /soap:Body /soap:Envelope That's exactly what I'd expect. However, the actual SetURI returned in my app is null, so I'm seeing NPEs whenever I try and iterate over this set. What's going on here? I'm relatively new to CXF as I've just ported over from XFire so I'm prepared to admit that I might be missing something fundamental but this looks pretty weird to me. Any advice would be highly appreciated as this is driving me mad! Thanks, Tony -- Tony Burdett Software Developer, ComparaGrid. European Bioinformatics Institute email: [EMAIL PROTECTED] tel: 01223 494624
Re: Usage of X509 certificates in WSS4J
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 nothing actually stopping somebody creating a certificate with no x.509v3 extensions, and also no issuerUniqueID or subjectUniqueID, ..and having a version of 3. A version of 1 would strictly be more correct though. Yes, I agree with you. I don't know offhand if Keytool gives you explicit control over the version number or whether it just calculates the version from the logical certificate request data when creating the certificate. I generated public key certificates and private keys from keytool only. According to [1], It generates v1 certificates and can import/export v1, v2, and v3 certificates.. But I am suspecting it because when while printing out the certificate, I get following along with SerialNumber, Certificate fingerprints. Owner: CN=dev, OU=mycompany, O=myorganization, L=mycity, ST=mystate, C=mycountry, [EMAIL PROTECTED] Issuer: CN=dev, OU=mycompany, O=myorganization, L=mycity, ST=mystate, C=mycountry, [EMAIL PROTECTED] I guess, EMAILADDRESS, etc comes as v3 certificate extensions. Is there any way through which I can verify whether my certificate is v3 certificate having no extension or v1 certificate? Generally all CA certificates must have extensions indicating that they are CAs, so they should have a version number of 3. Application certs on the other hand may vary depending on their content and anticipated usage. Cheers, Donal With Regards, Mayank [1]. http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html -Original Message- From: Mayank Mishra [mailto:[EMAIL PROTECTED] Sent: 26 February 2008 10:44 To: cxf-user@incubator.apache.org Subject: Usage of X509 certificates in WSS4J 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 server or otherwise, I observe Token Reference, the value of the Valuetype attribute in the KeyIdentifier element is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-prof ile-1.0#X509v3 AFAIK, In X.509 Certificate Token Profile 1.1, X509v1 certificates were included in the spec, in X509 Certificate Token Profile 1.0, only X509v3 certificates were there to be used. Also, AFAIK, WSS4J supports X.509 Certificate Token Profile 1.0. Please clarify me if I am wrong. Since, X509v3 certs have some more extension elements over X509v1. It should give some error, when passing X509v1 for cryptos creation. Or, it silently use X509v1, but then the valuetype should be #x509v1 instead of #x509v3. There is a bit of confusion. Kindly clarify. With Regards, Mayank IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Href attribute support in soap envelope body
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 of the array, but Java uses multiple JobParamsIn nodes (as you can see in my previous posting). If we look at the schema type definition in the WSDL xs:element maxOccurs=unbounded minOccurs=0 name=JobParamsIn type=xs:string/ it is Delphi that has incorrectly serialized the parameter and created an invalid SOAP request that would not pass validation which is disabled by default, right? Correct. That's definitely a Delphi issue as the soap message definitely does not match the schema.You will probably need to follow up with them to figure out how to get that to work properly. Dan Pierre Daniel Kulp wrote: 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; JobNameTestFromJava/JobName In the second case, JobName is unqualifed in that it doesn't have a namespace associated with it. Delphi is sending it out with the default namespace set so that JobName is qualified. There are two ways to approach how to get it working for you: 1) Research more in Delphi to figure out how to get it to send unqualified requests.Note: the ExecuteJob element SHOULD be qualified, but the children shouldn't. 2) Change the CXF server to expect it to be qualified. With 2.0.4, #2 isn't very hard. In the packages where your service is defined and where your java beans are defined, add a package-info.java that contains something like: @javax.xml.bind.annotation.XmlSchema( namespace = http://annuaire.ciss.lu;, elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED) package lu.ciss.annuaire; That should flip CXF to using qualified schemas. Dan On Tuesday 26 February 2008, pierre post wrote: 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 the Delphi doc). But the Web service call from Delphi always produces null values as incoming parameters in my Java Web service, without any exceptions or warnings on the CXF side. This is the request that Delphi sends now: ?xml version=1.0? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body ExecuteJob xmlns=http://annuaire.ciss.lu; JobNameTestFromDelphi/JobName JobParamsIn stringvalueDelphi1/string stringvalueDelphi2/string /JobParamsIn JobParamBean keykeyDelphi/key value2/value /JobParamBean /ExecuteJob /SOAP-ENV:Body /SOAP-ENV:Envelope The Java client (which still works correctly) sends the following request: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:ExecuteJob xmlns:ns1=http://annuaire.ciss.lu; JobNameTestFromJava/JobName JobParamsInvalueJava1/JobParamsIn JobParamsInvalueJava2/JobParamsIn JobParamBean keykeyJava/key value1/value /JobParamBean /ns1:ExecuteJob /soap:Body /soap:Envelope As there are some minor differences, is the request from Delphi incorrect / incompatible? If so, I will perhaps continue to investigate the issue on a Delphi forum resp. send a bug report to Codegear. Thanks in advance. Pierre Daniel Kulp wrote: SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:Body SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string SOAP-ENV:stringArray Umm... why would the string and stringArray things be in the SOAP-ENV namespace? That DEFINITELY looks bad. Looks like some more Delphi configuration is needed somehow. That said, you should definitely use a wrapped/doc/lit, not bare. So the message should look something like; SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema;
RE: Usage of X509 certificates in WSS4J
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 command line assume the cert is in PEM format (base 64 encoded), DER format is also supported (The Java language specific jks file format is not supported by openssl). (Aside: If you wanted to query certs programmatically then you could use the JDKs x.509 interface which gives you access to the extensions, and also to the version number of the certificate) The Email address data you refer to below appears to be just part of the distinguished name of both the Issuer and Subject. This by itself is not evidence of an x.509v43 extension being present. There is at least one defined X.509v3 extension that can be used for e-mail addresses (e.g. the emailAddress extension), but from the extract you have posted its not clear if this is specified in your cert. I suspect its unlikely base don what you have said so far. Anyway openssl will make this clear. If you are on Windows you could just download the pre built binaries executable from http://www.openssl.org/related/binaries.html I normally just build openssl myself, and haven't used that specific link personally - but it is listed on the main openssl.org webpage so hopefully should work. I could probably mail you a statically built version for one of the most popular Unix platforms if that's any use to you, and save you the hassle of building it.. Issuer: CN=dev, OU=mycompany, O=myorganization, L=mycity, ST=mystate, C=mycountry, [EMAIL PROTECTED] I guess, EMAILADDRESS, etc comes as v3 certificate extensions. Is there any way through which I can verify whether my certificate is v3 certificate having no extension or v1 certificate? Cheers, Donal -Original Message- From: Mayank Mishra [mailto:[EMAIL PROTECTED] Sent: 26 February 2008 14:10 To: cxf-user@incubator.apache.org Subject: Re: Usage of X509 certificates in WSS4J 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 nothing actually stopping somebody creating a certificate with no x.509v3 extensions, and also no issuerUniqueID or subjectUniqueID, ..and having a version of 3. A version of 1 would strictly be more correct though. Yes, I agree with you. I don't know offhand if Keytool gives you explicit control over the version number or whether it just calculates the version from the logical certificate request data when creating the certificate. I generated public key certificates and private keys from keytool only. According to [1], It generates v1 certificates and can import/export v1, v2, and v3 certificates.. But I am suspecting it because when while printing out the certificate, I get following along with SerialNumber, Certificate fingerprints. Owner: CN=dev, OU=mycompany, O=myorganization, L=mycity, ST=mystate, C=mycountry, [EMAIL PROTECTED] Issuer: CN=dev, OU=mycompany, O=myorganization, L=mycity, ST=mystate, C=mycountry, [EMAIL PROTECTED] I guess, EMAILADDRESS, etc comes as v3 certificate extensions. Is there any way through which I can verify whether my certificate is v3 certificate having no extension or v1 certificate? Generally all CA certificates must have extensions indicating that they are CAs, so they should have a version number of 3. Application certs on the other hand may vary depending on their content and anticipated usage. Cheers, Donal With Regards, Mayank [1]. http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html -Original Message- From: Mayank Mishra [mailto:[EMAIL PROTECTED] Sent: 26 February 2008 10:44 To: cxf-user@incubator.apache.org Subject: Usage of X509 certificates in WSS4J 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 server or otherwise, I observe Token Reference, the value of the Valuetype attribute in the KeyIdentifier element is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-prof ile-1.0#X509v3 AFAIK, In X.509 Certificate Token Profile 1.1, X509v1 certificates were included in the spec, in X509 Certificate Token Profile 1.0, only X509v3 certificates were there to be used. Also, AFAIK, WSS4J supports X.509 Certificate Token Profile 1.0. Please clarify me if I am wrong. Since, X509v3 certs have some more extension elements over X509v1. It should give some
Re: JAX-WS client proxy returning nulls
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 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 I've tried tweaking things based on the new stuff in the Aegis docs. I still haven't managed to solve the problem, though. The thing that was puzzling me is that the SOAP messages being sent/received seem to be correct. I assume this means that my service is configured correctly, and that I haven't set the client up to correctly interpret the response - but I've tried directing my client to use the Aegis databinding in a variety of ways and still seem to be getting this null problem. If I'm doing it incorrectly, does anyone have any code examples of how to do this? I can provide more details about my service/client configuration if that will help. Thanks again, Tony. Benson Margulies wrote: Tony, Please check out the current (newly modified) Aegis doc. Perhaps you have the 'AegisServiceConfiguration' enabled on the server side? On Tue, Feb 26, 2008 at 6:08 AM, Tony Burdett [EMAIL PROTECTED] wrote: 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 JaxWsProxyFactoryBean(); proxyFactory.getInInterceptors().add(new LoggingInInterceptor()); proxyFactory.getOutInterceptors().add(new LoggingOutInterceptor()); proxyFactory.setServiceClass(FluxionService.class); proxyFactory.setAddress(serviceURL); proxyFactory.setDataBinding(new AegisDatabinding()); FluxionService fs = (FluxionService)proxyFactory.create(); // SNIP Now, I should be able to do: SetURI uris = fs.getDataSources(); to retrieve a set of URIs from this service. When I make this call, I get the following SOAP request and response: Request: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:getDataSources xmlns:ns1=http://service.fluxion.comparagrid.org/; / /soap:Body /soap:Envelope Response: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body ns1:getDataSourcesResponse xmlns:ns1=http://service.fluxion.comparagrid.org/; return ns2:anyURI xmlns:ns2=http://impl.service.fluxion.comparagrid.org/; http://metagenome.ncl.ac.uk/cgdemo.owl /ns2:anyURI /return /ns1:getDataSourcesResponse /soap:Body /soap:Envelope That's exactly what I'd expect. However, the actual SetURI returned in my app is null, so I'm seeing NPEs whenever I try and iterate over this set. What's going on here? I'm relatively new to CXF as I've just ported over from XFire so I'm prepared to admit that I might be missing something fundamental but this looks pretty weird to me. Any advice would be highly appreciated as this is driving me mad! Thanks, Tony -- Tony Burdett Software Developer, ComparaGrid. European Bioinformatics Institute email: [EMAIL PROTECTED] tel: 01223 494624
Re: AW: Aegis DataBinding does not work
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 the slash. Most likely, the old docs produced some confusion
where the client was mapping/sending one form, but the server was
expecting the other form.
Dan
On Tuesday 26 February 2008, [EMAIL PROTECTED] wrote:
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 interface/impl used jax-ws annotations.
2- in my spring config used the latest changes as defined at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
On the client side;
1- in my client code used JaxWsProxyFactoryBean factory = new
JaxWsProxyFactoryBean(); 2- left the code as
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
Now it works H... ??? Any thoughts on this?
I am not sure if this work around is safe because I shall next attempt
using complex types (e.g. Vector) on the interface methods.
Cheers
Tezcan
-Ursprüngliche Nachricht-
Von: Benson Margulies [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 25. Februar 2008 14:17
An: Dilshener, Tezcan (ext.)
Betreff: Re: Aegis DataBinding does not work
Did you see my message to the list about AegisServiceConfiguration?
Please take that our of your spring config and try again.
On Mon, Feb 25, 2008 at 6:54 AM, [EMAIL PROTECTED]
wrote:
Hi Benson,
I saw your note on updated documentation.
I have corrected my spring-config accordingly but it did not
make
any difference. I am still receiving the following error
org.apache.cxf.interceptor.Fault: Message part
{http://pojo.spring.demo/}sayHi http://pojo.spring.demo/%7DsayHi
was not recognized.
Any more ideas?
1-) my cfx version is 2.0.4
2-) my client is trying to connect to server by using Aegis
Databinding as per example defined at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html ,
my service is HelloWorld example (without annotations) and
loaded
upon startup via the spring config defined at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
INFO: Outbound Message
---
Encoding: UTF-8
Headers: {Accept=[*], SOAPAction=[]}
Messages:
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodyns1
:sayHi
xmlns:ns1=http://pojo.spring.demo/;ns1:arg0Tex/ns1:arg0/ns1:say
Hi/soap:Body/soap:Envelope --
25.02.2008 12:49:26
org.apache.cxf.interceptor.LoggingInInterceptor
logging INFO: Inbound Message
Encoding: UTF-8
Headers: {Server=[WebSphere Application Server/6.1], Date=[Mon,
25
Feb 2008 11:49:25 GMT], transfer-encoding=[chunked],
Content-Language=[de-DE], connection=[Close], content-type=[text/xml;
charset=UTF-8]} Messages:
Message:
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodysoa
p:Faultfaultcodesoap:Client/faultcodefaultstringMessage part
{http://pojo.spring.demo/}sayHi http://pojo.spring.demo/%7DsayHi
was not
recognized./faultstring/soap:Fault/soap:Body/soap:Envelope
--
org.apache.cxf.binding.soap.SoapFault: Message part
{http://pojo.spring.demo/}sayHi http://pojo.spring.demo/%7DsayHi
was not recognized.
-Ursprüngliche Nachricht-
Von: Dilshener, Tezcan (ext.)
Gesendet: Montag, 25. Februar 2008 11:17
An: [EMAIL PROTECTED]; cxf-user@incubator.apache.org
Betreff: AW: Aegis DataBinding does not work
Hi
1-) my cfx version is 2.0.4
2-) my client is trying to connect to server by using Aegis
Databinding (as per
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html ), my
service is HelloWorld example (without annotations) and loaded upon
startup via the spring config defined at
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
http://cwiki.apache.org/CXF20DOC/aegis-databinding.html
and I think it is jax-ws.
So I am not sure what else I am doing wrong or i should do
further.
Cheers
Re: best practices for Map and List in webservices
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 to work, but it may require some extra
configuration to get the classes that you put into the list added to the
jaxb context and stuff. It also maps in to the schema as just an
xsd:anyType, which can sometimes cause issues with some stacks.
Maps, on the other hand, are really hard to get working (with JAXB).
You need to write special JavaTypeAdapters things to convert the maps
to/from special pair beans, and stuff. It basically requires quite a
bit more work at this point.
Dan
On Monday 25 February 2008, Daniel Lipofsky wrote:
I have got some WebServices that basically take and return
MapString,String and ListString. I am wondering what is
considered the best way to do this, especially for interoperability
with both Java and .NET. I don't have to use the Java collections
(although it sure is convenient). Previously we used WebMethods Glue
which provided this for us, but I understand it was not great for
interoperability.
Thanks,
Dan
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
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 java2wsdl tool has been merged into the new java2ws
tool which supports a bunch of new things. If you just want the wsdl,
pass the -wsdl flag.
Dan
We can consider 1.6.0_04. To be honest, we really need to compile with
a 1.5.x environment ideally since we probably need to support 1.5.x
JREs.
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 25 February 2008 17:08:00 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
Hmm..
Is this in maven or other build system? It looks like its picking up
some old jars someplace as the class:
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor
no longer even exists.
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
If using 2.1 snapshot, you may want to flip to 1.6.0_04. 03 includes
the 2.0 JAXWS/JAXB API's which may cause issues with the 2.1 versions
that CXF 2.1 requires._04 includes the proper 2.1 versions and I
have gone through and made sure CXF builds and runs with _04.
Dan
On Monday 25 February 2008, Phil Weighill-Smith wrote:
I've tried out the 2.1 snapshot available today and found that the
API has changed in some way in CXF so now trying to generate a WSDL
from Java code gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFact
or y.newBuilder()Lorg/apache/cxf/service/ServiceBuilder; at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceB
ui lder(JavaToProcessor.java:144) at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(Jav
aT oProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me
and I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should
be fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as
it will totally delegate to JAXB to generate the getUserResponse
type in the wsdl. Any chance you can try with the latest 2.1
snapshots (or wait till tomorrow/monday and try the ones I'll deploy
later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I
have a method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
Re: Problem generating WSDL from Java API with CXF 2.0.3
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: Problem generating WSDL from Java API with CXF 2.0.3
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 java2wsdl tool has been merged into the new java2ws
tool which supports a bunch of new things. If you just want the wsdl,
pass the -wsdl flag.
Dan
We can consider 1.6.0_04. To be honest, we really need to compile with
a 1.5.x environment ideally since we probably need to support 1.5.x
JREs.
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 25 February 2008 17:08:00 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
Hmm..
Is this in maven or other build system? It looks like its picking up
some old jars someplace as the class:
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor
no longer even exists.
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
If using 2.1 snapshot, you may want to flip to 1.6.0_04. 03 includes
the 2.0 JAXWS/JAXB API's which may cause issues with the 2.1 versions
that CXF 2.1 requires._04 includes the proper 2.1 versions and I
have gone through and made sure CXF builds and runs with _04.
Dan
On Monday 25 February 2008, Phil Weighill-Smith wrote:
I've tried out the 2.1 snapshot available today and found that the
API has changed in some way in CXF so now trying to generate a WSDL
from Java code gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFact
or y.newBuilder()Lorg/apache/cxf/service/ServiceBuilder; at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceB
ui lder(JavaToProcessor.java:144) at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(Jav
aT oProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me
and I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should
be fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as
it will totally delegate to JAXB to generate the getUserResponse
type in the wsdl. Any chance you can try with the latest 2.1
snapshots (or wait till tomorrow/monday and try the ones I'll deploy
later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I
have a method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
Re: Problem generating WSDL from Java API with CXF 2.0.3
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 (since 2.0.x is released). Dan - 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: Problem generating WSDL from Java API with CXF 2.0.3 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 java2wsdl tool has been merged into the new java2ws tool which supports a bunch of new things. If you just want the wsdl, pass the -wsdl flag. Dan -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
What jars files are not required on client side
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.
Re: What jars files are not required on client side
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 only required for Server side? Thanks. That list looks about correct. You may be able to ditch: geronimo-servlet_2.5_spec-1.1-M1.jar If you use Java6 up to update 3, you can ditch a couple more, but that isn't very tested well at this point.(CXF 2.1 will support update 4 and newer) I think there is a spring-all jar or similar that could be used instead of the individual spring jars. Not really sure though. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Does CXF Support Interfaces as Web Params?
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 to this context. Further investigation and digging through the
CXF code bought me to JAXBUtils. getValidClass(Class? cls) which is called
while building the JAXBContext. The code in JAXBUtils. getValidClass
explicitly excludes inclusion of any interfaces! I also tried setting the
XmlJavaTypeAdapter on the interface but that didn't work.
So, does CXF Support Interfaces as Web Params? I'd appreciate anyone
throwing some light on this!
Thanks
-ayush
Web Service Interface:
public interface TestServiceInterface {
public void testMethod(MyInterface param);
}
Parameter Interface:
public interface MyInterface{
String getText();
void setText(String t);
}
Parameter concrete class:
public class MyClass implements MyInterface {
private String text;
public String getText() {
return text;
}
public void setText(String t) {
this.text = t;
}
}
Client:
Service service = Service.create(SERVICE_NAME);
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
ENDPOINT_ADDRESS);
TestServiceInterface serviceInterface =
service.getPort(TestServiceInterface.class);
serviceInterface. testMethod(new MyClass());
java2wsdl yeilds WSDL file that causes NullPointerException
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 WSDL in the WAR file gives the following exception. Switching back to the handwritten WSDL makes it work fine. there are 2 things that might be contributing factors * I am using a mix of wrapper-style and non-wrapper style * My concrete impl classes inherit from an abstract impl class which contain most of the methods. The generated WSDL seems to contain a schema section for both with much repeating. Any ideas how to get this to work? 2008-02-26 15:16:58,400 ERROR [[/ws2]] - Servlet /ws2 threw load() exception java.lang.NullPointerException at org.apache.cxf.jaxws.support.JaxWsServiceConfiguration.getInParameterNam e(JaxWsServiceConfiguration.java:195) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.getInParamet erName(ReflectionServiceFactoryBean.java:1678) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.getInPartNam e(ReflectionServiceFactoryBean.java:1658) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializePa rameter(ReflectionServiceFactoryBean.java:586) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeCl assInfo(ReflectionServiceFactoryBean.java:563) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOpera tion(JaxWsServiceFactoryBean.java:165) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeWS DLOperations(ReflectionServiceFactoryBean.java:476) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOpera tions(JaxWsServiceFactoryBean.java:174) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildService FromWSDL(ReflectionServiceFactoryBean.java:274) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeSe rviceModel(ReflectionServiceFactoryBean.java:360) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(Refle ctionServiceFactoryBean.java:156) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsService FactoryBean.java:89) at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint( AbstractWSDLBasedEndpointFactory.java:74) at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java: 108) at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBea n.java:147) at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:299) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:230) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:181) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:352) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1240 ) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1205) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:425) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:156) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:248) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:160) at org.springframework.beans.factory.support.DefaultListableBeanFactory.pre InstantiateSingletons(DefaultListableBeanFactory.java:287) at org.springframework.context.support.AbstractApplicationContext.refresh(A bstractApplicationContext.java:352) at org.apache.cxf.transport.servlet.CXFServlet.loadAdditionalConfig(CXFServ let.java:145) at org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.jav a:113) at org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:63) at
RE: java2wsdl yeilds WSDL file that causes NullPointerException
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 by removing package-info.java and also BasePortType.java and BaseService.java which were hanging around from when I generated things for the abstract class; I also removed a reference to targetNamespace=.../Base.wsdl that was hanging around in WSException.java. Not sure what really did it.
Re: Does CXF Support Interfaces as Web Params?
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, 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 to this context. Further investigation and digging through the
CXF code bought me to JAXBUtils. getValidClass(Class? cls) which is called
while building the JAXBContext. The code in JAXBUtils. getValidClass
explicitly excludes inclusion of any interfaces! I also tried setting the
XmlJavaTypeAdapter on the interface but that didn't work.
So, does CXF Support Interfaces as Web Params? I'd appreciate anyone
throwing some light on this!
Thanks
-ayush
Web Service Interface:
public interface TestServiceInterface {
public void testMethod(MyInterface param);
}
Parameter Interface:
public interface MyInterface{
String getText();
void setText(String t);
}
Parameter concrete class:
public class MyClass implements MyInterface {
private String text;
public String getText() {
return text;
}
public void setText(String t) {
this.text = t;
}
}
Client:
Service service = Service.create(SERVICE_NAME);
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
ENDPOINT_ADDRESS);
TestServiceInterface serviceInterface =
service.getPort(TestServiceInterface.class);
serviceInterface. testMethod(new MyClass());
Re: Problem generating WSDL from Java API with CXF 2.0.3
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 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 (since 2.0.x is released). Dan - 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: Problem generating WSDL from Java API with CXF 2.0.3 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 java2wsdl tool has been merged into the new java2ws tool which supports a bunch of new things. If you just want the wsdl, pass the -wsdl flag. Dan
Re: Does CXF Support Interfaces as Web Params?
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 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, 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.ComplexObjectInterfaceis
not known to this context. Further investigation and digging through
the
CXF code bought me to JAXBUtils. getValidClass(Class? cls) which is
called
while building the JAXBContext. The code in JAXBUtils. getValidClass
explicitly excludes inclusion of any interfaces! I also tried setting
the
XmlJavaTypeAdapter on the interface but that didn't work.
So, does CXF Support Interfaces as Web Params? I'd appreciate anyone
throwing some light on this!
Thanks
-ayush
Web Service Interface:
public interface TestServiceInterface {
public void testMethod(MyInterface param);
}
Parameter Interface:
public interface MyInterface{
String getText();
void setText(String t);
}
Parameter concrete class:
public class MyClass implements MyInterface {
private String text;
public String getText() {
return text;
}
public void setText(String t) {
this.text = t;
}
}
Client:
Service service = Service.create(SERVICE_NAME);
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING,
ENDPOINT_ADDRESS);
TestServiceInterface serviceInterface =
service.getPort(TestServiceInterface.class);
serviceInterface. testMethod(new MyClass());
Re: Usage of X509 certificates in WSS4J
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 extensions rpesent. The above command line assume the cert is in PEM format (base 64 encoded), DER format is also supported (The Java language specific jks file format is not supported by openssl). (Aside: If you wanted to query certs programmatically then you could use the JDKs x.509 interface which gives you access to the extensions, and also to the version number of the certificate) I debugged MerlinCrypto instance created by WSS4J and checked the version number in the sun.security.x509.X509CertInfo instance. It has Version: v1 as CertificateVersion value. The Email address data you refer to below appears to be just part of the distinguished name of both the Issuer and Subject. This by itself is not evidence of an x.509v43 extension being present. There is at least one defined X.509v3 extension that can be used for e-mail addresses (e.g. the emailAddress extension), but from the extract you have posted its not clear if this is specified in your cert. I suspect its unlikely base don what you have said so far. Anyway openssl will make this clear. If you are on Windows you could just download the pre built binaries executable from http://www.openssl.org/related/binaries.html I normally just build openssl myself, and haven't used that specific link personally - but it is listed on the main openssl.org webpage so hopefully should work. Thanks Arundel for the link. I used the pre built binaries from the URL. I followed the following, 1. Exported the certificate to .CER format from the keytool -export command. 2. Converted CER format to PEM format using openssl command x509 -inform der -in MYCERT.cer -out MYCERT.pem 3. Checked the version using openssl command x509 -in MYCERT.pem -inform PEM -text I saw following information along with Validity, Subject, Subject Public Key Info and Certificate: Certificate: Data: Version: 1 (0x0) Serial Number: 1173183211 (0x45ed5aeb) Signature Algorithm: md5WithRSAEncryption I guess I can confirm seeing above that the certificates I am using are of version v1. Also, no extension information was there. Hence, in this case the certificates I am passing to WSS4J are x509v1, and the expected valueType must be #x509v1. In case I am right, WSS4J supports OASIS X.509 Certificate Token Profile 1.0 [1]. IMO, the only differences in 1.0 and OASIS X.509 Certificate Token Profile 1.1 [2] are following: 1. Inclusion of X.509 version 1 certificates (I dont' know the reason of going back). 2. Allowing only X.509 version 3 certificates to be used in Key Identifier reference. We can change the above and can support Token Profile 1.1. With Regards, Mayank [1]. http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf [2]. http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-x509TokenProfile.pdf I could probably mail you a statically built version for one of the most popular Unix platforms if that's any use to you, and save you the hassle of building it.. Issuer: CN=dev, OU=mycompany, O=myorganization, L=mycity, ST=mystate, C=mycountry, [EMAIL PROTECTED] I guess, EMAILADDRESS, etc comes as v3 certificate extensions. Is there any way through which I can verify whether my certificate is v3 certificate having no extension or v1 certificate? Cheers, Donal -Original Message- From: Mayank Mishra [mailto:[EMAIL PROTECTED] Sent: 26 February 2008 14:10 To: cxf-user@incubator.apache.org Subject: Re: Usage of X509 certificates in WSS4J 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 nothing actually stopping somebody creating a certificate with no x.509v3 extensions, and also no issuerUniqueID or subjectUniqueID, ..and having a version of 3. A version of 1 would strictly be more correct though. Yes, I agree with you. I don't know offhand if Keytool gives you explicit control over the version number or whether it just calculates the version from the logical certificate request data when creating the certificate. I generated public key certificates and private keys from keytool only. According to [1], It generates v1 certificates and can import/export v1, v2, and v3 certificates.. But I am suspecting it because when while printing out the certificate, I get following along with SerialNumber, Certificate fingerprints. Owner: CN=dev, OU=mycompany, O=myorganization, L=mycity, ST=mystate, C=mycountry,
Re: mutithread issues in interceptors and endpoints
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 way to use the
org.apache.cxf.service.invoker.LocalFactory with a RequestScopePolicy
thing to have it create a new instance of each request. Maybe. I'm
not really sure if any of that is working and it's all very confusing.
I'm tempted to rip that all out and just have a couple different
factories. (SingleInstanceFactory, PerRequestFactory, SessionFactory,
PooledFactory, etc...)
I have tried the following code, and actually it works fine, it creates a
new endpoint bean instance for each request.
ScopePolicy policy = RequestScopePolicy.instance();
org.apache.cxf.common.util.factory.Factory factory = new
LocalFactory(GreeterImpl.class);
JAXWSMethodInvoker invoker = new JAXWSMethodInvoker(fattorazza, policy);
JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
factoryBean.setAddress(address);
factoryBean.setServiceBean(implementor);
factoryBean.setInvoker(invoker);
factoryBean.create();
Endpoint.publish(address, implementor);
Just a note on the RequestScopePolicy: it seem to be a singleton, but the
constructor is not private, so the singletor factory can be violated, here
is the code.
public class RequestScopePolicy implements ScopePolicy {
private static final RequestScopePolicy SINGLETON = new
RequestScopePolicy();
public Factory applyScope(Factory f, Exchange ex) {
return f;
}
public static ScopePolicy instance() {
return SINGLETON;
}
}
--
View this message in context:
http://www.nabble.com/mutithread-issues-in-interceptors-and-endpoints-tp15611836p15707562.html
Sent from the cxf-user mailing list archive at Nabble.com.
