Building cxf
I just downloaded the 2.04 sources. Trying to compile I get this error: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/alleon/Documents/apache-cxf-2.0.4-incubator-src/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WSDL2JavaMojo.java:[37,33] package org.apache.maven.artifact does not exist /Users/alleon/Documents/apache-cxf-2.0.4-incubator-src/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WSDL2JavaMojo.java:[169,13] cannot find symbol symbol : class Artifact location: class org.apache.cxf.maven_plugin.WSDL2JavaMojo /Users/alleon/Documents/apache-cxf-2.0.4-incubator-src/maven-plugins/codegen-plugin/src/main/java/org/apache/cxf/maven_plugin/WSDL2JavaMojo.java:[169,52] cannot find symbol symbol : class Artifact location: class org.apache.cxf.maven_plugin.WSDL2JavaMojo Any idea on what I might be doing wrong ? I am running on a MacOS 10.4 machine -- Best Regards Guillaume PGP KeyID:C1A0A73F FingerPrint:A4A2 73C0 E7D4 6437 8185 D05E ECF2 AD84 C1A0 A73F http://cheztog.blogspot.com
Re: Usage of X509 certificates in WSS4J
Mayank Mishra wrote: 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 or atleast we can check certificate version and can put right value as "#x509v1" of 'ValueType' attribute in Key Identifier reference. With Regards, Mayank 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 printi
Re: Does CXF Support Interfaces as Web Params?
On Wednesday 27 February 2008, Ayush Gupta wrote:
> Yes, I've used JAXB with interfaces and its painful but does work.
>
> However, it appears from the code in JAXBUtils that CXF explicitly
> excludes interfaces even if they are annotated to be properly
> marshaled by JAXB (as per
> https://jaxb.dev.java.net/guide/Mapping_interfaces.html)
Actually, that code IS correct. I've been experimenting with this quite
a bit tonight and JAXB will barf if you try to create a context with any
class that is an interface, even if the interface has the
XmlJavaTypeAdapter annotation on it and such. Thus, that code is
correct. However, this also means that you cannot use interfaces
for "top level" things, only for stuff within actual concrete beans.
That said, I was pleasantly suprised when I wrote my test case that the
test actually worked with whats on the trunk today PROVIDING you have a
valid version of asm jar available AND you use wrapped doc/lit. With
the work I did two weeks ago, in the wrapped doc/lit case, it will use
ASM to buildup concrete beans in memory and the interface params get put
over just fine and they work. (This is on the 2.1 line only. Way to
complex to port back to 2.0.x.)
If you AREN'T using wrapped doc/lit or you don't have an asm jar
available, then there are issues. We have to drop down to JAXB
proprietary API's and types to get them to work. That's not going to
be easy and due to the extra book keeping, is going to be a performance
issue.In general, I strongly suggest the wrapped doc/lit with asm.
In anycase, I'm adding a sample of this to the java_first_jaxws sample to
kind of show it working. I'll start a new snapshot deploy before I
head to bed tonight so the 2.1 snapshots in the morning should have it.
I'd really appreciate it if folks could look at it and let me know how
to improve the sample to show some more of these complex scenarios. I
do admit most of our samples are very basic. This should be a step in
the right direction for providing something a bit more complex.
Dan
>
>
> -Original Message-
> From: jim ma [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 26, 2008 9:18 PM
> To: cxf-user@incubator.apache.org
> Subject: 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.h
>tml
>
> 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());
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: java2wsdl yeilds WSDL file that causes NullPointerException
Am Mittwoch, den 27.02.2008, 16:27 -0500 schrieb Daniel Kulp: > On Tuesday 26 February 2008, Daniel Lipofsky wrote: > > OK, I solved this original problem but I have more questions: > > > > How do you control the soap location. > > Right now it is outputing > > http://localhost:9090/hello"/> > > which is not correct. > > Hmm I don't see a way to do it with the 2.0.x java2wsdl tooling. > With the 2.1 tooling, there is a "-address" flag that looks like it > would be for that pupose. > > > > Also, can I override this programmatically in the client? > > That's the easy part. > ((BindingProvider)proxy).getRequestContext().put( > BindingProvider.ENDPOINT_ADDRESS_PROPERTY, > "http://blah/blah/blah";); > Part 7 of [1] gives a fuller example if it would help you. Glen [1] http://www.jroller.com/gmazza/entry/using_the_ebay_shopping_api1
Re: set Default minOccurs and nillable Parameters
Can this be done using JAXB? These nillable attributes are the bane of my existence... Is there anyway to make them go away? On Tue, Feb 5, 2008 at 1:12 PM, Benson Margulies <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-02-05 at 07:55 -0800, yulinxp wrote: > > This section explains how to set Default minOccurs and nillable > Parameters > > using Java API. > > Is there anyway we could do it through xml file? > > > > http://cwiki.apache.org/CXF20DOC/aegis-databinding.html > > > > Start from here, and add a Configuration bean to the AegisDatabinding. > > serviceClass=" > org.apache.cxf.javascript.fortest.AegisService" >address="http://localhost:8808/aegis";> > >class=" > org.apache.cxf.javascript.fortest.AegisServiceImpl" /> > > >class=" > org.apache.cxf.aegis.databinding.AegisDatabinding"> > > > >class=' > org.apache.cxf.service.factory.ReflectionServiceFactoryBean'> > > > key="overrideTypesList"> > > > org.apache.cxf.javascript.fortest.aegis.Mammal > > > > > > > > >
upgrading from XFire - SSL handshake errors
Have the default cipher suites changed between XFire and CXF?
The reason I ask is that I am in the process of upgrading a XFire client to
CXF. The XFire client successfully uses a SOAP service over HTTPS. I didn't
do anything particular to get XFire working over HTTPS so presumably the
default cipher suites were used.
My first attempt at connecting to the same endpoint via my new CXF client
resulted in the following SSL handshake_failure:
INFO: The cipher suites have been set to 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_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
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.
%% No cached client session
*** ClientHello, SSLv3
RandomCookie: GMT: 1187298740 bytes = { 113, 45, 193, 158, 214, 231, 11,
225, 197, 38, 3, 179, 175, 26, 25, 234, 108, 241, 155, 106, 191, 62, 221,
65, 209, 8, 182, 48 }
Session ID: {}
Cipher Suites: [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_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
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]
Compression Methods: { 0 }
***
WRITE: SSLv3 Handshake, length = 79
WRITE: SSLv2 client hello message, length = 101
READ: SSLv3 Alert, length = 2
RECV TLSv1 ALERT: fatal, handshake_failure
called closeSocket()
handling exception: javax.net.ssl.SSLHandshakeException: Received fatal
alert: handshake_failure
Feb 27, 2008 2:49:08 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Error writing to XMLStreamWriter.
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:136)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
at $Proxy48.localAuthenticationQuery(Unknown Source) ...
Caused by: javax.xml.stream.XMLStreamException
at
com.sun.xml.stream.writers.XMLStreamWriterImpl.writeStartElement(XMLStreamWriterImpl.java:1210)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:95)
... 16 more
After googling around for "SSLv3 Alert, length = 2" I found that this can
occur when the server rejects the cipher suites given in the ClientHello
message. By running the working XFire client with
"-Djavax.net.debug=ssl,handshake" enabled I learned that the server was
choosing SSL_RSA_WITH_3DES_EDE_CBC_SHA as the cipher suite. Sure enough
this cipher suite isn't in the default cipher suites thay my CXF client was
picking up (list is above). Adding this to my CXF client resolved the
handshake issue:
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.getCipherSuites().add("SSL_RSA_WITH_3DES_EDE_CBC_SHA");
conduit.setTlsClientParameters(tlsParams);
I'm all set now but this got me thinking about how my upgrade could have
been made much smoother had the default cipher suites remained the same. But
perhaps there is a good reason why they differ?
thanks,
-Travis
--
View this message in context:
http://www.nabble.com/upgrading-from-XFire---SSL-handshake-errors-tp15725238p15725238.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem generating WSDL from Java API with CXF 2.0.3
This looks exactly like the issue in:
http://www.nabble.com/Does-CXF-Support-Interfaces-as-Web-Params--to15702272.html
I'll look at it more tonight or tomorrow.
Dan
On Wednesday 27 February 2008, Phil Weighill-Smith wrote:
> Dan,
>
> So we managed to get the new tool running, but we still have the same
> problem. I've attached the full actual WSDL generated.
>
> This is generated using the following snippet of Ant scripting:
>
>
> depends="-make-output-dir"> classname="org.apache.cxf.tools.java2ws.JavaToWS" fork="true"> value="-wsdl"/>
>
> value="${product.dir}/user-module/built/output/generated"/> value="-o"/>
> value="${product.dir}/user-module/built/output/UserModule.wsdl"/>
> value="com.volantis.openapi.mss.usermodule.UserModule"/>
>
>
>
>
>
>
> When executed we get the following output from Ant:
>
>
> generate-remote-java2wsdl:
> [java] log4j:WARN No appenders could be found for logger
> (org.apache.cxf.bus.spring.BusApplicationContext). [java] log4j:WARN
> Please initialize the log4j system properly. [java] Feb 27, 2008
> 2:06:35 PM org.apache.cxf.bus.spring.BusApplicationContext
> getConfigResources [java] INFO: No cxf.xml configuration file
> detected, relying on defaults. [java] Feb 27, 2008 2:06:37 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass [java] INFO: Creating Service
> {http://com.volantis.xmlns/2008/01/mss/user-module}UserModuleService
> from class com.volantis.openapi.mss.usermodule.UserModule [java] Feb
> 27, 2008 2:06:38 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass [java] INFO:
> {http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
> type QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}parameter part type
> QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
> type QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}return part type
> QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}return part type
> QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}definition part
> type QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}parameter part type
> QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}return part type
> QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}return part type
> QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
> type QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}return part type
> QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}preference part
> type QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}originalPreference
> part type QName null. [java]
> {http://com.volantis.xmlns/2008/01/mss/user-module}parameters part
> type QName null.
>
> I'm wondering if the QName null issues are the source of our problems,
> and what they mean.
>
> Here is the start of our SEI (with the first operation/method
> included):
>
>
> package com.volantis.openapi.mss.usermodule;
>
> import com.volantis.openapi.mss.usermodule.jaxb.Adapters;
>
> import java.util.List;
>
> import javax.jws.WebParam;
> import javax.jws.WebService;
> import javax.jws.soap.SOAPBinding;
> import javax.xml.datatype.Duration;
> import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
>
> /**
> * Provides access to the various operations that can be performed
> against the * user module which forms part of the MSS API.
> *
> * ...
> */
> @WebService(name = "UserModule",
> targetNamespace =
> "http://com.volantis.xmlns/2008/01/mss/user-module";)
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
> use = SOAPBinding.Use.LITERAL,
> parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
> public interface UserModule {
> /**
> * Get the details of the specified user, with or without
> extension * parameter and subscription details and potentially
> updating the user's * last known device.
> *
> * @param applicationID the ID for the application
> scope in * which the user exists.
> Must not be * null
> * @param userID the application-scope unique
> ID for * the user to be retrieved.
> Must not be * null
> * @param device the DRWS device name for the
> request * during which the user's
> details are * to be retrieved. If
> not null this may * be used to
> update the user's last * known
> device
> * @param includeExtension
Re: Does CXF Support Interfaces as Web Params?
On Wednesday 27 February 2008, Ayush Gupta wrote:
> Yes, I've used JAXB with interfaces and its painful but does work.
>
> However, it appears from the code in JAXBUtils that CXF explicitly
> excludes interfaces even if they are annotated to be properly
> marshaled by JAXB (as per
> https://jaxb.dev.java.net/guide/Mapping_interfaces.html)
Fixable I'll try to get that fixed tomorrow. :-)
Dan
>
> -Original Message-
> From: jim ma [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 26, 2008 9:18 PM
> To: cxf-user@incubator.apache.org
> Subject: 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.h
>tml
>
> 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());
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: java2wsdl yeilds WSDL file that causes NullPointerException
On Tuesday 26 February 2008, Daniel Lipofsky wrote: > OK, I solved this original problem but I have more questions: > > How do you control the soap location. > Right now it is outputing > http://localhost:9090/hello"/> > which is not correct. Hmm I don't see a way to do it with the 2.0.x java2wsdl tooling. With the 2.1 tooling, there is a "-address" flag that looks like it would be for that pupose. > Also, can I override this programmatically in the client? That's the easy part. ((BindingProvider)proxy).getRequestContext().put( BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://blah/blah/blah";); Dan > > 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. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
CXF problem using extended class as Web Param
Hi all,
I'm implementing an unwrapped REST web service using HTTP Binding, deployed
on JBoss, using Spring.
In a specific method I need to use a class that's extending other as a web
parameter. Lets say:
The web service:
@Post
@HttpResource(location="/auth")
public String authenticate(@WebParam(name="AuthRequest") AuthRequest
request);
AuthRequest:
public class AuthRequest extends GenericRequest{
final static long serialVersionUID = 1L;
public AuthRequest() {
super();
}
public AuthRequest(Integer applicationId, String password, String
login) {
super(applicationId, password, login);
}
And GenericRequest..
public class GenericRequest implements Serializable {
public GenericRequest(){
}
public GenericRequest(Integer applicationId, String password, String
login)
{
super();
this.applicationId = applicationId;
this.password = password;
this.login = login;
}
private static final long serialVersionUID = 5037815176301473091L;
private Integer applicationId;
private String password;
private String login;
... and further setters and getters...
Wasn't this supposed to work??
I'm getting the following exception instead:
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.binding.http.IriDecoderHelper.interopolateParams(IriDecoderHelper.java:306)
at
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.mergeParams(URIParameterInInterceptor.java:122)
at
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.handleMessage(URIParameterInInterceptor.java:103)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
(...)
Thanks in advance,
Rui Ramos
--
View this message in context:
http://www.nabble.com/CXF-problem-using-extended-class-as-Web-Param-tp15721500p15721500.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Does CXF Support Interfaces as Web Params?
Yes, I've used JAXB with interfaces and its painful but does work.
However, it appears from the code in JAXBUtils that CXF explicitly excludes
interfaces even if they are annotated to be properly marshaled by JAXB (as
per https://jaxb.dev.java.net/guide/Mapping_interfaces.html)
-Original Message-
From: jim ma [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 9:18 PM
To: cxf-user@incubator.apache.org
Subject: 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: CXF Proxy and WS-Security
Daniel Kulp wrote: On Tuesday 26 February 2008, Will Gomes wrote: Is it possible with CXF to use single Proxy and be able to set the user for UsernameToken before each invocation and be thread safe? All examples I've seen so far sets the user on the interceptor once per proxy. Can I specify callback for username, similar to the password? Unforunately, at this point, the answer is no due to spec compliance issues.You can read some of the discussion about it in JIRA: https://issues.apache.org/jira/browse/CXF-1410 We're kind of debating which direction to go: 1) A separate proprietary "getThreadRequestContext()" call on a proprietary interface. 2) A flag that would somehow flip the getRequestContext() call over to a thread safe variety. In either case, the behavoir would be proprietary to CXF as the spec (and TCK) more or less requires the non-thread safe behavior to be the default. :-( I'd be interesting in hearing your opinions on the matter. Second solution seems more portable. Could the WSS4JOutInterceptor be made to make a callback to a UsernameCallbackHandler to retreive the username and add to the message context? I assume the message is thread safe when in the InterceptorChain. Also, i'm not sure the purpose of having a password callback (aside from keeping passwords out of config/code) if there is no associated username callback handler.
Re: CXF Proxy and WS-Security
On Tuesday 26 February 2008, Will Gomes wrote: > Is it possible with CXF to use single Proxy and be able to set the > user for UsernameToken before each invocation and be thread safe? All > examples I've seen so far sets the user on the interceptor once per > proxy. Can I specify callback for username, similar to the password? Unforunately, at this point, the answer is no due to spec compliance issues.You can read some of the discussion about it in JIRA: https://issues.apache.org/jira/browse/CXF-1410 We're kind of debating which direction to go: 1) A separate proprietary "getThreadRequestContext()" call on a proprietary interface. 2) A flag that would somehow flip the getRequestContext() call over to a thread safe variety. In either case, the behavoir would be proprietary to CXF as the spec (and TCK) more or less requires the non-thread safe behavior to be the default. :-( I'd be interesting in hearing your opinions on the matter. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: WebServiceContext Principal
On Wednesday 27 February 2008, Davide Gesino wrote: > According to the javadoc of WebServiceContext class, > > > getUserPrincipal() Returns the Principal that identifies the sender of > the request currently being serviced. If the sender has not been > authenticated, the method returns null. > > how is supposed to be filled this Principal? > When? > By whom? Well, that's kind of application specific. When running inside a servlet engine and using the CXFServlet, the CXFServlet provides an implementation that makes the getUserPrincipal() call back onto the same method of the current HttpServletRequest. Thus, it's filled in by tomcat from the information tomcat knows about. (like tomcat-users.xml in the tomcat conf directory along with information in the web.xml) HOWEVER, if you have some sort of custom CXF interceptor, you can create your own org.apache.cxf.security.SecurityContext object that does whatever custom thing you need and set that in the message and then the calls to the WebServiceContext getUserPrincipal stuff will go through that. Ideally, the ws-security stuff would also set a new SecurityContext or similar with the information it has. I'm not sure if it has a principal or role information right now or not. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: WebServiceContext not injected in endpoint
This is one of the many issues with the ScopePolicy/factory stuff which
is one of the reasons I eliminated the ScopePolicy stuff entirely from
the 2.1/trunk codebase. :-)
Is there any chance you could give the 2.1 snapshots a try? Configuring
your usecase will be SLIGHTLY different, but not by much:
org.apache.cxf.service.invoker.Factory factory = new
org.apache.cxf.service.invoker.PerRequestFactory(GreeterImpl.class);
JAXWSMethodInvoker invoker = new JAXWSMethodInvoker(factory);
.
The newer Factory stuff, since it has access to the exchange at request
time, can get the bus and thus get the resources properly injected.
That said, the resource injection isn't "free" so that will add a small
amount of extra processing per request. Thus, you might want to use
the PooledFactory to maintain a pool of GreeterImpl objects or possibly
a SessionFactory to create one per session (assuming your clients honor
the session).
In anycase, with the 2.1 code the major bugs should be fixed and I'd LOVE
to see someone else test it a bit to makre sure. Basically, resources
should get injected and the pooled stuff should actually work.
Dan
On Wednesday 27 February 2008, Davide Gesino wrote:
> trying customizing the JAxWSMethodInvoker I have problems injecting
> the web service context with the @Resource annotation.
> Maybe there's something wrong in what I am doing, maybe it could be a
> bug.
>
> Assume you have a GreeterImpl endpoint with the web service context
> injected.
>
> Try the following:
>
> case 1
> ScopePolicy policy = ApplicationScopePolicy.instance();
> // trying with the following is the same:
> // 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();
>
> case 2
> Endpoint.publish(address,implementor);
>
> the endpoint
> public class GreeterImpl implements Greeter {
>
> @Resource
> private WebServiceContext context;
>
> public java.lang.String greetMe(java.lang.String requestType) {
>
>
> if (context != null) {
> // in case 1 it is null, in case 2 it is !=null
> }
>
>
> return "hello "+ requestType;
> }
>
> in case 1 the method invocation works fine, but the context is not
> injected, while in case 2 the context is injected.
>
> where is the fault?
>
> Davide
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: maintain'g session problem
Thank u, it is working for me . -- Sent using goWebtop from Laszlo Systems. Try it yourself : http://www.gowebtop.com On Wed, Feb 27, 2008 at 5:55 PM, Ian Roberts wrote: prakesh kt wrote: when ever i am trying to get the values from the session it is giving null values.because it is creating the new session for every request. please help me to avoid this. I know in axis we can give maintainsession(true) to avoid this. ((BindingProvider)clientStub).getRequestContext().put( BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE); I got this from a Metro blog entry but it's a JAX-WS thing, not specific to Metro, and it works for me with CXF. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: maintain'g session problem
prakesh kt wrote: when ever i am trying to get the values from the session it is giving null values.because it is creating the new session for every request. please help me to avoid this. I know in axis we can give maintainsession(true) to avoid this. ((BindingProvider)clientStub).getRequestContext().put( BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE); I got this from a Metro blog entry but it's a JAX-WS thing, not specific to Metro, and it works for me with CXF. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
maintain'g session problem
Hi ,
I am new to cxf . My services are successfully exposed and i wrote
the client stubs to communicate with my services .currently i am stuck
up with one problem and i am looking for some pointers on this.
I would like check the authentication of the user before using my
services. I have list of valid user details in my db.
whenever User trying to use my services , I want to check the
authentication. for this purpuse i am calling a method internally when
ever the user invoke my service and binding the username &password and
setting it in to the httpSession (please refer the below code). i hope
that now u understand the problem, when ever i am trying to get the
values from the session it is giving null values.because it is creating
the new session for every request. please help me to avoid this. I know
in axis we can give maintainsession(true) to avoid this.
(IN my Serviceimpl class)
@Resource
WebServiceContext wsc;
@WebMethod
public void isValidUser(String username, String password) {
MessageContext context=wsc.getMessageContext();
HttpServletRequest
request=(HttpServletRequest)context.get(MessageContext.SERVLET_REQUEST);
/*
here i am calling some method to check the authentication and
after puting some flag value in session.
*/
}
@WebMethod
public void getMySerivce(String str){
HttpServletRequest
request=(HttpServletRequest)wsc.getMessageContext().get(MessageContext.SERVLET_REQUEST);
boolean value=request.getSession().getAttribute("MYFLAG");//
getting null. because here i am getting new session instance.
}
thanks,
prakeshkt
CXF Proxy and WS-Security
Is it possible with CXF to use single Proxy and be able to set the user for UsernameToken before each invocation and be thread safe? All examples I've seen so far sets the user on the interceptor once per proxy. Can I specify callback for username, similar to the password?
WebServiceContext Principal
According to the javadoc of WebServiceContext class, getUserPrincipal() Returns the Principal that identifies the sender of the request currently being serviced. If the sender has not been authenticated, the method returns null. how is supposed to be filled this Principal? When? By whom? -- View this message in context: http://www.nabble.com/WebServiceContext-Principal-tp15708867p15708867.html Sent from the cxf-user mailing list archive at Nabble.com.
WebServiceContext not injected in endpoint
trying customizing the JAxWSMethodInvoker I have problems injecting the web
service context with the @Resource annotation.
Maybe there's something wrong in what I am doing, maybe it could be a bug.
Assume you have a GreeterImpl endpoint with the web service context
injected.
Try the following:
case 1
ScopePolicy policy = ApplicationScopePolicy.instance();
// trying with the following is the same:
// 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();
case 2
Endpoint.publish(address,implementor);
the endpoint
public class GreeterImpl implements Greeter {
@Resource
private WebServiceContext context;
public java.lang.String greetMe(java.lang.String requestType) {
if (context != null) {
// in case 1 it is null, in case 2 it is !=null
}
return "hello "+ requestType;
}
in case 1 the method invocation works fine, but the context is not injected,
while in case 2 the context is injected.
where is the fault?
Davide
--
View this message in context:
http://www.nabble.com/WebServiceContext-not-injected-in-endpoint-tp15708465p15708465.html
Sent from the cxf-user mailing list archive at Nabble.com.
