Re: SOAP over WebSocket
I attached the picture but mailing list swallowed it. There you go http://s29.postimg.org/xbqcwzpzb/cxf_websocket.png I'm finishing a POC I will share with you in the coming days. 9 kwi 2014 09:30 "Przemyslaw Bielicki" napisał(a): > to make my question more clear I made a simplistic and simplified sequence > diagram. > > pls let me know if this is supported in CXF? it is very similar to JMS > where you can receive requests and send responses asynchronously and in any > order. > if it's not supported, is it possible to implement it with current CXF > architecture (mainly, dispatching client requests to business logic)? > > > On Tue, Apr 8, 2014 at 9:47 AM, Przemyslaw Bielicki > wrote: > >> Hi, >> >> does CXF support WebSockets as a transport? I need to support multiplexed >> SOAP and WebSocket protocol looks perfect as a starting point. It is >> bidirectional and full duplex. >> By multiplexing I mean that the client can send messages without waiting >> for the response, and the responses may be sent back in the different order >> that they were sent (I will use message / conversation ID, to identify the >> request and response) >> >> I looked for the information in the mailing list history, but it's still >> not clear for me if you support WebSocket out-of-the box[1] or I need to >> implement my own transport[2] (that could be a nice contribution to CXF? >> >> Many thanks, >> Przemyslaw >> >> [1] http://cxf.apache.org/docs/websocket.html >> [2] http://cxf.apache.org/docs/custom-transport.html >> > >
Re: Http proxy with STS
Unfortunately it's the same problem. Conduit from the configuration isn't used by STS. Looks like a bug. -- View this message in context: http://cxf.547215.n5.nabble.com/Http-proxy-with-STS-tp5743324p5743381.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Http proxy with STS
The simplest way of doing this is to just define http:conduit in Spring as
per the following, which should get picked up by all clients:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=services/sts/systests/basic/src/test/resources/org/apache/cxf/systest/sts/transport/cxf-client.xml;h=41291d063acd23090424add371f816e8bba38bd7;hb=HEAD
I'm not sure offhand how this can be done in code.
Colm.
On Sat, Apr 26, 2014 at 12:48 AM, lotos wrote:
> I just faced with the problem that if I use http proxy and STS at the same
> time it doesn't work.
> Conversation regarding security token doesn't go through the proxy. Only
> main request goes through the proxy. As a result it's not possible to get
> that token at all.
>
> *Is it possible to force CXF to use proxy for all network communications?*
>
> *Java code for proxy*
>
>/ Client client = ClientProxy.getClient(port);
> HTTPConduit http = (HTTPConduit) client.getConduit();
>
> HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
> httpClientPolicy.setProxyServer("localhost");
> httpClientPolicy.setProxyServerPort(3128);
> http.setClient(httpClientPolicy);/
>
> *Policy part of the WSDL:*
> /
>
>
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>
>
>
> RequireClientCertificate="false"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
>
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> ">
>
>
>
>
>
> Namespace="http://www.w3.org/2005/08/addressing"/>
> Namespace="http://www.w3.org/2005/08/addressing"/>
> Namespace="http://www.w3.org/2005/08/addressing"/>
> Namespace="http://www.w3.org/2005/08/addressing"/>
>
> Namespace="http://www.w3.org/2005/08/addressing"/>
>
> Namespace="http://www.w3.org/2005/08/addressing"/>
> Namespace="http://www.w3.org/2005/08/addressing"/>
>
>
>
>
>
>
>
>
> RequireClientCertificate="false"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> ">
>
>
>
>
>
>
>
>
>
> Namespace="http://www.w3.org/2005/08/addressing"/>
>
>
>
CXF compile with JDK 8
Hi, I am using mvn package for compiling source code cxf (https://git-wip-us.apache.org/repos/asf/cxf.git) I am using JDK 8 to compile. Source Code compile fails with error [ERROR] Failed to execute goal org.apache.cxf:cxf-codegen-plugin:3.0.0-SNAPSHOT: wsdl2java (generate-sources) on project cxf-testutils: [ERROR] Exit code: 1 [ERROR] Command line was: d:\Apps\java\jdk\jre\bin\java.exe -jar C:\Users\nagkum ar\AppData\Local\Temp\cxf-tmp-36108\cxf-codegen6570965978496805609.jar C:\Users\ nagkumar\AppData\Local\Temp\cxf-tmp-36108\cxf-w2j6619711455234741106args [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please rea d the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionE xception [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :cxf-testutils Does this not work with JDK 8, compile works fine with JDK 6 & 7. Is there any work around. Raja Nagendra Kumar, C.T.O www.tejasoft.com
CXF Test Cases failing
Hi,
CXF mvn packaging target fails
Apr 28, 2014 7:34:03 PM
org.apache.cxf.tools.validator.internal.WSDLRefValidator
collectValidationPoints
WARNING: WSDL document
file:/C:/temp/cxf/tools/wsdlto/test/target/test-classes/w
sdl2java_wsdl/no_port_or_service.wsdl does not define any services
Tests run: 69, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 21.323
sec <<<
FAILURE! - in org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest
testNamespacePackageMapping3(org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest)
Time elapsed: 0.246 sec <<< ERROR!
org.apache.cxf.tools.common.ToolException: FAIL_TO_WRITE_FILE
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:194)
at java.io.FileOutputStream.(FileOutputStream.java:145)
at
org.apache.cxf.tools.util.OutputStreamCreator.createOutputStream(Outp
utStreamCreator.java:33)
at
org.apache.cxf.tools.util.FileWriterUtil.getWriter(FileWriterUtil.jav
a:68)
at
org.apache.cxf.tools.util.FileWriterUtil.getWriter(FileWriterUtil.jav
a:75)
at
org.apache.cxf.tools.wsdlto.core.AbstractGenerator.parseOutputName(Ab
stractGenerator.java:88)
at
org.apache.cxf.tools.wsdlto.core.AbstractGenerator.parseOutputName(Ab
stractGenerator.java:105)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.generators.SEIGenerator.ge
nerate(SEIGenerator.java:126)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJav
aContainer.java:299)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaCon
tainer.java:164)
at
org.apache.cxf.tools.wsdlto.jaxws.CodeGenBugTest.testNamespacePackage
Mapping3(CodeGenBugTest.java:202)
Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenOptionTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.249
sec - in
org.apache.cxf.tools.wsdlto.jaxws.CodeGenOptionTest
Running org.apache.cxf.tools.wsdlto.jaxws.CodeGenTest
WSIBP Validator found
<{http://apache.org/xml_http_bare}GreetingPortTypeXMLBindi
ng> is NOT a SOAP binding
WSIBP Validator found
<{http://apache.org/xml_http_wrapped}GreetingPortTypeXMLBi
nding> is NOT a SOAP binding
Apr 28, 2014 7:34:16 PM
org.apache.cxf.tools.validator.internal.WSDLRefValidator
collectValidationPoints
WARNING: WSDL document
file:/C:/temp/cxf/tools/wsdlto/test/target/test-classes/w
sdl2java_wsdl/helloworld-noservice-header.wsdl does not define any services
Apr 28, 2014 7:34:17 PM
org.apache.cxf.tools.validator.internal.WSDLRefValidator
collectValidationPoints
WARNING: WSDL document
file:/C:/temp/cxf/tools/wsdlto/test/target/test-classes/w
sdl2java_wsdl/hello_world_async_noservice.wsdl does not define any services
Apr 28, 2014 7:34:21 PM org.apache.cxf.tools.common.ToolErrorListener
addWarning
WARNING:
file:/C:/temp/cxf/tools/wsdlto/test/target/test-classes/wsdl2java_wsdl/
swa-mime.wsdl [34,25]: An xmime:expectedContentTypes attribute is
present on an
incorrect element
Tests run: 60, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.991
sec <<<
FAILURE! - in org.apache.cxf.tools.wsdlto.jaxws.CodeGenTest
testWrapperWithWildcard(org.apache.cxf.tools.wsdlto.jaxws.CodeGenTest)
Time ela
psed: 0.003 sec <<< ERROR!
java.io.IOException: a folder with the name 'classes' already exists
at
org.junit.rules.TemporaryFolder.newFolder(TemporaryFolder.java:97)
at
org.junit.rules.TemporaryFolder.newFolder(TemporaryFolder.java:84)
at
org.apache.cxf.tools.wsdlto.AbstractCodeGenTest$1.before(AbstractCode
GenTest.java:42)
at
org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
at
org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
ner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
ner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provide
r.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4
Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider
.java:124)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameCla
ssLoader(ForkedBooter.java:200)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuit
RE: Extended support for wsdl11external WS-PolicyAttachments references
Hi Dan, URIDomainExpressionBuilder [1] was added to support all WSDL11 domain expressions accordingly spec [2] (excluding wsdl11.extension(namespace,identifier)). I am thinking about registration of this builder as default bus extension (the same way as EndpointReferenceDomainExpressionBuilder): - from one side default registration is comfortable for users applying WSDL11 expressions in external attachments, this will work just out of the box. - from other side, if user would like to register own domain expression (like in one security integration test [3]), it will be very difficult to replace default builder. The problem is that SpringConfiguredBeanLocator used in DomainExpressionBuilderRegistry loads Spring beans on first step and then checks for Bus extensions (using ExtensionManager). Beans specified in custom configuration will be overwritten by registered bus extension. If client or service is created using spring configuration, it is not trivial to replace default DomainExpressionBuilder (it is possible with ExtensionManagerImpl internal methods, but not convenient). I see following options: (a) Leave the code as is and document that user have to register URIDomainExpressionBuilder as bus extension or as a bean to use WSDL11 expressions. (b) Change initialization order in SpringConfiguredBeanLocator to give spring beans higher priority as bus extensions (this can have side effects) (c) Introduce convenient mechanism to replace/remove registered bus extensions or control behaviour of ConfiguredBeanLocator. What is your opinion? May be I am missing something and option (c) is already available? Regards, Andrei. [1] https://fisheye6.atlassian.com/changelog/cxf?cs=a4ea197c50c99d0c02d9226484c3ee0f8fa63b05 [2] http://www.w3.org/TR/2007/NOTE-wsdl11elementidentifiers-20070720/ [3] https://fisheye6.atlassian.com/browse/cxf/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/policy/UriDomainExpression.java > -Original Message- > From: Daniel Kulp [mailto:dk...@apache.org] > Sent: Freitag, 11. April 2014 19:40 > To: dev@cxf.apache.org; Andrei Shakirin > Subject: Re: Extended support for wsdl11external WS-PolicyAttachments > references > > > No objections here. I think we just implemented the few basic places to meet > whatever test case we were shooting for with the old Microsoft > interoperability > tests and didn't go much further. > > Dan > > > On Apr 11, 2014, at 5:44 AM, Andrei Shakirin wrote: > > > Hi, > > > > Currently CXF supports only limited set of references for external WS- > PolicyAttachments (wsa:EndpointReferenceType): > > > > http://www.w3.org/ns/ws-policy"; > xmlns:test="http://x.y.z/Assertions";> > > > > > > xmlns:wsa="http://www.w3.org/2005/08/addressing";> > >http://x.y.z/GreeterPort > > > > > > > > A > > > > > > > > > > I propose to extend that to support at least some URI Domain Expression for > wsdl11: > > wsdl11.definitions() > > wsdl11.service(service) > > wsdl11.binding(binding) > > wsdl11.bindingOperation(binding/operation) > > wsdl11.bindingOperation.input(binding/operation) > > wsdl11.bindingOperation.output(binding/operation) > > wsdl11.bindingOperation.fault(binding/operation/fault) > > > > I see that some work was started in cxf-rt-ws-policy > Wsdl11XPointerDomainExpression class, but it seems that is not complete. > > Partly it is also implemented in systests > > org.apache.cxf.systest.ws.policy.UriDomainExpression and > > org.apache.cxf.systest.ws.policy.UriDomainExpressionBuilder > > > > I would create Jira and add support for wsdl11 references. > > Any suggestions / objections? > > > > Regards, > > Andrei. > > > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog Talend Community Coder - > http://coders.talend.com
ConnectionFactoryFeature missing in cxf-rt-transports-jms-3.0.0-milestone2-sources.jar
Hi, I noticed that org.apache.cxf.transport.jms.ConnectionFactoryFeature class is missing in cxf-rt-transports-jms-3.0.0-milestone2-sources.jar. Maybe also other classes are missing too. I checked CXF Git repo and the class is there in both master branch and 3.0.0-milestone2 tag, so I don't understand why it's missing in the JAR. Any ideas? Cheers, Przemyslaw
