Re: Improving JBossWS-CXF Client Side Integration
OK, will do ;)
Richard
Daniel Kulp wrote:
On Mon June 15 2009 9:39:51 am Richard Opalka wrote:
What's the current status of this issue Daniel?
Should I create JIRA issue or is there already one?
Create a JIRA (and attach a patch ;-) )!
Dan
Richard
Richard Opalka wrote:
Hi CXF Folks,
see in lined comments below:
Daniel Kulp wrote:
On Wed June 3 2009 3:18:36 pm Jeff Genender wrote:
I actually prefer the injection/override of an implementation via a
property...
This is quite common (see the XML parser, JACC, etc) and sounds like
it could lend itself very well to what is trying to be done here.
Just because its quite common doesn't mean it works well. :-)
For example: the META-INF/services thing really does NOT work well in
an OSGi environment. The ServiceMix folks have to have separate
api jars for everything that uses the META-INF/services stuff that
use a different lookup mechanism.
Plus, the whole META-INF/services thing really depends on classpath
ordering and such which users never seem to get right. If CXF is
first, it would use CXF's and the JBoss customizations wouldn't
trigger. If JBoss's is first, they would.
This is exactly the reason why I don't like META-INF/services
suggested fix. We have many
complaining users on our forums about Stack XYZ doesn't work. Many
times its because
their IDE isn't configured properly. Users would need to take care
also about classpath ordering
if we would go this way.
That said, the listener thing Richard proposed has some additional
benefits as well when integrating into other containers such as
ServiceMix or Camel.
Dan
Jeff
On Jun 3, 2009, at 1:13 PM, Daniel Kulp wrote:
Richard,
Modifying the generated code is not a doable solution. That would
tie them
to CXF which would then violate the JAX-WS spec and TCK and such.
Thus,
that's not an option.
However, you could be on the right track. In our ServiceImpl, all
the
getPort calls forward into the protected createPort method (line
384 of
ServiceImpl).We COULD put your call to the listener in there.
The better option would be to push it even furthur into CXF and put
it into
the JaxWsProxyFactoryBean/ClientProxyFactoryBean.create() call.
That way,
if they end up using the spring jaxws:client call or use the
factories
directly themselves, the listeners would be invoked as well.
Dan
On Wed June 3 2009 2:11:22 am Richard Opalka wrote:
Hi Daniel,
Yes, I know about solution 1) you suggested. However I don't like
it.
It's hacky and could cause a lot of troubles to our customers.
Thus I'd like to go the way to modify CXF code base.
Before I'll write my suggestion let me clarify that we don't need
to
wrap your ServiceDelegate. We just need to register properties
on the proxy and that can be achieved using listener approach.
So here are my thoughts how it could be achieved in another way (no
delegation):
---
ad1)
---
// CXF provides listener interface
package org.apache.cxf.jaxws;
public interface ServiceListener
{
void onPortCreated(T proxy, ClassT sei);
}
---
ad2)
---
// JBossWS provides listener implementation
package org.jboss.wsf.stack.cxf.client;
public class ServiceListenerImpl implements ServiceListener
{
public void onPortCreated(T proxy, ClassT sei)
{
// ... our integration code
}
}
---
ad3)
---
// JBossWS somehow registers the listener
---
ad4)
---
// finally replace the following code in
org.apache.cxf.jaxws.ServiceImpl.createPort(...)
protected T T createPort(QName portName, EndpointReferenceType epr,
ClassT serviceEndpointInterface, WebServiceFeature... features)
{
// ...
return serviceEndpointInterface.cast(obj);
}
// with the following code:
protected T T createPort(QName portName, EndpointReferenceType epr,
ClassT serviceEndpointInterface, WebServiceFeature... features)
{
// ...
T proxy = serviceEndpointInterface.cast(obj);
for (ServiceListener listener : listeners)
{
listener.onPortCreated(proxy, serviceEndpointInterface);
}
return proxy;
}
If you like this approach then let's disscuss how ad3) could be
achieved, i.e. how to register the listener on the service.
Cheers,
Richard
Daniel Kulp wrote:
Well, couple things spring to mind:
Option 1: requires no changes to CXF, but requires some
classloader magic
on your side
Write your own javax.xml.ws.spi.Provider that probably subclasses
ours
and overrides the method:
@Override
public ServiceDelegate createServiceDelegate(URL url, QName
qname,
Class cls) {
Bus bus = BusFactory.getThreadDefaultBus();
return new ServiceImpl(bus, url, qname, cls);
}
In your case, return a subclass of our ServiceImpl the does your
additional stuff. That way, any cast we may do to ServiceImpl
would
still work (not sure if we do it anywhere, but just in case).
That way,
you won't really have an extra delegation layer.
DOSGi builds failing with a missing abdera artifact
Hi all, The CXF DOSGi builds have started failing this morning with the message below. Previously they were building fine. Does anyone know what happened to the abera 0.4.0-incubating dependencies which come in via the cxf-minimal bundle? See: http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/ Cheers, David 1) org.apache.abdera:abdera-core:jar:0.4.0-incubating Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.abdera -DartifactId=abdera-core -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.abdera -DartifactId=abdera-core -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.cxf.dosgi:cxf-dosgi-ri-dsw-cxf:bundle:1.1-SNAPSHOT 2) org.apache.cxf:cxf-bundle-minimal:jar:2.2.3-SNAPSHOT 3) org.apache.abdera:abdera-core:jar:0.4.0-incubating
CXF WS-security Signing not working - javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
Hello, I am getting the exception
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI when
implementing signature secruity with WS-Security in CXF. What does this
mean? Anyone have any insights on what I can do to resolve this issue?
Honestly, I don't remember this being so difficult to implement in older CXF
and I don't think I have ever seen this error before. I tried to to google
it a lot today and by the looks of it, not many other people have seen this
before either. I am on version 2.2 now.
Could anyone please describe to me what this error means? What process do I
need to resolve it? P.S. The web service works fine without the
interceptors when I don't try and use WS-security. I followed the
WS-Security instructions listed here:
http://cwiki.apache.org/CXF20DOC/ws-security.html
That is, I generated a keystore for my server side, generated a public key
for my client. Imported the public key for my client into the keystore.
Any assistance anyone can give me in regards to resolving this issue is
greatly appreciated.
Below is the whole message and exception, including the SOAP exchange and
stuff.:
log4j:WARN No appenders could be found for logger
(org.apache.cxf.bus.spring.BusApplicationContext).
log4j:WARN Please initialize the log4j system properly.
Jun 16, 2009 11:00:10 AM org.apache.cxf.bus.spring.BusApplicationContext
getConfigResources
INFO: No cxf.xml configuration file detected, relying on defaults.
Jun 16, 2009 11:00:14 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://teams.ea.com/}EATeamsWSService from class
com.ea.teams.EATeamsWS
Jun 16, 2009 11:00:26 AM
org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose
INFO: Outbound Message
---
ID: 1
Address: http://teams-rwsdv:9019/teamsws/EATeamsWS
Encoding: UTF-8
Content-Type: text/xml
Headers: {SOAPAction=[], Accept=[*/*]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Headerwsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
soap:mustUnderstand=1ds:Signature
xmlns:ds=http://www.w3.org/2000/09/xmldsig#; Id=Signature-1
ds:SignedInfo
ds:CanonicalizationMethod
Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1;
/
ds:Reference URI=#id-2
ds:Transforms
ds:Transform Algorithm=http://www.w3.org/2001/10/xml-exc-c14n#; /
/ds:Transforms
ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1; /
ds:DigestValue9ugq2OUuSZq3m5dk2pchTf+XSNA=/ds:DigestValue
/ds:Reference
/ds:SignedInfo
ds:SignatureValue
ntGCqu+lVsS5LWvKr2Bovba2xkOrIH7uOVwPk2GzEDVBUd6hdWY1Cw/l/DXH2MtFgokwNrJ2q74o
2wkjiZ+Tc2ak13ccUGAFWFuc0YmVoSZgYtRRZY/phhj7SHREQiodCeMQ7/4j8IZxZDf+JpGy3dwd
js2fRIuc9g7AvpC7KX0=
/ds:SignatureValue
ds:KeyInfo Id=KeyId-327383FBE9F26CE8EF12451752261752
wsse:SecurityTokenReference
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
wsu:Id=STRId-327383FBE9F26CE8EF12451752261753ds:X509Data
ds:X509IssuerSerial
ds:X509IssuerNameCN=teams/ds:X509IssuerName
ds:X509SerialNumber1245171677/ds:X509SerialNumber
/ds:X509IssuerSerial
/ds:X509Data/wsse:SecurityTokenReference
/ds:KeyInfo
/ds:Signature/wsse:Security/soap:Headersoap:Body
xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
wsu:Id=id-2ns1:retrieveAllFields
xmlns:ns1=http://teams.ea.com/;usernamesysadmin/usernamepassword4ealabels/password/ns1:retrieveAllFields/soap:Body/soap:Envelope
--
Jun 16, 2009 11:00:27 AM org.apache.cxf.interceptor.LoggingInInterceptor
logging
INFO: Inbound Message
ID: 1
Encoding: UTF-8
Content-Type: text/xml; charset=utf-8
Headers: {Content-Length=[225], Server=[Jetty(6.1.18)],
content-type=[text/xml; charset=utf-8]}
Payload: soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodysoap:Faultfaultcodesoap:Server/faultcodefaultstringNo
such Localname for SOAP
URI/faultstring/soap:Fault/soap:Body/soap:Envelope
--
javax.xml.ws.soap.SOAPFaultException: No such Localname for SOAP URI
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
at $Proxy47.retrieveAllFields(Unknown Source)
at test.ea.ws.WebServiceClient.main(WebServiceClient.java:46)
Caused by: org.apache.cxf.binding.soap.SoapFault: No such Localname for SOAP
URI
at
org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)
at
org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)
at
Re: How to implement the SOAP Fault for JMS Transport?
Hi, I have added a simple interceptor in the SOAP binding. If the transport uri is http://www.w3.org/2008/07/soap/bindings/JMS/, the jms interceptor will be added. But I have some question for that: 1. I feel a little weird to add a transport-related interceptor here. 2. Program Problem. I have declared some constants in the jms-transport module. I need use some of these constants in the jms interceptor. I think it is a little weird to add project dependency to jms-transport for soap-binding module. Do I need to declare these constants again in the soap-binding module? 3. How to deal with soapjms:isFault property. If the soapjms:isFault is true, it indicates that the response is a SOAP fault. How to deal with this property. best regards, liu Daniel Kulp Writes: On Wed June 10 2009 4:38:37 am liucong wrote: So, the JMS transport just copy JMS message properties to somewhere(For example, Message.PROTOCOL_HEADERS map). Then the SOAP binding add some extra interceptors (How to add these interceptors?) to deal with these properties (check the properties, throw some SOAP Faults, and so on). Does it work? Is it Ok? Yep. That seems right. To add your interceptors, it would be in the SoapBindingFactory class. The createBinding(BindingInfo) method is where the interceptors for the SOAP stuff is setup.That would be the starting place to look. Dan Daniel Kulp Writes: Ideally, to me, this type of fault mapping needs to be in the SOAP binding, not the JMS transport.The JMS transport needs to be somewhat independent of soap so that it's usable for things like XML over JMS and possibly even some resty things. Basically, the SOAP binding should examine it's transportId and if it's the SOAP/JMS spec defined ID, it should add some extra interceptors to handle the mapping of the soap specific things into the non-soap specific things in the transport. For example: all the funky JMS headers that the SOAP/JMS spec requires should be done from an interceptor provided by the SOAP binding (put them in the Message.PROTOCOL_HEADERS map) that the JMS transport would just copy across. That said, I really haven't read the SOAP/JMS spec in very much detail so I'm not sure if it's completely possible. :-) Dan On Mon June 8 2009 10:54:18 pm liucong wrote: Hi, Willem Jiang Writes: Hi, I think you mean how to throw the fault from the JMS transport. Basically , if you throw the fault from a CXF interceptor, CXF's interceptors chain will take care of it and build the fault message and throw it out. If you want to check the Content type , you could write an interceptor and load it with your soap jms transport. How to load an interceptor with my soap jms transport? Is there any material for help? Thank you. But I think you could take the soap binding (SoapBindingFactory) as an example, and put this kind of checking as a work of soap jms binding. Just my 2 cents, Willem liucong wrote: Hi all, When I implement the SOAP Over JMS Specification, I don’t know how to implement SOAP fault for it. I use the org.apache.cxf.interceptor.Fault to record the Fault information. For example, I create a Fault instance for SOAP fault subcode contentTypeMismatch (http://www.w3.org/TR/2008/WD-soapjms-20080723/#binding-faults). If I check the fault the cxf-rt-transports-jms module, I don’t know how to deal with the fault which is checked out. If I added an Interceptor for JMS transport, I can use the interceptor to deal with the fault. Is It right? If it is Ok, how is the interceptor added to the interceptors according to whether the jms transport is used or not? Are there any materials for interceptors, phases, and phase order? Thank you very much! Best regards, Liu
