Re: woodstox mandatory?
to use cxf (tested with v2.6.7) because of org.apache.cxf.staxutils.StaxUtils is it normal? in TomEE we were remove it by default so basically it means we can't upgrade *Romain Manni-Bucau* *Twitter: @rmannibucauhttps://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: woodstox mandatory?
.**findClass(URLClassLoader.java:**354) at java.lang.ClassLoader.**loadClass(ClassLoader.java:**423) at sun.misc.Launcher$**AppClassLoader.loadClass(**Launcher.java:308) at java.lang.ClassLoader.**loadClass(ClassLoader.java:**356) ... 37 more *Romain Manni-Bucau* *Twitter: @rmannibucauhttps://twitter.**com/rmannibucauhttps://twitter.com/rmannibucau * *Blog: **http://rmannibucau.**wordpress.com/*http://rmannibucau.wordpress.com/* http://**rmannibucau.wordpress.com/http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/**rmannibucau*http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/**rmannibucau*https://github.com/rmannibucau* 2013/4/2 Freeman Fangfreeman.f...@gmail.com Hi, I believe it's just compile time dependency, during runtime, you still can use any other stax parser for now. What's the error you run into? － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.**comhttp://freemanfang.blogspot.com http://blog.sina.com.cn/u/**1473905042http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-4-2, at 下午3:19, Romain Manni-Bucau wrote: Hi, seems woodstox is now mandatory to use cxf (tested with v2.6.7) because of org.apache.cxf.staxutils.**StaxUtils is it normal? in TomEE we were remove it by default so basically it means we can't upgrade *Romain Manni-Bucau* *Twitter: @rmannibucauhttps://twitter.**com/rmannibucauhttps://twitter.com/rmannibucau * *Blog: **http://rmannibucau.**wordpress.com/*http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.**com/http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/**rmannibucau*http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/**rmannibucau*https://github.com/rmannibucau* -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: woodstox mandatory?
On 02/04/13 16:10, Daniel Kulp wrote: Actually, this stack trace really concerns me. This makes it look like we have an XMLStreamReader that was not created via one of the StaxUtils methods. Otherwise, this exception would be raised at creation time, not close. That bothers me as all the creations of the readers should be done via the StaxUtils methods if possible.(providing this is XML. I suppose if this is JSON with Jettison or Fastinfoset that has their own factories, it's different) Is there anyway you could help debug where the stream reader is being created in this case? I look at JSONProvider and indeed it uses StaxUtils.close() to close the reader, so it is a good observation indeed, though I'm not 100% sure this is the path one of Romain's tests is exercising. thanks, Sergey Thanks! Dan On Apr 2, 2013, at 3:42 AM, Romain Manni-Bucaurmannibu...@gmail.com wrote: when unmarshalling (org.apache.cxf.jaxrs.provider.JAXBElementProvider.readFrom) the reader is closed thanks to StaxUtils.close(reader); call and it triggers: org.apache.cxf.jaxrs.client.ClientWebApplicationException: java.lang.NoClassDefFoundError: com/ctc/wstx/stax/WstxInputFactory at org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:871) at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:841) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:768) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:729) at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:345) at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:481) at org.superbiz.rest.UserServiceTest.show(UserServiceTest.java:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Caused by: java.lang.NoClassDefFoundError: com/ctc/wstx/stax/WstxInputFactory at org.apache.cxf.jaxrs.provider.JAXBElementProvider.readFrom(JAXBElementProvider.java:196) at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:446) at org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:857) ... 34 more Caused by: java.lang.ClassNotFoundException: com.ctc.wstx.stax.WstxInputFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 37 more *Romain Manni-Bucau* *Twitter: @rmannibucauhttps://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/4/2 Freeman Fangfreeman.f...@gmail.com Hi, I believe it's just compile time dependency, during runtime, you still can use any other stax parser for now. What's the error you run into? － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web:
Re: [VOTE] Release Apache CXF 2.5.10/2.6.7/2.7.4
+1 Sergey On 29/03/13 00:09, Daniel Kulp wrote: We've resolved over 80 issues since 2.7.3, which is a bunch List of issues: 2.5.10 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324007 2.6.7 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324006 2.7.4 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12324005 The Maven staging areas are at: (forgot to close between 2.5.10 and 2.6.7) 2.5.10 2.6.7 https://repository.apache.org/content/repositories/orgapachecxf-030/ 2.7.4 https://repository.apache.org/content/repositories/orgapachecxf-031/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.10 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.7 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.4 This vote will be open for at least 72 hours. Here's my +1.
Re: svn commit: r1461738 - /cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
Dan, thanks for the fix, I actually did not include the local CORS
update, sorry
Sergey
On 27/03/13 20:47, dk...@apache.org wrote:
Author: dkulp
Date: Wed Mar 27 17:47:25 2013
New Revision: 1461738
URL: http://svn.apache.org/r1461738
Log:
Fix tests by allowing for the null return.
Modified:
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
Modified:
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java?rev=1461738r1=1461737r2=1461738view=diff
==
---
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
(original)
+++
cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharingFilter.java
Wed Mar 27 17:47:25 2013
@@ -491,10 +491,12 @@ public class CrossOriginResourceSharingF
splitPattern = FIELD_COMMA_PATTERN;
}
ListString results = new ArrayListString();
-for (String value : values) {
-String[] items = splitPattern.split(value);
-for (String item : items) {
-results.add(item.trim());
+if (values != null) {
+for (String value : values) {
+String[] items = splitPattern.split(value);
+for (String item : items) {
+results.add(item.trim());
+}
}
}
return results;
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Thoughts about a 2.8 release (or not)…
Hi Andrei On 27/03/13 18:24, Andrei Shakirin wrote: +1 for skipping 2.8 and releasing 3.0 end of this year. @Sergei: let us to discuss how I could help with 2.0 TCK. I'm trying to get the server part close enough to be tested against TCK. There are 3 issues which I'm aware at the moment that need to be completed: 1. support for server-side media type quality parameters (;qs), this is needed 2. support fro injection of Configuration context - should be straightforward enough 3. bean validation support - the latter is important but has just been confirmed to be an optional feature - that said I think we can probably get it done for RS but also for WS I think only 1 is required at this stage to start working with TCK, plus minor bits and pieces to be fixed to get (server-part) TCK passed :-). The TCK we have is not final but should be close enough to the final one. The client implementations tests will be done later in the year I'll get back to you once I do an initial run later on Thanks Sergey Regards, Andrei. -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: Montag, 25. März 2013 19:19 To: dev@cxf.apache.org Subject: Thoughts about a 2.8 release (or not)… We're getting close to April which normally would be the next release (2.8). However, looking things over, I'm not sure it makes sense at this time. Looking at trunk, the only major change (which is admittedly a big one), is updating the JAX-RS 2.0 stuff from m10 to the RC level. However, it's not complete yet. Almost everything else has been back ported to 2.7.x. The other major chunk of work that is happening is on the wss4j2 branch, but that isn't ready for for release yet either. (and has some backwards compat issues to resolve if it would go on a 2.x line) According to the agreements Apache has with Oracle, we really cannot release code that doesn't pass the TCK (which the 2.0 works would not). Technically, we should not have released 2.7.0 as a release. We can release things like tech previews or beta or similar, but not a full release. Since we are working on trying to renew the agreements, Oracle is paying attention to us pretty closely right now. So, what am I getting at? In order to release 2.8 in a few weeks, we'd either need to back out all the JAX-RS 2.0 stuff to 1.1 level OR everyone jump in full force and get it to pass the TCK. I really don't see either happening. Backing out to 1.1 would be silly and the 2.0 TCK stuff is a ton of work. Thus, my suggestion would be to skip a big release this April and concentrate on bigger things for our Oct/Nov release. Possibly make that a CXF 3.0 release instead of 2.8 where we can clean up some stuff, break a few things (like change the couple API's that currently force WSDL4J on JAX-RS users), etc…We can incorporate the WSS4J2 changes as part of this as well.If we go this route, we could likely start a series of beta releases or similar in June or so to get people looking at it and testing with it. Any thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Thoughts about a 2.8 release (or not)…
On Tue, Mar 26, 2013 at 5:25 AM, Jeff Genenderjgenen...@apache.org wrote: Or… don't claim its a certified release… That may work too. One problem is that JAX-RS 2.0 is nearly finalized but not yet and I'm not sure when Apache will get the final TCK after that. As far as JAX-RS 2.0 is concerned, CXF will not have a 'bullet-proof' implementation in a few weeks time, so I'm also fine with not releasing 2.8.0 in April, but I like Dan's idea to consider doing a beta release or few of them during the summer time; I think those users who work with JAX-RS should have an option to play with the final API as soon as realistically possible, before they start considering trying the friendly implementations from Oracle or JBoss :-) Thanks, Sergey Jeff On Mar 25, 2013, at 12:19 PM, Daniel Kulpdk...@apache.org wrote: We're getting close to April which normally would be the next release (2.8). However, looking things over, I'm not sure it makes sense at this time. Looking at trunk, the only major change (which is admittedly a big one), is updating the JAX-RS 2.0 stuff from m10 to the RC level. However, it's not complete yet. Almost everything else has been back ported to 2.7.x. The other major chunk of work that is happening is on the wss4j2 branch, but that isn't ready for for release yet either. (and has some backwards compat issues to resolve if it would go on a 2.x line) According to the agreements Apache has with Oracle, we really cannot release code that doesn't pass the TCK (which the 2.0 works would not). Technically, we should not have released 2.7.0 as a release. We can release things like tech previews or beta or similar, but not a full release. Since we are working on trying to renew the agreements, Oracle is paying attention to us pretty closely right now. So, what am I getting at? In order to release 2.8 in a few weeks, we'd either need to back out all the JAX-RS 2.0 stuff to 1.1 level OR everyone jump in full force and get it to pass the TCK. I really don't see either happening. Backing out to 1.1 would be silly and the 2.0 TCK stuff is a ton of work. Thus, my suggestion would be to skip a big release this April and concentrate on bigger things for our Oct/Nov release. Possibly make that a CXF 3.0 release instead of 2.8 where we can clean up some stuff, break a few things (like change the couple API's that currently force WSDL4J on JAX-RS users), etc…We can incorporate the WSS4J2 changes as part of this as well.If we go this route, we could likely start a series of beta releases or similar in June or so to get people looking at it and testing with it. Any thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] - Release Apache Fediz 1.0.3
+1 Sergey On 20/02/13 14:35, Oliver Wulff wrote: +1 Oli From: Colm O hEigeartaigh [cohei...@apache.org] Sent: 19 February 2013 18:05 To: dev@cxf.apache.org Subject: [VOTE] - Release Apache Fediz 1.0.3 This is a vote to release Apache Fediz 1.0.3. This is a bug-fix release with an upgraded CXF 2.6.6 dependency. Release notes: https://issues.apache.org/jira/browse/FEDIZ/fixforversion/12323485 SVN tag: http://svn.apache.org/viewvc/cxf/fediz/tags/fediz-1.0.3/ Artifacts: https://repository.apache.org/content/repositories/orgapachecxf-267/ Here is my +1. Colm. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: CXF 2.7 and Rest service
Hi On 14/02/13 10:51, marcin.kasinski wrote: Hello. Is this bug fixed or not ? In cxf 2.7.3 I have the same error. Unfortunately the fixes which went into 2.7.2 and 2.7.3 did not eliminate the problem completely, CXF 2.7.4 has been confirmed independently to have resolved it - more confirmation would help. By the way, if the email client does not show the whole thread it can be tricky to figure out what we are talking about here :-), so preserving some context can help. For the benefit of the list: JAX-RS endpoints fail to register if a WS-Discovery endpoint is also activated, fixed in 2.7.4-SNAPSHOT Thanks, Sergey - Regards Marcin Kasinski http://itzone.com.pl -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-2-7-0-and-Rest-jaxrs-service-tp5716862p5723181.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] New features.xml for 2.6.6
On 13/02/13 18:05, Daniel Kulp wrote: There is a problem with the features.xml file for 2.6.6 where a property wasn't expanded. This is a vote to release a 2.6.6.1 versioned features file only that pulls in the 2.6.6 bundles, but correct the property expansion. Staging repo: https://repository.apache.org/content/repositories/orgapachecxf-232/ Tag: https://svn.apache.org/repos/asf/cxf/tags/apache-cxf-features-xml-2.6.6.1/ +1 Cheers, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Apache DOSGi 1.4.0 Release
+1 Thanks, Sergey On 22/01/13 19:47, Christian Schneider wrote: The Apache CXF DOSGi subproject is the Reference Implementation of the OSGi Remote Services and Remote Services Admin Service specifications [1] which provide a distributed computing model based around OSGi Services. The CXF DOSGi 1.4.0 release contains the following fixes and improvements: * 41 issues resolved (see jira) https://issues.apache.org/jira/browse/DOSGI/fixforversion/12319877 * Karaf feature for easy installation in Apache Karaf http://cxf.apache.org/dosgi-apache-karaf-feature.html * Zookeeper discovery http://cxf.apache.org/dosgi-discovery.html now supports automatic reconnects and Cluster configuration * DOSGi is now independent of spring dm * Custom intents are now created by publishing e.g. CXF Features as services * Big refactorings make the code much easier to understand Also see the release notes: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.4.0/distribution/sources/src/main/release/release_notes.txt Staging area: https://repository.apache.org/content/repositories/orgapachecxf-155/ The vote will be open for at least 72 hours. Here's my +1. Best regards, Christian [1] Chapters 13 and 122 in the OSGi 4.2 Enterprise Specification at http://www.osgi.org/Download/Release4V42 -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: JAX-RS 2.0 and CXF 2.7.x
On 21/12/12 12:13, Sergey Beryozkin wrote: On 20/12/12 18:48, Sergey Beryozkin wrote: Hi At the moment CXF 2.7.2-SNAPSHOT depends on jsr339-api-m10 - this is quite close to the current JAX-RS 2.0 Snapshot API. ServiceMix spec jsr339-api-m10 (v 2.2.0) is also available. Next, jsr339-api-m13 and now jsr339-api-m15 are available in Central. The differences between jsr339-api-m10 and jsr339-api-m15 are quite minor at JAX-RS 2.0 API level - especially given that CXF does not implement yet the actual JAX-RS 2.0 client fluent API (though as I've mentioned earlier the async invoker and all 2.0 filters/interceptors are already supported). Users who started experimenting with AsyncResponse might see some differences - primarily to do with resume/cancel returning boolean instead of throwing exceptions, etc. Thought who might've started with DynamicFeature would be impacted most - but I honestly do not think anyone has started coding DynamicFeatures - we do not document it yet. I've been planning to get 2.7.x implementing final 2.0 API. It is important to note that the users migrating to 2.7.x are not expected to see any BC issues (and it was thanks to early 2.7.x users that we fixed some initial regressions/issues in 2.7.x). I've upgraded locally to jsr339-api-m15 and I'm eager to commit :-) The only 'side-effect' is that the users of next to be released CXF 2.7.2 would need to replace jsr339-api-m10 and jsr339-api-m15. Alternatively: we can keep jsr339-api-m10 in CXF 2.7.x for its lifetime, and get CXF 2.8.0-SNAPSHOT starting effectively with jsr339-api-m15 and commit to having CXF 2.8.0/1 get the final JAX-RS 2.0 done My preference is to get the 2.0 dependencies changed in 2.7.x or at least do the upgrade to m15 and stay there with the further updates done only in 2.8.x - however if there is some concern about it then the alternative (mentioned or others) can also work. Any comments ? I've already got some feedback - there's some concern from our ESB team it may affect the stability of the distribution which is based on 2.7.x - thus looks like I will postpone and just upgrade to jsr339-api-m15 in 2.8.0-SNAPSHOT. Ultimately, CXF 2.7.x is much more than the initial JAX-RS 2.0 support so those JAX-RS users who have already migrated can expect the 2.0 to 1.1 API BC stability at 2.7.x, experiment with new JAX-RS 2.0 constructs and expect very very minor upgrades required if using 2.0 API when migrating further to 2.8.x - unless they've already started using JAX-RS DynamicFeature (hint :-)) I've upgraded to m15 on the trunk (2.8.0-SNAPSHOT only). As I said, those 2.7.x users which have started using JAX-RS 2.0 constructs can expect very minor if any updates when moving to CXF 2.8.0 at the later stage Thanks, Sergey
Re: Branching for 2.7.x-fixes...
On 05/01/13 01:23, Daniel Kulp wrote: With 2.7.2 now built, I'm planning to create the 2.7.x-fixes branch and make trunk target 2.8. I'll likely set that all up on Monday. Any objections or thoughts or anything? +1 Cheers, Sergey
Re: [VOTE] Apache CXF 2.5.8/2.6.5/2.7.2
+1 Cheers, Sergey On 05/01/13 01:22, Daniel Kulp wrote: We've resolved over 35 issues since 2.7.1. Not a huge number, but sufficient. List of issues: 2.5.8 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12323606 2.6.5 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12323605 2.7.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12323604 The Maven staging areas are at: 2.5.8 https://repository.apache.org/content/repositories/orgapachecxf-99/ 2.6.5 https://repository.apache.org/content/repositories/orgapachecxf-100/ 2.7.2 https://repository.apache.org/content/repositories/orgapachecxf-101/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.8 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.5 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.2 This vote will be open for at least 72 hours. Here's my +1.
Re: About Distributed OSGi greeter_rest demo
Hi Tang CC-ing to dev as it might of the general interest On 04/01/13 15:53, Tang Yong wrote: Hi Sergey, Thanks, I still have many needing to learn... :) I have two questions and want to ask you or Christian, [Background] In the future(not very long), I will try to integrate DCXF into Glassfish v4 in order to make glassfish have DOSGi capability(this is also why I start to join DCXF and indeedly, DCXF is an excellent framework!), as to how to integrate it, I am still in thinking, because ,currently, glassfish has not some functions similar to Karaf's feature or OSGi subsystem(this is also why I start to do some research on Karaf's kernel/feature). [Question1] However, glassfish has a itself OSGi http container implementation, and I wish that defaultly, while starting DCXF, it can use glassfish's OSGi http container, so could you give me some advice(if spenting your too much time, no problem, I will investigate it in depth, :)) I guess it does not matter at DOSGi level how HTTPService is provided, whether with pax-web or via the container-specific implementation [Question2] glassfish has itself jax-rs/ws implementation(jersey), and currently, DCXF uses CXF as core jax-rs/ws implementation, I have an unmature idea: whether there is a possibility that we can swich jax-rs/ws implementation and also use other framework(for example, jersey), of course, I know that this is a litter unpractical. Well, quite awhile back there was some discussion on how to get the actual DSW implementation pluggable, example, some experts wanted a very slim RI implementation based on something like RMI, but it never came to any practical solution. If someone can ever come up with some practical patch with CXF being the default DSW stack - then why not :-) Cheers, Sergey Thanks --Tang
Re: svn commit: r142447
thanks Dan
On 20/12/12 14:16, dk...@apache.org wrote:
Author: dkulp
Date: Thu Dec 20 14:16:01 2012
New Revision: 1424479
URL: http://svn.apache.org/viewvc?rev=1424479view=rev
Log:
[CXF-4714] Better fix by fixing the underlying jetty stream
Modified:
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
Modified:
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java?rev=1424479r1=1424478r2=1424479view=diff
==
---
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
(original)
+++
cxf/trunk/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
Thu Dec 20 14:16:01 2012
@@ -43,6 +43,7 @@ import org.apache.cxf.configuration.jsse
import org.apache.cxf.configuration.security.CertificateConstraintsType;
import org.apache.cxf.continuations.ContinuationProvider;
import org.apache.cxf.continuations.SuspendedInvocationException;
+import org.apache.cxf.helpers.IOUtils;
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.io.CachedOutputStream;
import org.apache.cxf.io.CopyingOutputStream;
@@ -394,6 +395,7 @@ public class JettyHTTPDestination extend
static class JettyOutputStream extends FilterOutputStream implements
CopyingOutputStream {
final Output out;
+boolean written;
public JettyOutputStream(Output o) {
super(o);
out = o;
@@ -401,10 +403,21 @@ public class JettyHTTPDestination extend
@Override
public int copyFrom(InputStream in) throws IOException {
+if (written) {
+return IOUtils.copy(in, out);
+}
CountingInputStream c = new CountingInputStream(in);
out.sendContent(c);
return c.getCount();
}
+public void write(int b) throws IOException {
+written = true;
+out.write(b);
+}
+public void write(byte b[], int off, int len) throws IOException {
+written = true;
+out.write(b, off, len);
+}
}
static class CountingInputStream extends FilterInputStream {
int count;
Modified:
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java?rev=1424479r1=1424478r2=1424479view=diff
==
---
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
(original)
+++
cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java
Thu Dec 20 14:16:01 2012
@@ -696,7 +696,7 @@ public abstract class AbstractHTTPDestin
written = true;
}
if (wrappedStream != null) {
-return IOUtils.copy(in, wrappedStream,
IOUtils.DEFAULT_BUFFER_SIZE);
+return IOUtils.copy(in, wrappedStream);
}
return IOUtils.copy(in, this, IOUtils.DEFAULT_BUFFER_SIZE);
}
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: When to move JAX-RS Client implementation to the new module
On 13/12/12 12:01, Sergey Beryozkin wrote: Hi, I've opened CXF-4696 [1] to get the client implementation moved out of jax-rs frontend to its own module: to get the main module smaller, to let users avoid downloading extra baggage when no client code is utilized and in preparation for implementing JAX-RS 2.0 API (though I'm keen on keeping supporting WebClient API, with Proxy API having no challenge from 2.0 API :-)) I thought I'd wait till CXF 2.8.0-SNAPSHOT but then started changing my mind, the reason is that CXF 2.7.x users can expect minor dependency changes during the lifetime of CXF 2.7.x anyway, for example, jsr339-api-m10 dep will get replaced soon enough by jsr339-api-m13 - this for the most parts will be limited just to it, to the dependency update. Moving the client code to its own module will affect 2.7.x users exactly the same way, at some point, say, when migrating to CXF 2.7.2, they will need to add a new dependency but only if they also work with the client API. IMHO this is can be simpler, as opposed to having CXF 2.7.x and 2.8.x jaxrs frontends still depending till some point of time on the not finalized 2.0 API but having the client api located in different modules... After more consideration and some feedback it seems that that the best thing to do is to postpone it till a new 2.8.0-SNAPSHOT trunk is created; splitting the jaxrs frontend into 2 modules on the existing 2.7.x trunk (and soon to become a branch) appears to be a step too far... I'm still planning to do some refactoring on 2.7.x (to do with getting ProviderFactory class a bit more manageable given that now it has to deal with so many providers) but getting the modules split is definitely will be done in 2.8.x Updating to newer JAX-RS 2.0 milestone releases on 2.7.x is a slightly different issue - I'll start a new thread Thanks, Sergey [1] https://issues.apache.org/jira/browse/CXF-4696
JAX-RS 2.0 and CXF 2.7.x
Hi At the moment CXF 2.7.2-SNAPSHOT depends on jsr339-api-m10 - this is quite close to the current JAX-RS 2.0 Snapshot API. ServiceMix spec jsr339-api-m10 (v 2.2.0) is also available. Next, jsr339-api-m13 and now jsr339-api-m15 are available in Central. The differences between jsr339-api-m10 and jsr339-api-m15 are quite minor at JAX-RS 2.0 API level - especially given that CXF does not implement yet the actual JAX-RS 2.0 client fluent API (though as I've mentioned earlier the async invoker and all 2.0 filters/interceptors are already supported). Users who started experimenting with AsyncResponse might see some differences - primarily to do with resume/cancel returning boolean instead of throwing exceptions, etc. Thought who might've started with DynamicFeature would be impacted most - but I honestly do not think anyone has started coding DynamicFeatures - we do not document it yet. I've been planning to get 2.7.x implementing final 2.0 API. It is important to note that the users migrating to 2.7.x are not expected to see any BC issues (and it was thanks to early 2.7.x users that we fixed some initial regressions/issues in 2.7.x). I've upgraded locally to jsr339-api-m15 and I'm eager to commit :-) The only 'side-effect' is that the users of next to be released CXF 2.7.2 would need to replace jsr339-api-m10 and jsr339-api-m15. Alternatively: we can keep jsr339-api-m10 in CXF 2.7.x for its lifetime, and get CXF 2.8.0-SNAPSHOT starting effectively with jsr339-api-m15 and commit to having CXF 2.8.0/1 get the final JAX-RS 2.0 done My preference is to get the 2.0 dependencies changed in 2.7.x or at least do the upgrade to m15 and stay there with the further updates done only in 2.8.x - however if there is some concern about it then the alternative (mentioned or others) can also work. Any comments ? Thanks, Sergey
Re: Container validation of UsernameToken passwords?
This is why using JAAS is better :-) Cheers, Sergey On 15/12/12 00:17, Glen Mazza wrote: OK, I just debugged the Metro source code to determine how they can read the Tomcat tomcat-users.xml file in order to do validation of UsernameToken passwords. Basically, if no sc:ValidatorConfiguration defined in the service-side WSDL: https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89 Then, the conditional at Metro's DefaultSecurityEnvironmentImpl.authenticateUser() line #1167 will not be met: http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultSecurityEnvironmentImpl.java#1167 ...and hence the line at 1173 (to check the Tomcat password file) is done instead, in class DefaultRealmAuthenticationAdapter.authenticate(): http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultRealmAuthenticationAdapter.java#DefaultRealmAuthenticationAdapter.authenticate%28javax.security.auth.Subject%2Cjava.lang.String%2Cjava.lang.String%29 As you can see from the above class, Metro can do this for Tomcat and GlassFish only, not all servlet containers; furthermore it just relies on system variables to hunt down the location of the tomcat-users.xml and read usernames and passwords from it. (For GlassFish, as shown in that same class, it attempts to load a GlassFish callback handler of some sort, instead of reading a file.) Glen -- View this message in context: http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516p5720335.html Sent from the cxf-dev mailing list archive at Nabble.com.
When to move JAX-RS Client implementation to the new module
Hi, I've opened CXF-4696 [1] to get the client implementation moved out of jax-rs frontend to its own module: to get the main module smaller, to let users avoid downloading extra baggage when no client code is utilized and in preparation for implementing JAX-RS 2.0 API (though I'm keen on keeping supporting WebClient API, with Proxy API having no challenge from 2.0 API :-)) I thought I'd wait till CXF 2.8.0-SNAPSHOT but then started changing my mind, the reason is that CXF 2.7.x users can expect minor dependency changes during the lifetime of CXF 2.7.x anyway, for example, jsr339-api-m10 dep will get replaced soon enough by jsr339-api-m13 - this for the most parts will be limited just to it, to the dependency update. Moving the client code to its own module will affect 2.7.x users exactly the same way, at some point, say, when migrating to CXF 2.7.2, they will need to add a new dependency but only if they also work with the client API. IMHO this is can be simpler, as opposed to having CXF 2.7.x and 2.8.x jaxrs frontends still depending till some point of time on the not finalized 2.0 API but having the client api located in different modules... Cheers, Sergey [1] https://issues.apache.org/jira/browse/CXF-4696
Re: [VOTE] Apache CXF 2.5.7/2.6.4/2.7.1
+1, thanks, Sergey On 07/12/12 14:41, Daniel Kulp wrote: We've resolved over 110 issues since 2.7.0. That's a very large number for a patch release so we definitely should get this out. Over 90 were ported back to 2.6.4, again, a large number. List of issues: 2.5.7 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12323349 2.6.4 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12323348 2.7.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12323347 The Maven staging areas are at: 2.5.7 https://repository.apache.org/content/repositories/orgapachecxf-120/ 2.6.4 https://repository.apache.org/content/repositories/orgapachecxf-121/ 2.7.1 https://repository.apache.org/content/repositories/orgapachecxf-122/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.7 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.4 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.1 This vote will be open for at least 72 hours. Here's my +1.
Re: Container validation of UsernameToken passwords?
Will configuring WSS4JInInterceptor to skip validating the token (ws-security.validate.token property set to false) and using JAASLoginInterceptor do it ? http://cxf.apache.org/docs/security.html#Security-JAASLoginInterceptor This path might work for UT only I guess Cheers, Sergey On 04/12/12 12:06, Colm O hEigeartaigh wrote: I don't think there is a way to handle this at the moment. You could plug in a custom Validator for (WS-Security) UsernameTokens and do some container-specific validation I guess. Colm. On Fri, Nov 30, 2012 at 4:51 PM, Glen Mazzaglen.ma...@gmail.com wrote: Hi folks, I just confirmed by testing Metro w/UsernameToken over SSL transport (haven't tried UT via their symmetric binding yet), that if I *don't* configure a server-side password callback handler like here: https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89 , Metro transparently switches to container validation instead -- in my case, the tomcat-users.xml file: http://www.jroller.com/gmazza/entry/ssl_for_web_services#SSL5 . The validation appears to be the same validation done with SSL with basic authentication, i.e., checking that the username and password exists within the roles defined in the web.xml in the WAR hosting the web service. Having not yet debugged the Metro source code, I'm not sure whether Metro is hardcoded to be able to handle only GlassFish and Tomcat or can generically do container validation with any servlet container (I would suspect the latter), or what it would do for OSGi environments for that matter. Is there a way to do this right now with CXF? CXF raises General security error (WSSecurityEngine: No password callback supplied) if I don't provide a server-side password callback handler as here: https://github.com/gmazza/blog-samples/blob/master/cxf_usernametoken_profile/war/src/main/webapp/WEB-INF/cxf-servlet.xml#L19 . If not, I'm not sure if it's worth implementing--I guess it's a question of how much additional benefit it would provide, the amount of effort it would take to do so in a generic fashion, and risk of security vulnerabilities. Regards, Glen -- View this message in context: http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Fediz IDP refactored
Hi I was also planning to ask, if CXF plugin were to be added too, how will it work with such a plugin ? Cheers, Sergey Hi there I've refactored the Fediz IDP and I'd like your feedback. The IDP is based on a state machine which re-uses Servlet Filters to build up the processing chain but an abstract AbstractAuthFilter handles all the state related processing. I was struggeling a little bit how to define the states. An enum is to static whereas a string to error prone. I'd like that users have the option to extend the IDP without having to patch the enum class to introduce new states. I've defined the default states in a enum but all processing is based on strings. It's now much easier to add the SAML profile as only the FederationFilter and FederationPostFilter has to be rewritten. Another topic I'd like your opinion is the pre-state condition. A filter is called only if the one state condition is met. If a filter could support depending on different states, there is also only one FederationFilter needed. Looking forward for your feedback. Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Need help with CXF 2.2.11
On 01/12/12 15:42, deepachandaran.palanis...@cognizant.com wrote: Hi I am using CXF 2.2.11 as Restful webservice client. I understand that we can configure timeout SSL using configuration file. Can you please guide me on configuring the timeout SSL via Java code? I don't see Webclient.getConfig method in CXF 2.2. Please help. In that case please consider migrating to the newer CXF. Cheers, Sergey Regards, -Deepak This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CXF Continuations Not Portable Issue
Hi Richard
On 27/11/12 08:12, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 04:58 PM, Sergey Beryozkin wrote:
Hi Richard
On 26/11/12 15:05, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 02:57 PM, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 01:31 PM, Sergey Beryozkin wrote:
Hi Richard
On 26/11/12 12:29, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 01:21 PM, Sergey Beryozkin wrote:
Hi Richard
On 26/11/12 12:15, Richard Opalka wrote:
Dear CXF developers,
I'm analyzing our recent CXF continuation related failures
in CI
and I identified the following problem:
SVN commit id: 1409193
introduced
---
@@ -57,32 +57,30 @@ public class Servlet3ContinuationProvider
implements
ContinuationProvider {
if (continuation == null) {
continuation = new Servlet3Continuation();
+} else {
+continuation.startAsyncAgain();
}
return continuation;
}
---
method call that causes our JBossWeb to throw IllegalStateException.
According to startAsync() javadoc for Throws:
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#startAsync%28%29
---
Throws:
IllegalStateException - if this request is within the
scope of a
filter or servlet that does not support asynchronous operations
(that
is, isAsyncSupported() returns false), or if this method is called
again
without any asynchronous dispatch (resulting from one of the
AsyncContext#dispatch methods), is called outside the scope of
any such
dispatch, or is called again within the scope of the same
dispatch, or
if the response has already been closed
---
JBossWeb is strictly following these ISE guidelines (is not lenient
like e.g. Jakarta Tomcat).
What would you say about
Subsequent invocations of this method, or its overloaded variant,
will
return the same AsyncContext instance, reinitialized as
appropriate. ?
Without this call I can not have the test doing multiple timeouts
on the
same continuation working...
Makes sense to me. I had a look to our JBoss Web code again and I
noticed one suspicious line there - I'm going to discuss it with our
folks.
Oh, thanks for that, I've just sent one more follow-up, sorry about
the
noise, should've waited :-)
Let's see what our Servlet experts will say -
https://issues.jboss.org/browse/JBWEB-256
Our JBoss Web guru is saying JBoss Web impl. is correct.
I'd appreciate to see more concrete clarifications, regarding the
following two points:
- the documentation clearly says that repeated calls of startAsync()
return the same instance.
- what does it mean to have called startAsync() called on the same
dispatch, does it apply to a current thread dispatch or to the whole
suspended continuation process ?
To be honest, the positive statement on the multiple startAsync calls
makes me think the ISE case applies to this method called multiple times
during the same thread dispatch...
Thanks, Sergey
Unfortunately I'm not servlet expert :( But Remy suggested (see
JBWEB-256 comments):
'Feel free to seek further clarification from the specification expert
groups if you like.'
First of all, thanks for validating the proposed fix from Dan, your
patch has been applied.
I think at the moment the only argument I have is it works with Tomcat
Jetty which is not a strong enough proof that ISE should not be
actually reported :-), so the fix is a good compromise. I'd love to see
the clear statement from the servlet experts, but I wonder if it is even
possible to get them to answer :-)
Thanks, Sergey
Cheers,
Rio
Cheers, Sergey
The last issue that I identified with
Servlet3ContinuationProvider is
the isNew flag has incorrect initial value - it should be *true*.
Sure - needs to be fixed
SVN trunk update issue
Hi I'm trying to update the trunk with SVN and getting the following: svn: Checksum mismatch while updating 'rt/core/src/main/java/org/apache/cxf/feature/transform/XSLTInInterceptor.java'; expected: '8031abcfbea05e46f6a2b1dab3020956', actual: 'd41d8cd98f00b204e9800998ecf8427e' Any ideas how this can be fixed ? Cheers, Sergey
Re: SVN trunk update issue
On 27/11/12 13:27, Romain Manni-Bucau wrote: Hi, do you use us or eu svn? maybe switch to us if you use eu proxy Switching between the two addresses does not help, must be something else I guess Thanks, Sergey *Romain Manni-Bucau* *Twitter: @rmannibucauhttps://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/27 Sergey Beryozkinsberyoz...@gmail.com Hi I'm trying to update the trunk with SVN and getting the following: svn: Checksum mismatch while updating 'rt/core/src/main/java/org/** apache/cxf/feature/transform/**XSLTInInterceptor.java'; expected: '** 8031abcfbea05e46f6a2b1dab30209**56', actual: '** d41d8cd98f00b204e9800998ecf842**7e' Any ideas how this can be fixed ? Cheers, Sergey
Re: SVN trunk update issue
I did a completely fresh checkout with the local updates patched and applied to the new trunk and it worked, does not work against the old trunk though, guess I had it corrupted somehow... Cheers, Sergey On 27/11/12 13:32, Sergey Beryozkin wrote: On 27/11/12 13:27, Romain Manni-Bucau wrote: Hi, do you use us or eu svn? maybe switch to us if you use eu proxy Switching between the two addresses does not help, must be something else I guess Thanks, Sergey *Romain Manni-Bucau* *Twitter: @rmannibucauhttps://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/27 Sergey Beryozkinsberyoz...@gmail.com Hi I'm trying to update the trunk with SVN and getting the following: svn: Checksum mismatch while updating 'rt/core/src/main/java/org/** apache/cxf/feature/transform/**XSLTInInterceptor.java'; expected: '** 8031abcfbea05e46f6a2b1dab30209**56', actual: '** d41d8cd98f00b204e9800998ecf842**7e' Any ideas how this can be fixed ? Cheers, Sergey
Re: CXF Continuations Not Portable Issue
Hi Richard
On 26/11/12 12:15, Richard Opalka wrote:
Dear CXF developers,
I'm analyzing our recent CXF continuation related failures in CI
and I identified the following problem:
SVN commit id: 1409193
introduced
---
@@ -57,32 +57,30 @@ public class Servlet3ContinuationProvider implements
ContinuationProvider {
if (continuation == null) {
continuation = new Servlet3Continuation();
+} else {
+continuation.startAsyncAgain();
}
return continuation;
}
---
method call that causes our JBossWeb to throw IllegalStateException.
According to startAsync() javadoc for Throws:
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#startAsync%28%29
---
Throws:
IllegalStateException - if this request is within the scope of a
filter or servlet that does not support asynchronous operations (that
is, isAsyncSupported() returns false), or if this method is called again
without any asynchronous dispatch (resulting from one of the
AsyncContext#dispatch methods), is called outside the scope of any such
dispatch, or is called again within the scope of the same dispatch, or
if the response has already been closed
---
JBossWeb is strictly following these ISE guidelines (is not lenient
like e.g. Jakarta Tomcat).
What would you say about
Subsequent invocations of this method, or its overloaded variant, will
return the same AsyncContext instance, reinitialized as appropriate. ?
Without this call I can not have the test doing multiple timeouts on the
same continuation working...
The last issue that I identified with Servlet3ContinuationProvider is
the isNew flag has incorrect initial value - it should be *true*.
Sure - needs to be fixed
Thanks, Sergey
Cheers,
Rio
Re: CXF Continuations Not Portable Issue
More comments below,
On 26/11/12 12:21, Sergey Beryozkin wrote:
Hi Richard
On 26/11/12 12:15, Richard Opalka wrote:
Dear CXF developers,
I'm analyzing our recent CXF continuation related failures in CI
and I identified the following problem:
SVN commit id: 1409193
introduced
---
@@ -57,32 +57,30 @@ public class Servlet3ContinuationProvider implements
ContinuationProvider {
if (continuation == null) {
continuation = new Servlet3Continuation();
+ } else {
+ continuation.startAsyncAgain();
}
return continuation;
}
---
method call that causes our JBossWeb to throw IllegalStateException.
According to startAsync() javadoc for Throws:
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#startAsync%28%29
---
Throws:
IllegalStateException - if this request is within the scope of a
filter or servlet that does not support asynchronous operations (that
is, isAsyncSupported() returns false), or if this method is called again
without any asynchronous dispatch (resulting from one of the
AsyncContext#dispatch methods), is called outside the scope of any such
dispatch, or is called again within the scope of the same dispatch, or
if the response has already been closed
---
I actually read is called again within the scope of the same dispatch
differently, a continuation thread is dispatched one or many times, but
if you get startAsync() called within a specific thread dispatch more
than once then it is indeed an ISE.
I guess my reading may be wrong - but the fact that I get the tests
working with Tomcat and Jetty might imply that may be JBossWeb might
treat this case specifically ?
JBossWeb is strictly following these ISE guidelines (is not lenient
like e.g. Jakarta Tomcat).
CC-ing Bill too - the feedback is welcome
Finally, what continuation tests are actually failing, can you provide
more info please
Cheers, Sergey
What would you say about
Subsequent invocations of this method, or its overloaded variant, will
return the same AsyncContext instance, reinitialized as appropriate. ?
Without this call I can not have the test doing multiple timeouts on the
same continuation working...
The last issue that I identified with Servlet3ContinuationProvider is
the isNew flag has incorrect initial value - it should be *true*.
Sure - needs to be fixed
Thanks, Sergey
Cheers,
Rio
Re: CXF Continuations Not Portable Issue
Hi Richard
On 26/11/12 12:29, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 01:21 PM, Sergey Beryozkin wrote:
Hi Richard
On 26/11/12 12:15, Richard Opalka wrote:
Dear CXF developers,
I'm analyzing our recent CXF continuation related failures in CI
and I identified the following problem:
SVN commit id: 1409193
introduced
---
@@ -57,32 +57,30 @@ public class Servlet3ContinuationProvider implements
ContinuationProvider {
if (continuation == null) {
continuation = new Servlet3Continuation();
+} else {
+continuation.startAsyncAgain();
}
return continuation;
}
---
method call that causes our JBossWeb to throw IllegalStateException.
According to startAsync() javadoc for Throws:
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#startAsync%28%29
---
Throws:
IllegalStateException - if this request is within the scope of a
filter or servlet that does not support asynchronous operations (that
is, isAsyncSupported() returns false), or if this method is called again
without any asynchronous dispatch (resulting from one of the
AsyncContext#dispatch methods), is called outside the scope of any such
dispatch, or is called again within the scope of the same dispatch, or
if the response has already been closed
---
JBossWeb is strictly following these ISE guidelines (is not lenient
like e.g. Jakarta Tomcat).
What would you say about
Subsequent invocations of this method, or its overloaded variant, will
return the same AsyncContext instance, reinitialized as appropriate. ?
Without this call I can not have the test doing multiple timeouts on the
same continuation working...
Makes sense to me. I had a look to our JBoss Web code again and I
noticed one suspicious line there - I'm going to discuss it with our folks.
Oh, thanks for that, I've just sent one more follow-up, sorry about the
noise, should've waited :-)
Cheers, Sergey
The last issue that I identified with Servlet3ContinuationProvider is
the isNew flag has incorrect initial value - it should be *true*.
Sure - needs to be fixed
Thanks
Thanks, Sergey
Cheers,
Rio
Re: CXF Continuations Not Portable Issue
Hi Richard
On 26/11/12 15:05, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 02:57 PM, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 01:31 PM, Sergey Beryozkin wrote:
Hi Richard
On 26/11/12 12:29, Richard Opalka wrote:
Hi Sergey,
On 11/26/2012 01:21 PM, Sergey Beryozkin wrote:
Hi Richard
On 26/11/12 12:15, Richard Opalka wrote:
Dear CXF developers,
I'm analyzing our recent CXF continuation related failures in CI
and I identified the following problem:
SVN commit id: 1409193
introduced
---
@@ -57,32 +57,30 @@ public class Servlet3ContinuationProvider
implements
ContinuationProvider {
if (continuation == null) {
continuation = new Servlet3Continuation();
+} else {
+continuation.startAsyncAgain();
}
return continuation;
}
---
method call that causes our JBossWeb to throw IllegalStateException.
According to startAsync() javadoc for Throws:
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#startAsync%28%29
---
Throws:
IllegalStateException - if this request is within the scope of a
filter or servlet that does not support asynchronous operations (that
is, isAsyncSupported() returns false), or if this method is called
again
without any asynchronous dispatch (resulting from one of the
AsyncContext#dispatch methods), is called outside the scope of any such
dispatch, or is called again within the scope of the same dispatch, or
if the response has already been closed
---
JBossWeb is strictly following these ISE guidelines (is not lenient
like e.g. Jakarta Tomcat).
What would you say about
Subsequent invocations of this method, or its overloaded variant, will
return the same AsyncContext instance, reinitialized as appropriate. ?
Without this call I can not have the test doing multiple timeouts on the
same continuation working...
Makes sense to me. I had a look to our JBoss Web code again and I
noticed one suspicious line there - I'm going to discuss it with our
folks.
Oh, thanks for that, I've just sent one more follow-up, sorry about the
noise, should've waited :-)
Let's see what our Servlet experts will say -
https://issues.jboss.org/browse/JBWEB-256
Our JBoss Web guru is saying JBoss Web impl. is correct.
I'd appreciate to see more concrete clarifications, regarding the
following two points:
- the documentation clearly says that repeated calls of startAsync()
return the same instance.
- what does it mean to have called startAsync() called on the same
dispatch, does it apply to a current thread dispatch or to the whole
suspended continuation process ?
To be honest, the positive statement on the multiple startAsync calls
makes me think the ISE case applies to this method called multiple times
during the same thread dispatch...
Thanks, Sergey
Cheers, Sergey
The last issue that I identified with Servlet3ContinuationProvider is
the isNew flag has incorrect initial value - it should be *true*.
Sure - needs to be fixed
Thanks
Thanks, Sergey
Cheers,
Rio
Re: svn commit: r1412802
Hi Christian What is the auto-detection and is there any reason JAX-RS endpoints can not benefit of this possible enhancement ? Thanks, Sergey On 23/11/12 09:50, cschnei...@apache.org wrote: Author: cschneider Date: Fri Nov 23 09:50:25 2012 New Revision: 1412802 URL: http://svn.apache.org/viewvc?rev=1412802view=rev Log: DOSGI-128 Small refactoring in preparation of the auto detection of jaxws and jaxb services
Re: svn commit: r1412802
Hi On 23/11/12 10:15, Christian Schneider wrote: Hi Sergey, the idea is to auto detect if a service is a JAXWS service by detecting the @WebService annotation. So if this annotation is found then the service would default to JAXWS/JAXB instead of Simple/Aegis if no intent overrides this. The corresponding issue is: https://issues.apache.org/jira/browse/DOSGI-128 OK, see what you mean, thanks This may also be possible for JAXRS. Can you open an issue and document how a jaxrs service should be detected and what the settings then should be? In case of JAX-RS, it has to be '@javax.ws.rs.Path' annotation that can identify a service bean as a JAX-RS root resource class...Alternatively the service bean itself can be 'javax.ws.rs.core.Application'. I guess I can definitely get the code enhanced to manage 'Application' OSGI services, however, what about the auto-detection and the actual endpoint address ? Will the endpoint be bound to HTTP Service or will it be an absolute (default) URI and thus Jetty will do an internal HTTP support ? Thanks, Sergey Christian On 11/23/2012 10:59 AM, Sergey Beryozkin wrote: Hi Christian What is the auto-detection and is there any reason JAX-RS endpoints can not benefit of this possible enhancement ? Thanks, Sergey On 23/11/12 09:50, cschnei...@apache.org wrote: Author: cschneider Date: Fri Nov 23 09:50:25 2012 New Revision: 1412802 URL: http://svn.apache.org/viewvc?rev=1412802view=rev Log: DOSGI-128 Small refactoring in preparation of the auto detection of jaxws and jaxb services
Re: CXF-DOSGI: Default address and default host and port
Hi Christian, On 23/11/12 13:42, Christian Schneider wrote: I will start the issue Provide a default address for services (see https://issues.apache.org/jira/browse/DOSGI-127) soon. The idea is to provide a default servlet transport based address in case no address service property is defined. I found that currently we already provide a default address based on the jetty transport. The disadvantage is that this needs a host and port number that have to be configured either on the service or for the cxf dosgi dsw bundle. So two questions: 1) Is it ok to switch to the servlet transport as the new default? 2) How much backwards compatibility do we need? About 2) I found that we have default.host and default.port that were to be configured using the config admin service. When looking closer into the code I found that the code supporting this is not attached to the config admin service. So it looks like the default settings currently can not be configured at all. So only the hard coded defaults of localhost and 9090 work. For the service we have the Constants.WS_PORT_PROPERTY(org.apache.cxf.ws.port) that can be set in the service. So do we need to support these configs or can I simply remove the whole code concerning this when I switch to the servlet transport? If no backwards compatibility is needed then a lot of code could be removed. For example the code for determining the localhost address and the whole handlerProperties for the configTypeHandlers. IMHO 2) (using HTTP Service by default) is the best option for teh auto-detection case. Note that the get default address is only used on the ws.address or rs.address path, from POJO handers which create Jetty-transport based endpoints. If we have ws.http.context or rs.http.context properties, HttpService configuration handers are invoked and this Jetty-transport default address construction is bypassed. So I propose that in case of the auto-detection simply use HttpService handlers, they have the code for constructing the default servlet context root too from the name of the class. Cheers, Sergey Christian
Re: svn commit: r1412802
Hi, I'll probably stay away for a moment from getting JAX-RS endpoints auto-detected given that the default context path will not be really user friendly in such cases (ex, 'my_company_Books', etc) though this can work ok in a end-to-end WS case... However supporting JAX-RS Application OSGI services will make sense, something I can work upon in time... The question is, are we prepared to get DSW depending on JAX-WS JAX-RS API ? I don't see any major issues at the moment, it probably will do OK Thanks, Sergey On 23/11/12 12:24, Christian Schneider wrote: In the DOSGI-128 issue I do not plan to support a default address. There is anothe issue for it though: https://issues.apache.org/jira/browse/DOSGI-127 I planned to use the servlet transport by default and somehow create the default address from the Service interface. Not sure how to support more than one instance of a service endpoint for the same interface though. Still we could simply start with that. Christian Am 23.11.2012 11:52, schrieb Sergey Beryozkin: Hi On 23/11/12 10:15, Christian Schneider wrote: Hi Sergey, the idea is to auto detect if a service is a JAXWS service by detecting the @WebService annotation. So if this annotation is found then the service would default to JAXWS/JAXB instead of Simple/Aegis if no intent overrides this. The corresponding issue is: https://issues.apache.org/jira/browse/DOSGI-128 OK, see what you mean, thanks This may also be possible for JAXRS. Can you open an issue and document how a jaxrs service should be detected and what the settings then should be? In case of JAX-RS, it has to be '@javax.ws.rs.Path' annotation that can identify a service bean as a JAX-RS root resource class...Alternatively the service bean itself can be 'javax.ws.rs.core.Application'. I guess I can definitely get the code enhanced to manage 'Application' OSGI services, however, what about the auto-detection and the actual endpoint address ? Will the endpoint be bound to HTTP Service or will it be an absolute (default) URI and thus Jetty will do an internal HTTP support ? Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Variables from type class dont work
Hi On 21/11/12 08:20, Janosch Weber wrote: Hello, I develop with Apache CXF Distributed OSGi. Everything works fine, except if I use variables from type Class. A Service with these variables cannot used remotly. I got the same Exception and behaviour described in this BUG: https://issues.apache.org/jira/browse/CXF-3613 This BUG was fixed in normal Apache CXF in october 2012. I think it was not fixed in Distibuted OSGi (The last release was in april 2012). Is it possible to get a newer running singledistribution-bundle? The nightly snapshot don't work at my system. When is the next release of Distributed OSGi? Is this fixed? Christian has upgraded DOSGi CXF trunk to depend on CXF 2.7.0 and DOSGi 1.4 release will be done in a week or two. Next, once CXF 2.7.1 is out, you will be able replace CXF 2.7.0 within DOSGi multibundle distro with CXF 2.7.1 - perhaps DOSGI 1.4 itself can be released with CXF 2.7.1... Sergey Greets
Re: svn commit: r1411506 - /cxf/trunk/api/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
Hi
On 20/11/12 02:40, Freeman Fang wrote:
Hi Dan,
But if on unix/linux platform, if we have \r\n, it interpret as two new line, which can
cause some service providers can't handle the request, I think what we want should be a new
line here, so use system property line.separator should be OK, please see the initial
description from CXF-4482[1].
IMHO it has to be 'attachment.line.separator' (to support the legacy
providers or the ones which can not handle CR/LF) contextual property,
using system property just won't work because we can have Unix on one
end, Win on the other end, or vice versa
Sergey
Btw, seems any jira update can't send out mail notification now.
[1]https://issues.apache.org/jira/browse/CXF-4482
Freeman
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-11-20, at 上午10:31, Daniel Kulp wrote:
Actually, more importantly, this makes the payload different depending on if
its from Unix or Windows. According to the mid spec:
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
(section 7.2.1)
it should always be a CRLF, so the code would be updated to always use that for
the attachment boundaries.
Dan
On Nov 19, 2012, at 9:21 PM, Daniel Kulpdk...@apache.org wrote:
Umm… don't use anything from sun.* packages. You can use
org.apache.cxf.common.util.SystemPropertyAction if that works.
Dan
On Nov 19, 2012, at 8:56 PM, ff...@apache.org wrote:
Author: ffang
Date: Tue Nov 20 01:56:17 2012
New Revision: 1411506
URL: http://svn.apache.org/viewvc?rev=1411506view=rev
Log:
[CXF-4482]get line.separator system property ensure CR/LF works across platforms
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
Modified:
cxf/trunk/api/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java?rev=1411506r1=1411505r2=1411506view=diff
==
---
cxf/trunk/api/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
(original)
+++
cxf/trunk/api/src/main/java/org/apache/cxf/attachment/AttachmentSerializer.java
Tue Nov 20 01:56:17 2012
@@ -153,7 +153,9 @@ public class AttachmentSerializer {
encoding = UTF-8;
}
StringWriter writer = new StringWriter();
-writer.write(\n);
+String lineSeparator = java.security.AccessController.doPrivileged(
+new sun.security.action.GetPropertyAction(line.separator));
+writer.write(lineSeparator);
writer.write(--);
writer.write(bodyBoundary);
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: CXF DOSGi: Idea for replacement of IntentMap reading
Hi Christian On 16/11/12 06:59, Christian Schneider wrote: Currently we manually use spring-dm to read the IntentMap from the dsw bundle as well as from bundles implementing or using OSGi services. This has some drawbacks: - As IntentMap is defined in the dsw bundle the user bundles depend on the dsw bundle - User bundles and dsw bundle depend on spring dm - It is not possible to use other ways to define intents (e.g. blueprint or by hand) So I propose to replace this with a different aproach: First I would like to replace the IntentMap with a simple HashMap so we do not need a depdendency on dsw. To also avoid to directly use spring dm I propose we define the default intents in java code. For user defined intents we could use a service. So the user bundles would define the intent map themselves and offer it as an OSGi service. The dsw bundle then would check for these services. As the Map is not a unique identifier we could use a property to mark a service as a intent map. The solution has one drawback though. It is incompatible with the current way of defining intents. Do you think this is a problem? Do you see any other problems with proposed solution? Btw. I think the current intent map reading has a bug. We use getIntentMap for loading the default intents as well as the use intents. Inside getIntentMap we cache the loaded IntentMap. So only the first call will load something. So I am not sure if user intents work at all at the moment. Is this correct? See also: https://issues.apache.org/jira/browse/DOSGI-86 https://issues.apache.org/jira/browse/DOSGI-115 I'm not sure anyone uses custom intents, there were some ideas from users on how to get custom intents, suggesting how it can be done based on the existing approach but it was too difficult as far as I recall. So what you suggest seems more flexible and OSGI-friendly. Typically, reacting to an intent means adding a CXF-level interceptor. How will it work with your approach ? Cheers, Sergey Christian -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: WebClient….query(_wadl) not working...
Hi Dan On 02/11/12 20:30, Daniel Kulp wrote: Sergey, I've noticed the last couple days that the full build that normally take about 6 minutes on my machine are taking upwards of 7.5 minutes or so. The problem seems to be the LoadDistributorTest and Failover tests in the jaxrs system tests. Looking at it, the setup methods are failing as the line: Response r = WebClient.create(address).query(_wadl).get(); is failing to generate a GET request with the _wadl query param. Wireshark is showing: GET /rest HTTP/1.1 Content-Type: */* Accept: */* User-Agent: Apache CXF 2.7.1-SNAPSHOT Cache-Control: no-cache Pragma: no-cache Host: localhost:9002 Connection: keep-alive HTTP/1.1 404 Not Found Content-Length: 0 Date: Fri, 02 Nov 2012 20:29:31 GMT Server: Jetty(8.1.7.v20120910) I think you've touched something there. Can you take a look? I did, the consequence of trying to get ParamConverterProviders supported on the client side :-), thanks for the above info, helped me to fix the regression quickly... Cheers, Sergey
Re: goodbye
Hi Tomasz On 31/10/12 11:21, Tomasz Oponowicz wrote: Hi all, You probably notice my minor contribution for one year or more. I have to leave Apache CXF because lack of spare time. You don't have to say 'goodbye' if you have no spare time :-), many committers who have no spare time do not contribute regularly It has been an amazing working with you, during GSOC and after. I would especially like to thank Sergey for helping me with project. Thank you, LogBrowser was an interesting project, and I'm still looking forward to it growing into a light-weight management console with some cool UI features. Goodbye. Talk to you later :-) Cheers, Sergey With best wishes, Tomasz Oponowicz
Re: CXF-DSOGI: Proposal to switch logging to slf4j
On 31/10/12 14:45, Daniel Kulp wrote: On Oct 31, 2012, at 7:15 AM, Christian Schneiderch...@die-schneider.net wrote: Hi all, currently we use a mix of log4j and util logging in CXF-DOSGi. That definitely should be fixed. Not sure why we would have had a mix like that. I just saw that zookeeper changed their logging to slf4j. It seems their current release is not completely correct but I am sure they will soon work fine with just slf4j as an import. As CXF-DOSGi only runs on OSGi and slf4j is the simplest way to support logging on OSGi I propose we switch the logging to slf4j. So we are in line with Apache Karaf and Zookeeper. The main concern I would have had is if any of the CXF-DOSGi code used the Messages.properties resource bundles for the logging messages like the main CXF code does. However, I just did a quick search through the DOSGi code and don't see any of them. Apparently not used there. it is a good point though. I wonder if the CXF style should be preserved in CXF-based DSW ? May be no one will notice, Cheers, Sergey Thus, I don't really have any major objection to it. Dan Please also see the two related issues in jira: https://issues.apache.org/jira/browse/DOSGI-135 https://issues.apache.org/jira/browse/DOSGI-132 So what do you think? Best regards Christian
Re: Request for feedback on CXF DOSGI Refactoring of TopologyManager
Hi Christian On 26/10/12 13:45, Christian Schneider wrote: Currently the topology manager project in CXF DOSGI contains a lot of cycles between the classes. The code is also rather difficult to understand. I have prepared a refactoring to resolve the cycles and make the code a lot more readable. As the changes are pretty big I will first add a patch and wait for some feedback. https://issues.apache.org/jira/browse/DOSGI-134 I hope David will find some time to look into it - I've never dealt with TopologyManager replacing the older code, so as far as I'm concerned, +1 to making things easier to understand/read, great to see some real quality updates being applied to the trunk :-) Sergey Best regards Christian
Re: Can we delete the cxf-dosgi systests dir ?
Hi Christian On 23/10/12 13:53, Christian Schneider wrote: In CXF DOSGI we currently have two directories with system tests: systests - This is currently not executed in the build. The pom is still on 1.3-SNAPSHOT systests2 - This is used in the build Is systests just an old dir or do we still need it? If it is not needed anymore I propose to delete the systests dir and rename systests2 to systests. AFAIK, systests are more complete but have been tricky to run properly due to their dependence on the servicemix OSGI test suite support. David created systests2 for paxweb test bundle /etc be used instead. Perhaps the tests can be 'merged' from both folders, with those of 'systests' which have not been migrated yet to be used with paxweb to be ignored for now ? Sergey Christian
Re: encrypting tmp files generated by CachedOutputStream?
On 18/10/12 15:38, Aki Yoshida wrote: Hi, but using a bus or EP prop, we will need a new method in COS to pass this encryption option. And we will need to change the current code in many places to make sure that this new method is used to prevent an unintended plain output written from somewhere. So, I see some drawbacks. Maybe, we can have a global option plus an instance level overwriting option? This would be similar to how the temp root directory is currently set in COS. +1 Cheers, Sergey @Dan we can add that option too. thanks. aki 2012/10/18 Freeman Fangfreeman.f...@gmail.com: Yeah, endpoint property should be good. － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: http://weibo.com/u/1473905042 On 2012-10-18, at 下午9:22, Willem jiang wrote: Using the system property will effect CXF instance across the JVM. It could be good if we can do it on the bus level. -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: willemjiang On Thursday, October 18, 2012 at 9:05 PM, Aki Yoshida wrote: Hi Freeman, yes. This should be an option and disabled by default. I am thinking about introducing a system property org.apache.cxf.io.CachedOutputStream.something to set the cipher transformation name to enable this option. regards, aki 2012/10/18 Freeman Fangfreeman.f...@gmail.com (mailto:freeman.f...@gmail.com): Hi Aki, Basically I'm +1 for this good idea. Just a little bit concern about the performance impact. Could we add a flag to enable this encryption behavior? By default the value is false, so keep same behavior as is, and users can explicitly enable it if they need a higher secure runtime. My 2 cents. Best Regards Freeman － Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: http://weibo.com/u/1473905042 On 2012-10-18, at 下午8:31, Aki Yoshida wrote: Hi, There is a concern that these temporary files are written out to the file system without any protection. And I was wondering if we can add an option to enable encryption for the stream output and keep the key in the COS instance so that only that COS instance can later read the data from the file system. Is there any security concern to this approach? If none, I will go ahead and add this option. thanks. regards, aki
Re: CXF 2.7 and Rest service
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'bookservice': Invocation of init method failed; nested exception is org.apache.cxf.service.factory.ServiceConstructionException at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1422) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:518) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:282) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:204) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4791) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5285) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.cxf.service.factory.ServiceConstructionException at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:201) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1546) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1487) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1419) ... 22 more Caused by: java.lang.NullPointerException at org.apache.cxf.ws.discovery.listeners.WSDiscoveryServerListener.startServer(WSDiscoveryServerListener.java:64) at org.apache.cxf.bus.managers.ServerLifeCycleManagerImpl.startServer(ServerLifeCycleManagerImpl.java:61) at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:146) at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:192) ... 29 more paź 17, 2012 6:48:01 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Error listenerStart paź 17, 2012 6:48:01 PM org.apache.catalina.core.StandardContext startInternal SEVERE: Context [/HelloImplRestWeb] startup failed due to previous errors paź - Regards Marcin Kasinski http://itzone.com.pl -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-2-7-and-Rest-service-tp5716862.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [DISCUSS] 2.4.x EOL?
+1 Sergey On Oct 6, 2012, at 5:54 AM, Daniel Kulpdk...@apache.org wrote: With 2.7.0 coming out real soon (voting on now), I'd like to discuss whether we should make 2.4.10 the last for the 2.4.x line. 2.4.0 was released 18 months ago. Last month, 2.4.x accounted for about 12% of the downloads from central, but that's inline with the 11% for 2.3.x which we don't support. (Almost 50% are on 2.6.x already. Great to see people updating and keeping current.) Of the 12%, less than 10% of those were for 2.4.9 and 2.4.8 (almost 75% were for 2.4.4 and lower) which shows very few people updating on the 2.4.x line (which is concerning due to the security implications) or if they are updating, they are moving to the more recent branches. Thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Apache CXF 2.7.0
+1 Sergey On 06/10/12 12:43, Daniel Kulp wrote: It's been 6 months since 2.6.x was first released and thus time for the next big thing. :-) We have several new features including two new transports (UDP and an Async based HTTP transport), WS-Discovery support, many JAX-RS enhancements while on the road to 2.0 support, etc…. The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-098/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.0 Migration guide is at: http://cxf.apache.org/docs/27-migration-guide.html Vote will be open for 72 hours. Here is my +1. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Release Apache CXF 2.4.10, 2.5.6, 2.6.3
+1 Sergey On 06/10/12 12:40, Daniel Kulp wrote: We've resolved over 48 issues since 2.6.2 with a bunch of them fairly important. List of issues: 2.4.10 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12322966 2.5.6 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12322965 2.6.3 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12322964 The Maven staging areas are at: 2.4.10 https://repository.apache.org/content/repositories/orgapachecxf-093/ 2.5.6 https://repository.apache.org/content/repositories/orgapachecxf-094/ 2.6.3 https://repository.apache.org/content/repositories/orgapachecxf-095/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.10 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.6 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.3 This vote will be open for at least 72 hours. Here's my +1. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
New ContinuationCallback interface
Hi I'd like to add a new ContinuationCallback [1] interface for getting it easier to track various invocation status updates. Particularly it would make it possible for the JAX-RS frontend to support CompletionCallback [2] but I think it can also be of use to CXF applications not relying on JAX-RS. At the moment this interface is a work in progress, supports only two callback methods. We can improve that when we have more ideas what to make available to the specific callback methods... Ideally I'd like to merge it now, before 2.7.0 is out, this is the last bit I'd like to do for JAX-RS 2.0 AsyncResponse and then move to working on other things... The code seems safe as the continuation based tests are running OK, but I can wait till after 2.7.0 is out too Cheers, Sergey [1] https://issues.apache.org/jira/browse/CXF-4531 [2] http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/container/CompletionCallback.html
Re: Some issues with logging and tests
On 30/09/12 14:33, Benson Margulies wrote: I've got a case, for which I'm about to file a JIRA, in which I think that it's important that a particular situation leads to a log message with some minimal content with a particular log level. Have we got any tests for cases like this? I'm thinking about wiring up some sort of test rig for intercepting log messages for the purpose. Meanwhile, this particular case is perhaps worth a moment's discussion. In JAX-RS, consider the following circumstance: A resource accepts a parameter of bean type, and a mapper (in my case, the Jackson json mapper) is responsible for mapping from the incoming content to the bean. The incoming headers specify 'accept: application/json', since that's what the function (normally) produces. Now, someone debugging a python client sends a json blob with a misspelled item in it. The mapper throws an exception. WebApplicationExceptionMapper catches it and maps it to a 500, accompanying the action with a log message at DEBUG. The client gets a naked '500', no message anywhere. I suspect, but I'm not sure, that the mapper would send back some backtracey verbiage if the accept header were no so restrictive. On the one hand, a WARN would be handy, as it's a pain to have to go adjust the logging config just to see why the client isn't working. On the other hand, a production application might get thousands of malformed inputs a day, and might not want all this traffic in the log. Do we have a design principle (written down?) about how we decide what should be logged non-DEBUG? Should errors resulting from ill-behaved clients get that treatment? If not, I shouldn't write a JIRA or change any code here. As I said in the previous message, it is to do with the over-optimization of WebApplicationExceptionMapper. By the way, I'm not sure I agree with the fix to CXF-4528. This is now getting complicated: one has to install a fault logger to get a stack trace, and, on top of that, the logging will happen twice, if property is set and FINE is active... Let me propose something slightly different: if the fault logger is installed and it handled the exception: then do nothing else, the logger can log or ignore the error message, if not - do print the warn message because a number of times this issue has been raised - and this can be optimized if needed by turning 'printStackTrace' to false. Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Seeming problem with definition of JAX-RS exception mappers
Hi Benson On 30/09/12 15:22, Benson Margulies wrote: An exception mapper is for the entire service, not for a resource. And it has no access to the @Produces of a resource, nor to request headers. Doesn't this make it mighty difficult to be well-behaved? You can inject @Context HttpHeaders and then get the list of acceptable types (sorted in the ascending order). That should help with setting the right content-type Cheers, Sergey
Re: Some issues with logging and tests
Hi On 30/09/12 18:03, Benson Margulies wrote: On Sun, Sep 30, 2012 at 12:59 PM, Sergey Beryozkinsberyoz...@gmail.com wrote: On 30/09/12 14:33, Benson Margulies wrote: I've got a case, for which I'm about to file a JIRA, in which I think that it's important that a particular situation leads to a log message with some minimal content with a particular log level. Have we got any tests for cases like this? I'm thinking about wiring up some sort of test rig for intercepting log messages for the purpose. Meanwhile, this particular case is perhaps worth a moment's discussion. In JAX-RS, consider the following circumstance: A resource accepts a parameter of bean type, and a mapper (in my case, the Jackson json mapper) is responsible for mapping from the incoming content to the bean. The incoming headers specify 'accept: application/json', since that's what the function (normally) produces. Now, someone debugging a python client sends a json blob with a misspelled item in it. The mapper throws an exception. WebApplicationExceptionMapper catches it and maps it to a 500, accompanying the action with a log message at DEBUG. The client gets a naked '500', no message anywhere. I suspect, but I'm not sure, that the mapper would send back some backtracey verbiage if the accept header were no so restrictive. On the one hand, a WARN would be handy, as it's a pain to have to go adjust the logging config just to see why the client isn't working. On the other hand, a production application might get thousands of malformed inputs a day, and might not want all this traffic in the log. Do we have a design principle (written down?) about how we decide what should be logged non-DEBUG? Should errors resulting from ill-behaved clients get that treatment? If not, I shouldn't write a JIRA or change any code here. As I said in the previous message, it is to do with the over-optimization of WebApplicationExceptionMapper. By the way, I'm not sure I agree with the fix to CXF-4528. This is now getting complicated: one has to install a fault logger to get a stack trace, and, on top of that, the logging will happen twice, if property is set and FINE is active... That was the situation *before* I changed it. As of now, if there's no fault logger, you have a stack trace if you make the call to turn on the stack trace. If you *do* decide to put in a fault logger, you decide whether to dump stack traces from it. Let me propose something slightly different: if the fault logger is installed and it handled the exception: then do nothing else, the logger can log or ignore the error message, if not - do print the warn message because a number of times this issue has been raised - and this can be optimized if needed by turning 'printStackTrace' to false. That's what I did, except that I left it at 'FINE'. If I messed up the logic let's look at the code together. Sounds good, what do you think of r1392082 ? Basically, right now the logic is as follows: If the fault listener is available and has indicated it did handle the call - then do nothing else, otherwise - do either WARN (default) or FINE print stack trace message I guess there could be more variations (as to what to do when the fault listener has handled or has not handled the call - the logic can be improved), but I guess I'd like to make sure the user can get a print stack trace without having to install a listener... Thanks, Sergey
Re: Some issues with logging and tests
Also updated the mapper to optionally report an error message (can be customized by extending the mapper) by setting an 'addMessageToResponse' property - which is ignored if the exception already contains Response with a non-null entity Sergey On 30/09/12 18:39, Sergey Beryozkin wrote: Hi On 30/09/12 18:03, Benson Margulies wrote: On Sun, Sep 30, 2012 at 12:59 PM, Sergey Beryozkinsberyoz...@gmail.com wrote: On 30/09/12 14:33, Benson Margulies wrote: I've got a case, for which I'm about to file a JIRA, in which I think that it's important that a particular situation leads to a log message with some minimal content with a particular log level. Have we got any tests for cases like this? I'm thinking about wiring up some sort of test rig for intercepting log messages for the purpose. Meanwhile, this particular case is perhaps worth a moment's discussion. In JAX-RS, consider the following circumstance: A resource accepts a parameter of bean type, and a mapper (in my case, the Jackson json mapper) is responsible for mapping from the incoming content to the bean. The incoming headers specify 'accept: application/json', since that's what the function (normally) produces. Now, someone debugging a python client sends a json blob with a misspelled item in it. The mapper throws an exception. WebApplicationExceptionMapper catches it and maps it to a 500, accompanying the action with a log message at DEBUG. The client gets a naked '500', no message anywhere. I suspect, but I'm not sure, that the mapper would send back some backtracey verbiage if the accept header were no so restrictive. On the one hand, a WARN would be handy, as it's a pain to have to go adjust the logging config just to see why the client isn't working. On the other hand, a production application might get thousands of malformed inputs a day, and might not want all this traffic in the log. Do we have a design principle (written down?) about how we decide what should be logged non-DEBUG? Should errors resulting from ill-behaved clients get that treatment? If not, I shouldn't write a JIRA or change any code here. As I said in the previous message, it is to do with the over-optimization of WebApplicationExceptionMapper. By the way, I'm not sure I agree with the fix to CXF-4528. This is now getting complicated: one has to install a fault logger to get a stack trace, and, on top of that, the logging will happen twice, if property is set and FINE is active... That was the situation *before* I changed it. As of now, if there's no fault logger, you have a stack trace if you make the call to turn on the stack trace. If you *do* decide to put in a fault logger, you decide whether to dump stack traces from it. Let me propose something slightly different: if the fault logger is installed and it handled the exception: then do nothing else, the logger can log or ignore the error message, if not - do print the warn message because a number of times this issue has been raised - and this can be optimized if needed by turning 'printStackTrace' to false. That's what I did, except that I left it at 'FINE'. If I messed up the logic let's look at the code together. Sounds good, what do you think of r1392082 ? Basically, right now the logic is as follows: If the fault listener is available and has indicated it did handle the call - then do nothing else, otherwise - do either WARN (default) or FINE print stack trace message I guess there could be more variations (as to what to do when the fault listener has handled or has not handled the call - the logic can be improved), but I guess I'd like to make sure the user can get a print stack trace without having to install a listener... Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Async methods for JAX-RS WebClient
I went ahead and populated AsyncInvoker, as well as added another shortcut directly to WebClient, to support an async post call. Dan, have a look please, One thing that I can have a look later is making sure the retry calls work in case of async call failures, plus add few more minor enhancements, overall though it seems it looks OK Thanks, Sergey On 23/09/12 18:56, Sergey Beryozkin wrote: On 23/09/12 18:14, Sergey Beryozkin wrote: Hi Dan On 21/09/12 19:27, Daniel Kulp wrote: Sergey, (and others) I just committed some initial support for some async methods to the WebClient. Can you take a look at that change and make sure it all makes sense? I only have a get method in there right now, but it should be fairly trivial now to add the others that would map to the new doInvokeAsync method. Just want to make sure it looks ok first. It is a very good start, thanks for starting to look into it. I think I will push some of the code to AbstractClient once I get a better understanding of what is going on, for proxies to get the async support too. Other than that, I wonder if we should introduce an async() method which would return http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html that would let us support the async style of invocation completely in line with the way JAX-RS 2.0 does it, example: WebClient wc = WebClient.create(address); wc.async().get(callback); // etc (async() in JAX-RS 2.0 is in http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/clisystests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRS20ClientServerBookTest.javaent/Invocation.Builder.html) I added an empty AsyncInvoker implementation, with async().get(InvocationCallback) also working for now :-). Wow, it's really happening thanks to the addition of the HTTP async transport :-) Thanks, Sergey In addition to that we can indeed add simple shortcuts, one per every main method, or for those which are more likely to participate in async flows, say for get/post/put, to let users 'save' on typing 'async()' for few mainstream cases I'm a little concerned about the state objects in the WebClient. I assume WebClients aren't supposed to be thread safe (that's OK). However, can a WebClient be used to make multiple calls? What would you expect in the case where a WebClient makes multiple async calls? By default WebClient is not thread safe, but the thread-safety can be activated by a threadSafe flag, it can be set on the client factory bean, or passed to a WebClient factory method. Have a look please at JAXRSMultithreadedClientTest. A thread-local map is then used to keep a per-invocation state. WebClient keeps the state because it emulates the 'browsing' process, so at any moment it (a single instance) can move back or forward - but that requires an extra support for the thread safety. 2.0 client interface is different, no 'browsing' style is there, so it may be much simpler to deal with the thread safety, I'll fond out soon once I start implementing it :-) Cheers, Sergey
Re: Async methods for JAX-RS WebClient
On 24/09/12 19:07, Daniel Kulp wrote: On Sep 24, 2012, at 8:31 AM, Sergey Beryozkinsberyoz...@gmail.com wrote: I went ahead and populated AsyncInvoker, as well as added another shortcut directly to WebClient, to support an async post call. Dan, have a look please, That all looks great. Thanks for filling in all the other methods. :-) Cool, thanks for making it easy to do that... Sergey Dan One thing that I can have a look later is making sure the retry calls work in case of async call failures, plus add few more minor enhancements, overall though it seems it looks OK Thanks, Sergey On 23/09/12 18:56, Sergey Beryozkin wrote: On 23/09/12 18:14, Sergey Beryozkin wrote: Hi Dan On 21/09/12 19:27, Daniel Kulp wrote: Sergey, (and others) I just committed some initial support for some async methods to the WebClient. Can you take a look at that change and make sure it all makes sense? I only have a get method in there right now, but it should be fairly trivial now to add the others that would map to the new doInvokeAsync method. Just want to make sure it looks ok first. It is a very good start, thanks for starting to look into it. I think I will push some of the code to AbstractClient once I get a better understanding of what is going on, for proxies to get the async support too. Other than that, I wonder if we should introduce an async() method which would return http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html that would let us support the async style of invocation completely in line with the way JAX-RS 2.0 does it, example: WebClient wc = WebClient.create(address); wc.async().get(callback); // etc (async() in JAX-RS 2.0 is in http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/clisystests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRS20ClientServerBookTest.javaent/Invocation.Builder.html) I added an empty AsyncInvoker implementation, with async().get(InvocationCallback) also working for now :-). Wow, it's really happening thanks to the addition of the HTTP async transport :-) Thanks, Sergey In addition to that we can indeed add simple shortcuts, one per every main method, or for those which are more likely to participate in async flows, say for get/post/put, to let users 'save' on typing 'async()' for few mainstream cases I'm a little concerned about the state objects in the WebClient. I assume WebClients aren't supposed to be thread safe (that's OK). However, can a WebClient be used to make multiple calls? What would you expect in the case where a WebClient makes multiple async calls? By default WebClient is not thread safe, but the thread-safety can be activated by a threadSafe flag, it can be set on the client factory bean, or passed to a WebClient factory method. Have a look please at JAXRSMultithreadedClientTest. A thread-local map is then used to keep a per-invocation state. WebClient keeps the state because it emulates the 'browsing' process, so at any moment it (a single instance) can move back or forward - but that requires an extra support for the thread safety. 2.0 client interface is different, no 'browsing' style is there, so it may be much simpler to deal with the thread safety, I'll fond out soon once I start implementing it :-) Cheers, Sergey
Re: Async methods for JAX-RS WebClient
Hi Dan On 21/09/12 19:27, Daniel Kulp wrote: Sergey, (and others) I just committed some initial support for some async methods to the WebClient. Can you take a look at that change and make sure it all makes sense? I only have a get method in there right now, but it should be fairly trivial now to add the others that would map to the new doInvokeAsync method. Just want to make sure it looks ok first. It is a very good start, thanks for starting to look into it. I think I will push some of the code to AbstractClient once I get a better understanding of what is going on, for proxies to get the async support too. Other than that, I wonder if we should introduce an async() method which would return http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html that would let us support the async style of invocation completely in line with the way JAX-RS 2.0 does it, example: WebClient wc = WebClient.create(address); wc.async().get(callback); // etc (async() in JAX-RS 2.0 is in http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/Invocation.Builder.html) In addition to that we can indeed add simple shortcuts, one per every main method, or for those which are more likely to participate in async flows, say for get/post/put, to let users 'save' on typing 'async()' for few mainstream cases I'm a little concerned about the state objects in the WebClient. I assume WebClients aren't supposed to be thread safe (that's OK). However, can a WebClient be used to make multiple calls? What would you expect in the case where a WebClient makes multiple async calls? By default WebClient is not thread safe, but the thread-safety can be activated by a threadSafe flag, it can be set on the client factory bean, or passed to a WebClient factory method. Have a look please at JAXRSMultithreadedClientTest. A thread-local map is then used to keep a per-invocation state. WebClient keeps the state because it emulates the 'browsing' process, so at any moment it (a single instance) can move back or forward - but that requires an extra support for the thread safety. 2.0 client interface is different, no 'browsing' style is there, so it may be much simpler to deal with the thread safety, I'll fond out soon once I start implementing it :-) Cheers, Sergey
Re: Async methods for JAX-RS WebClient
On 23/09/12 18:14, Sergey Beryozkin wrote: Hi Dan On 21/09/12 19:27, Daniel Kulp wrote: Sergey, (and others) I just committed some initial support for some async methods to the WebClient. Can you take a look at that change and make sure it all makes sense? I only have a get method in there right now, but it should be fairly trivial now to add the others that would map to the new doInvokeAsync method. Just want to make sure it looks ok first. It is a very good start, thanks for starting to look into it. I think I will push some of the code to AbstractClient once I get a better understanding of what is going on, for proxies to get the async support too. Other than that, I wonder if we should introduce an async() method which would return http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/AsyncInvoker.html that would let us support the async style of invocation completely in line with the way JAX-RS 2.0 does it, example: WebClient wc = WebClient.create(address); wc.async().get(callback); // etc (async() in JAX-RS 2.0 is in http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/clisystests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRS20ClientServerBookTest.javaent/Invocation.Builder.html) I added an empty AsyncInvoker implementation, with async().get(InvocationCallback) also working for now :-). Wow, it's really happening thanks to the addition of the HTTP async transport :-) Thanks, Sergey In addition to that we can indeed add simple shortcuts, one per every main method, or for those which are more likely to participate in async flows, say for get/post/put, to let users 'save' on typing 'async()' for few mainstream cases I'm a little concerned about the state objects in the WebClient. I assume WebClients aren't supposed to be thread safe (that's OK). However, can a WebClient be used to make multiple calls? What would you expect in the case where a WebClient makes multiple async calls? By default WebClient is not thread safe, but the thread-safety can be activated by a threadSafe flag, it can be set on the client factory bean, or passed to a WebClient factory method. Have a look please at JAXRSMultithreadedClientTest. A thread-local map is then used to keep a per-invocation state. WebClient keeps the state because it emulates the 'browsing' process, so at any moment it (a single instance) can move back or forward - but that requires an extra support for the thread safety. 2.0 client interface is different, no 'browsing' style is there, so it may be much simpler to deal with the thread safety, I'll fond out soon once I start implementing it :-) Cheers, Sergey
Re: Facing error on Weblogic 11g with Apache CXF |u sing POST IN REST |Need help
) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1451) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) Caused by: java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:173) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:89) at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:130) at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:82) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:139) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:38) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109) at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:100) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:394) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:133) at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:180) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:104) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:184) … 9 more I can share the detailed logs if required as well. Thanks in advance. We are sending a small XML file with 2 string values through REST.Actually we didn’t suspected the param As: 1 The application starts working after some time. 2 The issue comes up only when the admin server and engines are on different machines. SO by this its seems that the server is not able to initialize the CXF properly. -- View this message in context: http://cxf.547215.n5.nabble.com/Facing-error-on-Weblogic-11g-with-Apache-CXF-u-sing-POST-IN-REST-Need-help-tp5713466.html Sent from the cxf-issues mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Release CXF Fediz 1.0.1
+1 On Aug 24, 2012, at 1:02 PM, Glen Mazzaglen.ma...@gmail.com wrote: Hi all, this new release provides significant documentation updates within the samples as well as new sample keys to help clarify necessary trust requirements. Oli has also gotten some programmatic fixes/enhancements in. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313420version=12321857 Maven staging areas: https://repository.apache.org/content/repositories/orgapachecxf-006/ Releases are tagged at: http://svn.apache.org/repos/asf/cxf/fediz/tags/fediz-1.0.1/ Here is my +1. The vote will be open for at least 72 hours. Thanks, Glen -- View this message in context: http://cxf.547215.n5.nabble.com/VOTE-Release-CXF-Fediz-1-0-1-tp5713126.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [VOTE] New features.xml for 2.5.5(.1)
On 22/08/12 15:27, Daniel Kulp wrote: The Karaf features.xml file that was released with 2.5.5 is corrupt which is preventing it from actually being usable to install CXF 2.5.5 into Karaf. This vote is just to release a new features file (version 2.5.5.1) that fixes that issue. It installs all the CXF 2.5.5 artifacts that have previously been released. Again, this is ONLY a features.xml file release. Staging are: https://repository.apache.org/content/repositories/orgapachecxf-029/ Tag: http://svn.apache.org/repos/asf/cxf/tags/apache-cxf-features-xml-2.5.5.1/ Here is my +1 +1 Cheers, Sergey
Re: fediz SSO?
On 20/08/12 22:17, Romain Manni-Bucau wrote: two distinct RP webapps (let say in different tomcat). currently it almost works because with 401 the client (browser) will cache authorization header so it will seem it work but since you change the way you login (and the user/pass is no more in headers) it can't work anymore (typically a form). This seems like a state management issue to me. Fediz currently relies on the servlet container to manage the session state, so if you say have the single application running on two Tomcat containers then Tomcat has to be configured to get the state shared between multiple containers, I recall I saw some material on the web on how to do it, Alternatively, the state can be managed by Fediz itself (similarly to the way we do it with Web profile), may be we can support that too once CXF-centric extensions are added Cheers, Sergey The point today is what's next' in IDP? I mean, does fediz aims to provide extensibility or will user need to fork the IDP to get some custom features (i know the answer will not be yes or no ;), but a state is important IMO)? *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/20 Oliver Wulffowu...@talend.com Hi Romain The IDP has a lot of potential for new features. At the very beginning, the Fediz IDP was intended to mock an IDP and test your application but it has grown as you can meanwhile attach LDAP for authentication and claims support. I'm not sure what you mean by classical SSO between two web apps? Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Romain Manni-Bucau [rmannibu...@gmail.com] Sent: 17 August 2012 15:13 To: dev@cxf.apache.org Subject: Re: fediz SSO? ok, great, so i'll wait some news from fediz ;) thanks for the answer *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/17 Sergey Beryozkinsberyoz...@gmail.com Hi On 17/08/12 09:11, Romain Manni-Bucau wrote: Hi, i didn't see anything in the roadmap of fediz regarding the 'classical' SSO (between 2 webapps with GUI). It doesn't seem to currently work (well that's not a big surprise but that's a big problem for real applications which have GUI + WS). Any information about it? Colm and myself worked on implementing SAML SSO Web Profile at the SP side only, currently in CXF, implemented with the help of JAX-RS filters/endpoints. I hope we can come to some agreement soon enough on how to get it linked with Fediz Another question is the GUI used for the login, a 401 is rarely what an application wants, any way to use a form or is th eonly way to achieve it forking the existing servlets? The login form is offered by IDP (Fediz in this case). We've chatted with Oli few months ago on providing CXF-centric Fediz extensions, when we do it we will be able to utilize JAX-RS RequestDispatcherProvider which links the data with JSP/other view handlers - this is how we do SAML SSO Post Redirect support too Cheers, Sergey *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.**com http://rmannibucau.wordpress.com * -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: fediz SSO?
Hi On 21/08/12 11:42, Romain Manni-Bucau wrote: well i thought of some distributed solutions but for me that's not a solution since you keep the password instead of keeping the token, i think the current logic flow is not matching this requirement (but is it a fediz requirement?) My understanding that it is only IDP that keeps, indirectly, the password and the state management at the RP side is all about getting the login token shared, but I'm not sure yet how Fediz does it, shame I haven't debugged it yet, need to do it asap :-) Cheers, Sergey *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/21 Sergey Beryozkinsberyoz...@gmail.com On 20/08/12 22:17, Romain Manni-Bucau wrote: two distinct RP webapps (let say in different tomcat). currently it almost works because with 401 the client (browser) will cache authorization header so it will seem it work but since you change the way you login (and the user/pass is no more in headers) it can't work anymore (typically a form). This seems like a state management issue to me. Fediz currently relies on the servlet container to manage the session state, so if you say have the single application running on two Tomcat containers then Tomcat has to be configured to get the state shared between multiple containers, I recall I saw some material on the web on how to do it, Alternatively, the state can be managed by Fediz itself (similarly to the way we do it with Web profile), may be we can support that too once CXF-centric extensions are added Cheers, Sergey The point today is what's next' in IDP? I mean, does fediz aims to provide extensibility or will user need to fork the IDP to get some custom features (i know the answer will not be yes or no ;), but a state is important IMO)? *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.**comhttp://rmannibucau.wordpress.com * 2012/8/20 Oliver Wulffowu...@talend.com Hi Romain The IDP has a lot of potential for new features. At the very beginning, the Fediz IDP was intended to mock an IDP and test your application but it has grown as you can meanwhile attach LDAP for authentication and claims support. I'm not sure what you mean by classical SSO between two web apps? Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com __**__ From: Romain Manni-Bucau [rmannibu...@gmail.com] Sent: 17 August 2012 15:13 To: dev@cxf.apache.org Subject: Re: fediz SSO? ok, great, so i'll wait some news from fediz ;) thanks for the answer *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.**comhttp://rmannibucau.wordpress.com * 2012/8/17 Sergey Beryozkinsberyoz...@gmail.com** Hi On 17/08/12 09:11, Romain Manni-Bucau wrote: Hi, i didn't see anything in the roadmap of fediz regarding the 'classical' SSO (between 2 webapps with GUI). It doesn't seem to currently work (well that's not a big surprise but that's a big problem for real applications which have GUI + WS). Any information about it? Colm and myself worked on implementing SAML SSO Web Profile at the SP side only, currently in CXF, implemented with the help of JAX-RS filters/endpoints. I hope we can come to some agreement soon enough on how to get it linked with Fediz Another question is the GUI used for the login, a 401 is rarely what an application wants, any way to use a form or is th eonly way to achieve it forking the existing servlets? The login form is offered by IDP (Fediz in this case). We've chatted with Oli few months ago on providing CXF-centric Fediz extensions, when we do it we will be able to utilize JAX-RS RequestDispatcherProvider which links the data with JSP/other view handlers - this is how we do SAML SSO Post Redirect support too Cheers, Sergey *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com http://rmannibucau.wordpress.**comhttp://rmannibucau.wordpress.com * -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: fediz SSO?
two web apps? Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com __**__ From: Romain Manni-Bucau [rmannibu...@gmail.com] Sent: 17 August 2012 15:13 To: dev@cxf.apache.org Subject: Re: fediz SSO? ok, great, so i'll wait some news from fediz ;) thanks for the answer *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.**comhttp://rmannibucau.** wordpress.comhttp://**rmannibucau.wordpress.comhttp://rmannibucau.wordpress.com * 2012/8/17 Sergey Beryozkinsberyoz...@gmail.com** Hi On 17/08/12 09:11, Romain Manni-Bucau wrote: Hi, i didn't see anything in the roadmap of fediz regarding the 'classical' SSO (between 2 webapps with GUI). It doesn't seem to currently work (well that's not a big surprise but that's a big problem for real applications which have GUI + WS). Any information about it? Colm and myself worked on implementing SAML SSO Web Profile at the SP side only, currently in CXF, implemented with the help of JAX-RS filters/endpoints. I hope we can come to some agreement soon enough on how to get it linked with Fediz Another question is the GUI used for the login, a 401 is rarely what an application wants, any way to use a form or is th eonly way to achieve it forking the existing servlets? The login form is offered by IDP (Fediz in this case). We've chatted with Oli few months ago on providing CXF-centric Fediz extensions, when we do it we will be able to utilize JAX-RS RequestDispatcherProvider which links the data with JSP/other view handlers - this is how we do SAML SSO Post Redirect support too Cheers, Sergey *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com http://rmannibucau.wordpress.**comhttp://rmannibucau.** wordpress.comhttp://**rmannibucau.wordpress.comhttp://rmannibucau.wordpress.com * -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Release Apache CXF 2.4.9/2.5.5/2.6.2
Hi, +1 Sergey On 15/08/12 04:20, Daniel Kulp wrote: We've resolved over 80 issues since 2.6.1 and we're a little overdue for a release. List of issues: 2.4.9 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12321666 2.5.5 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12321667 2.6.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12321668 The Maven staging areas are at: 2.4.9 https://repository.apache.org/content/repositories/orgapachecxf-001/ 2.5.5 https://repository.apache.org/content/repositories/orgapachecxf-002/ 2.6.2 https://repository.apache.org/content/repositories/orgapachecxf-004/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.9 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.5 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.2 This vote will be open for at least 72 hours.
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
Hi On 11/06/12 14:35, Sergey Beryozkin wrote: Hi Dan, All, sorry for a delay On 08/06/12 20:55, Daniel Kulp wrote: Not really much of a discussion, but no objections either. Thus, I'll go ahead and create the branch. :-) Dan On Friday, June 01, 2012 11:10:26 AM Daniel Kulp wrote: With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts about creating a 2.6.x-fixes branch and changing trunk to target 2.7. Here is a list of some things I'd like to start thinking about for 2.7: 1) Drop support for Java 5 - this may be a bit contentious. :-) It would simplify the poms a little bit, allow use of @Override, remove some jars from the lib dir, etc... The bigger issue is that several of the things we test with and depend on are now Java 6+ such as ActiveMQ and gwt and such so we've been stuck on older versions. +1 2) Async http client - this is been on my maybe next version of CXF for quite a while. Since 2.3.x I think. Maybe I'll actually get to it. :-) Would definitely help with some of the Camel integration scenarios. 3) WS-Discovery - really two parts to this. Runtime support to broadcast availability and discover endpoints is the first part. Second part MAY be a simple WS-Discovery proxy service for /services. 4) SOAP/UDP - Required for #3. 5) Possible re-write of the http-jetty transport to base it off the Servlet transport or similar so it can take more advantage of things like the services list, etc... Additionally, that may make it easier to create an http-tomcat transport (which people DID ask about at CamelOne BTW). Hope the JAX-RS frontend will benefit from 2) :-) Those are the things *I've* been thinking on and off about. Obviously the other folks around here may have additional things. I'm sure Colm has some security things, Sergey has some REST things, etc :-) There are few new features/improvements I'd like to focus upon in the next 6-12 months, apart from starting to work on implementing JAX-RS 2.0: 1. Security related enhancements - Continue working with Colm and Oli on SAML-based SSO (CXF, Fediz), though I did not work with Fediz yet - OAuth 2.0 and OpendId Connect - at the very least CXF AuthorizationService should be able to work with OpenId Connect endpoints provided by the third party - this part should be fairly easy to implement but there's a lot of new material there so it will take a bit of time to test/implement - OAuth 2.0, Fediz and SAML - we may want to provide an option for Fediz to produce SAML pr even JWT assertions as recommended by the relevant OAuth profiles 2. 'Connecting' FIQL queries with JPA as proposed by Jeff Wang - I think it needs to be prioritized; possible support for the alternative OData language 3. Light weight HTTP RM support - Aki and myself talked briefly about it with, I'll post an update shortly - not sure it's for 2.7 though 4. Looks like Web Sockets can become one of the main tools for building Web UI. People say they are not RESTful, but users will inevitably expect some support for it soon enough. So perhaps we can consider introducing an api similar to the Continuations one CXF already has that will be usable with Tomcat/Jetty, or at least introduce a Jetty centric module - again not sure it's for 2.7 but more investigation is needed So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes branch now? The only concern I had about it (it came to me when I was on holidays :-)) was where we'd have JAX-RS 2.0 implemented. Postponing it till 2.8 may not be ideal as introducing 2.8 say early in 2013 will give us 5 branches (including the trunk) and starting implementing it later in 2013 will be a bit late. I think the right thing to do would be to state upfront that CXF 2.7 will have at least the basic JAX-RS 2.0 support, for example, CXF 2.7.0 will have the dependencies changed only with the base JAX-RS Response, UriBuilder, etc updated. CXF 2.7.1/etc will start introducing more support. That should work, we don't have to get all JAX-RS 2.0 implemented in one go I've started the upgrade process on the trunk only, I think we will have a fairly basic server-side JAX-RS 2.0 support in CXF 2.7.0, but the process has started :-). Cheers, Sergey Does it sound reasonable ? Cheers, Sergey
Re: CXF-Trunk-JDK17 - Build # 53 - Still Unstable
Hi On 01/08/12 08:15, Apache Jenkins Server wrote: The Apache Jenkins build system has built CXF-Trunk-JDK17 (build #53) Status: Still Unstable Check console output at https://builds.apache.org/job/CXF-Trunk-JDK17/53/ to view the results. I can not reproduce the test failures in the JAX-RS frontend, after rebuilding locally with Java 1.7. Does someone else see the build failures, when building locally ? Thanks, Sergey
Re: Unresolved variables; only 0 value(s) given for 1 unique variable(s)
Hi Matt
On 30/07/12 19:00, Matt Massie wrote:
Let me start by thanking your team for writing such a good piece of code.
CXF has worked well for us.
For one project, we used CXF to create a JAX-RS service that uses nested
subresources. Originally, we only provided a Python client to REST
interface. I'm in the process of using the CXF JAXRSClientFactory to create
a Java client for customers as well. Unfortunately, the way we've
annotated the code is causing errors in the client code and I'm at a loss
to understand exactly why.
I've distilled the problem down to a simple test case and posted it as a
gist.
https://gist.github.com/3207745
Thanks for making this code available, helped me reproduce the issue
immediately.
Whenever I run the above test case, I get the following exception:
java.lang.IllegalArgumentException: Unresolved variables; only 0 value(s)
given for 1 unique variable(s)
at
org.apache.cxf.jaxrs.impl.UriBuilderImpl.substituteVarargs(UriBuilderImpl.java:185)
at org.apache.cxf.jaxrs.impl.UriBuilderImpl.doBuild(UriBuilderImpl.java:82)
at
org.apache.cxf.jaxrs.impl.UriBuilderImpl.buildFromEncoded(UriBuilderImpl.java:218)
at
org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:152)
at $Proxy15.getGrandchildResource(Unknown Source)
at com.cloudera.api.v1.impl.TestClass.testCase(TestClass.java:92)
It appears that the client code is unable to generate a request URI from
the @Path annotation we're providing.
Is there anything obviously wrong with the code in the gist that you can
see? Any guidance you can provide would be very appreciated.
ChildResource has
@Path(/{childName}/grandChildren)
on one of its methods,
but no @PathParam(childName) is avaialble
I've updated the method and the test passed
Cheers, Sergey
-Matt
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: 2.7 migration guide page created...
On 25/07/12 22:01, Daniel Kulp wrote: Just to let everyone know, I started a page to record any migration issues for CXF 2.7: https://cwiki.apache.org/confluence/display/CXF20DOC/2.7+Migration+Guide I just made a rather large commit to refactor the HTTPConduit stuff a bit. I've pulled all the HTTPUrlConnection logic out of it and into a subclass. I'm working on a new httpcompontent-asyncclient subclass as well. Pulling the HTTPUrlConnection stuff out allows quite a bit of reuse of much of the logic while making sure code that would do things like: HTTPConduit conduit = (HTTPConduit)client.getConduit(); conduit.setC() will still work. +1, very good Cheers, Sergey However, anyone that has already subclassed the HTTPConduit (likely very rare) may have migration issues.
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
On 13/07/12 18:35, Aki Yoshida wrote:
Hi,
I just submitted the code with CXF-4423 into trunk. Currently, it has
only the spring support and the blueprint support is to follow.
Basically, you can do something like:
bean id=keyManagers .../
bean id=trustManagers .../
http:conduit
name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters
sec:keyManagers ref=keyManagers/
sec:trustManagers ref=trustManagers/
sec:cipherSuitesFilter
...
Is this syntax okay? Alternatively, we could add the keyMangersRef and
trustMangersRef attributes within tlsClientParameters and not use the
keyManagers and trustManagers elements in this case. But I thought the
ref attribute within the keyManagers/trustManagers elements didn't
look bad.
IMHO it looks fine, I guess the individual stores can be represented as
bean references too if required
Sergey
regards, aki
2012/7/6 Freeman Fangfreeman.f...@gmail.com:
Sounds good to me, +1
Freeman
On 2012-7-5, at 下午10:28, Willem Jiang wrote:
+1，it makes our life easier to share the security parameter beans across
the http conduit.
On Thu Jul 5 19:09:57 2012, Sergey Beryozkin wrote:
Hi Aki,
On 05/07/12 11:58, Aki Yoshida wrote:
2012/7/5 Sergey Beryozkinsberyoz...@gmail.com:
Hi Aki
On 04/07/12 11:59, Aki Yoshida wrote:
Hi,
I haven been wondering about this for a while and I would like to hear
your thoughts.
Concretely, I am wondering if people are happy with the current file
or resource based keystore instantiation provided by the
tlsClientParameters's configuration schema. The current schema does
not allow any bean referencing from within that structure. So, using
the http's spring or blueprint namespace handlers that are based on
this schema, you need to configure this entire structure. This makes
it difficult to use this configuration handler If you have your own
mechanism to get keystores and you can provide it as a bean or
factory-bean reference.
In such cases, one could directly configure the httpConduit and its
tlsClientParameter as beans directly. Unfortunately, this doesn't work
in blueprint because the blueprint bean element does not have the name
attribute that can be used to configure the conduit's matching
pattern. So, this is not practical. Besides, I think it's pain to
configure beans directly when the specific namespace handlers are
available.
So what are the options? Is this an unusual use case? If this is not
an unusual use case, should we add the reference attribute in some of
those elements so that these can be optionally configured separately
and referenced?
Your comments are appreciated.
I've had a chance to deal with tlsClientParameters few days ago,
I've seen
the examples of the references like
sec:keyStore type=JKS password=sspass
url=mtprotocol://mystorejks/
Are you thinking of having something like
ref=mybean ? I guess it makes sense, we'd probably need to have some
interface like KeyResourceStore introduced, sorry if I misunderstood
Hi Sergey,
yes. I was thinking about introducing an optional ref attribute in
some suitable places to do ref=mybean.
Here are some examples.
The current configuration looks like this:
http:conduit
name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters
sec:keyManagers keyPassword=password
sec:keyStore type=JKS password=password
file=my/file/dir/Morpit.jks/
/sec:keyManagers
sec:trustManagers
sec:keyStore type=JKS password=password
file=my/file/dir/Truststore.jks/
/sec:trustManagers
...
Depending on where we allow this optional ref attribute, we could have
several variations in referencing.
For example, we could allow this attribute in the root level as in
http:conduit
name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters ref=mytlsbean
...
In this case, you could configure this bean directly and setting each
of its bean attributes. This may not be very convenient, but it is
simple and does not require any schema changes to its sub components.
or we could allow the ref attribute in the key/trustManagers level,
as in
http:conduit
name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters
sec:keyManagers ref=mykeymanagersbean/
sec:trustManagers ref=mytrustmanagersbean/
...
or in the keystore level:
http:conduit
name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters
sec:keyManagers keyPassword=password
sec:keyStore ref=mykeystorebean/
...
I would like to hear if people want to have something like these.
IMHO both options look good, +1 from me
Thanks, Sergey
Thanks.
Regards, aki
Cheers, Sergey
Thanks.
Regards, Aki
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http
Re: Available RESTful services -- UI
Redirecting the users list, On 13/07/12 16:15, sunnydyal wrote: OK. style-sheet exists in my root directory. Still not picking up stylesheet. Servlet controller produce a warning. Here Html Source: HEAD LINK type=text/css rel=stylesheet href=/myapp/servicelist.css meta http-equiv=content-type content=text/html; charset=UTF-8 titleCXF - Service list/title /head WARN : org.apache.cxf.transport.servlet.ServletController - Can't find the the request for http://localhost:8080/myapp/servicelist.css's Observer This is because your CXFServlet is most likely listening on /* so it is asked to handle this URI. Can you restrict it to say /services/* or similar, this would let a default servlet to read this file ? If you prefer /* then consider configuring a static-resources-list CXF parameter, see DefaultCXFServlet: http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/resources/jaxrs_dispatch/WEB-INF/web.xml Sergey -- View this message in context: http://cxf.547215.n5.nabble.com/Available-RESTful-services-UI-tp5710956p5711058.html Sent from the cxf-dev mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Thoughts about DOSGI 1.3.2 release
On 12/07/12 10:10, David Bosschaert wrote: On 11 July 2012 22:42, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi David, All So far I'm really behind the target of getting DOSGI 1.3.2 released around this time of the year. I'm managed to get a bit of time and resolved DOSGI-111, however it's difficult for me right now to prioritize on other DOSGI JIRAs - I'm a bit overwhelmed with the current and the incoming (JAX-)RS related tasks. Somehow, Jettison 1.3.2 will have to be released as well. However I'm intending to keep the process going - the plan is to attempt to fix at least one specific JIRA, particularly to do with managing multiple contexts, etc, every 2 or so weeks. Not perfect :-), but there will be some progress. David, I've seen you creating a new subsystem distribution. Will it let us drop a single bundle distro ? Hi Sergey, Yes I started on the subsystem distro. This will be usable with implementations of the OSGi Enterprise R5 subsystem specification [1]. Currently the build process is not ideal and contains some hardcoded stuff, so the subsystem distribution is not ready. There has been some discussion in the Aries user list in relation to a maven plugin that will smoothen this out [2]. The subsystem distro will combine the convenience of the single bundle distro with the modularity of the multi-bundle distro. The best of both worlds :) However, I'm not sure whether it will completely replace the single bundle distro. It requires a subsystem implementation to be present in the OSGi framework and not everyone may have this. OK. I guess having a subsystem distribution is still a good thing, perhaps, in a few years time, it will become the only distribution. Additionally, I added some stuff in the discovery area: * Fixed a NPE when remote services with non-supported service registration properties were put in the Discovery Server. * Added a Discovery Plugin (experimental) that allows the transformation of discovery information. Great, by the way, the blog about the cloud stuff is also cool. Cheers, Sergey Cheers, David [1] Chapter 134 of the Enterprise Spec in http://www.osgi.org/Download/Release5 [2] http://mail-archives.apache.org/mod_mbox/aries-user/201207.mbox/%3C2A06A984-24E5-4793-A716-E0816CAF333A%40yahoo.com%3E
Re: Thoughts about DOSGI 1.3.2 release
Hi David, All So far I'm really behind the target of getting DOSGI 1.3.2 released around this time of the year. I'm managed to get a bit of time and resolved DOSGI-111, however it's difficult for me right now to prioritize on other DOSGI JIRAs - I'm a bit overwhelmed with the current and the incoming (JAX-)RS related tasks. Somehow, Jettison 1.3.2 will have to be released as well. However I'm intending to keep the process going - the plan is to attempt to fix at least one specific JIRA, particularly to do with managing multiple contexts, etc, every 2 or so weeks. Not perfect :-), but there will be some progress. David, I've seen you creating a new subsystem distribution. Will it let us drop a single bundle distro ? Cheers, Sergey On 29/05/12 12:11, Sergey Beryozkin wrote: On 29/05/12 08:12, David Bosschaert wrote: Migrating to blueprint will also solve https://issues.apache.org/jira/browse/DOSGI-69 which is a long-standing issue that many people want to see resolved. Agreed. I'd still see this migration as a 1.4-level issue. I can see 4-5 issues in the list that can help people with getting to move forward with DOSGi without requiring a lot of time to spend on fixing them, so I'd look at them for 1.3.2 It's a shame I've a little understanding at the moment how Aries works under the hood, not to say how Gemini does :-). I'm having some little progress with a single patch I just did for Aries though :-) Having someone who has a deeper understanding of Aries and possibly Gemini contributing toward this possible migration would be welcome. Cheers, Sergey David On 28 May 2012 18:51, Sergey Beryozkinsberyoz...@gmail.com wrote: FYI: https://issues.apache.org/jira/browse/DOSGI-115 The proposed fix will probably work with Gemini straight away :-) Sergey On 28/05/12 18:45, Sergey Beryozkin wrote: On 28/05/12 18:35, David Bosschaert wrote: I can understand that it's a significant refactoring. If you stay within the pure Blueprint model (within the spec) you shouldn't get bound to Aries. Eclipse Gemini also has an implementation. Sure and there was a proposal on how to get Gemini used under the hood, but the issue is how to get both used as needed. Having DOSGi migrated to Blueprint and CXF 2.6.x would obviously improve DOSGi CXF a lot, specifically, its OSGI-'awareness' would increase a lot. But as I said, there are still quite a few issues in this list: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+DOSGI+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC which IMHO are quite important to get fixed for the users be able to do their POCs, before making a big 'leap' forward. Unfortunately I can not afford spending several weeks on migrating the code to Blueprint, testing with Aries Gemini, etc...Perhaps we will get a bit of help from DOSGI CXF users :-) Cheers, Sergey Cheers, David On 28 May 2012 18:17, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi David On 28/05/12 18:09, David Bosschaert wrote: Sounds good, Sergey. I'm all for releasing frequently. One of the things that I think would be good to tackle is to migrate to OSGi Blueprint (from of the current Spring-based approach). Is that something that you were thinking of looking at? Not really. Some users would like to use Blueprint but not be bound to Aries. So for me it's a DOSGI 1.4 level issue which will require a significant time investment. Cheers, Sergey Cheers, David On 28 May 2012 17:34, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi I'm thinking of starting working toward releasing DOSGI 1.3.2. I think I'll spend the next 2 or months on fixing few issues I can find some time for, given that there's a lot of other CXF/etc work that needs to be taken care of. I'd like to suggest that the next release will be 1.3.2 as opposed to 1.4.0. Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort, giving that a minimal bundle in CXF 2.6.x has gone. It seems that there are still quite a few issues there that are important to be fixed for the base/simple DOSGI applications to work reliably and given that 2.5.x branch is still relatively 'young', I'd probably prefer to stay on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI 1.3.3), simply to make the most of the limited time that I will be able to spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by that time many of the 'basic' DOSGI features have been fixed... Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
NPE in one of WS-RM tests
Hi I spotted NPE (see below) in one of WS-RM tests, when building a WS-RM module,but the tests pass... Aki, may be you'd like to have a look :-) Cheers, Sergey Running org.apache.cxf.ws.rm.persistence.jdbc.RMTxStoreConfigurationTest java.lang.NullPointerException at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.createTables(RMTxStore.java:881) at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.init(RMTxStore.java:1066) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1546) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1487) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1419) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:518) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1327) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1085) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:516) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425) at org.apache.cxf.bus.spring.BusApplicationContext$1.run(BusApplicationContext.java:107) at org.apache.cxf.bus.spring.BusApplicationContext$1.run(BusApplicationContext.java:105) at java.security.AccessController.doPrivileged(Native Method) at org.apache.cxf.bus.spring.BusApplicationContext.init(BusApplicationContext.java:105) at org.apache.cxf.bus.spring.SpringBusFactory.createApplicationContext(SpringBusFactory.java:157) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:148) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:124) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:94) at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStoreConfigurationTest.testTxStoreBean(RMTxStoreConfigurationTest.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
Re: NPE in one of WS-RM tests
On 09/07/12 17:07, Daniel Kulp wrote: On Monday, July 09, 2012 12:39:36 PM Sergey Beryozkin wrote: Hi I spotted NPE (see below) in one of WS-RM tests, when building a WS-RM module,but the tests pass... Aki, may be you'd like to have a look :-) I have a fix for this on my machine that I didn't get a chance to commit prior to my having to run to the hospital with my kid last week (and then vacation). Give me a few minutes to run tests and such. Thanks Dan Cheers, Sergey Dan Cheers, Sergey Running org.apache.cxf.ws.rm.persistence.jdbc.RMTxStoreConfigurationTest java.lang.NullPointerException at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.createTables(RMTxStore.jav a:881) at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore.init(RMTxStore.java:1066) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm pl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1546) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1487) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.initializeBean(AbstractAutowireCapableBeanFactory.java:1419) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.doCreateBean(AbstractAutowireCapableBeanFactory.java:518) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.createBean(AbstractAutowireCapableBeanFactory.java:455) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject( AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.get Singleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Ab stractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abst ractBeanFactory.java:192) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.reso lveReference(BeanDefinitionValueResolver.java:322) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.reso lveValueIfNecessary(BeanDefinitionValueResolver.java:106) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1327) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.populateBean(AbstractAutowireCapableBeanFactory.java:1085) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.doCreateBean(AbstractAutowireCapableBeanFactory.java:516) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto ry.createBean(AbstractAutowireCapableBeanFactory.java:455) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject( AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.get Singleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Ab stractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abst ractBeanFactory.java:192) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preIn stantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanF actoryInitialization(AbstractApplicationContext.java:895) at org.springframework.context.support.AbstractApplicationContext.refresh(Abs tractApplicationContext.java:425) at org.apache.cxf.bus.spring.BusApplicationContext$1.run(BusApplicationContex t.java:107) at org.apache.cxf.bus.spring.BusApplicationContext$1.run(BusApplicationContex t.java:105) at java.security.AccessController.doPrivileged(Native Method) at org.apache.cxf.bus.spring.BusApplicationContext.init(BusApplicationConte xt.java:105) at org.apache.cxf.bus.spring.SpringBusFactory.createApplicationContext(Spring BusFactory.java:157) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java :148) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java :124) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java :94) at org.apache.cxf.ws.rm.persistence.jdbc.RMTxStoreConfigurationTest.testTxSto reBean(RMTxStoreConfigurationTest.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
Hi Aki On 04/07/12 11:59, Aki Yoshida wrote: Hi, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation provided by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within that structure. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. I've had a chance to deal with tlsClientParameters few days ago, I've seen the examples of the references like sec:keyStore type=JKS password=sspass url=mtprotocol://mystorejks/ Are you thinking of having something like ref=mybean ? I guess it makes sense, we'd probably need to have some interface like KeyResourceStore introduced, sorry if I misunderstood Cheers, Sergey Thanks. Regards, Aki -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1354452 - in /cxf/branches/2.4.x-fixes: ./ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/
value = 1.1;
+
+ // Act
+ Object id = InjectionUtils.handleParameter(value,
+ true,
+ Id.class,
+ new Annotation[] {},
+ ParameterType.PATH,
+ createMessage());
+
+ // Assert
+ assertTrue(id instanceof Id);
+ assertEquals(value, ((Id)id).getId());
+ }
+
public void testCollectionTypeFromArray() {
assertNull(InjectionUtils.getCollectionType(String[].class));
}
@@ -179,4 +211,62 @@ public class InjectionUtilsTest extends
}
}
+ private Message createMessage() {
+ ProviderFactory factory = ProviderFactory.getInstance();
+ Message m = new MessageImpl();
+ m.put(org.apache.cxf.http.case_insensitive_queries, false);
+ Exchange e = new ExchangeImpl();
+ m.setExchange(e);
+ e.setInMessage(m);
+ Endpoint endpoint = EasyMock.createMock(Endpoint.class);
+ endpoint.getEndpointInfo();
+ EasyMock.expectLastCall().andReturn(null).anyTimes();
+ endpoint.get(Application.class.getName());
+ EasyMock.expectLastCall().andReturn(null);
+ endpoint.size();
+ EasyMock.expectLastCall().andReturn(0).anyTimes();
+ endpoint.isEmpty();
+ EasyMock.expectLastCall().andReturn(true).anyTimes();
+ endpoint.get(ProviderFactory.class.getName());
+ EasyMock.expectLastCall().andReturn(factory).anyTimes();
+ EasyMock.replay(endpoint);
+ e.put(Endpoint.class, endpoint);
+ return m;
+ }
+
+ public static class Adapter extends XmlAdapterString, Id {
+
+ @Override
+ public String marshal(final Id id) throws Exception {
+ return id.getId();
+ }
+
+ @Override
+ public Id unmarshal(final String idStr) throws Exception {
+ Id id = new DelegatingId();
+ id.setId(idStr);
+ return id;
+ }
+ }
+
+ @XmlJavaTypeAdapter(Adapter.class)
+ public interface Id {
+ String getId();
+
+ void setId(String id);
+ }
+
+ public static class DelegatingId implements Id {
+
+ private String id;
+
+ public String getId() {
+ return this.id;
+ }
+
+ public void setId(String id) {
+ this.id = id;
+ }
+
+ }
}
-
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1354452 - in /cxf/branches/2.4.x-fixes: ./ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/
Hi Willem, Freeman
Willem, the fix looks OK, thanks for doing it,
I was doing the merge to 2.5.x manually so that led to that broken code
Cheers, Sergey
On 05/07/12 10:08, Sergey Beryozkin wrote:
Oh, sorry, completely missed it. Will look asap
Cheers, Sergey
On 05/07/12 10:02, Willem Jiang wrote:
I just committed a quick fix for it.
Sergey, if you have time, please double check it.
On Wed Jul 4 08:44:12 2012, Freeman Fang wrote:
Hi Sergey,
This commit break some jaxrs tests in 2.5.x branch, they're
org.apache.cxf.jaxrs.utils.InjectionUtilsTest.testHandleParameterWithXmlAdapterOnInterface
org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsInterface
org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreAsClass
org.apache.cxf.jaxrs.ext.codegen.CodeGeneratorProviderTest.testBookStoreTypesOnly
Those test failed since Project CXF-2.5.x #337[1] on CI and afterwards.
The reason for CodeGeneratorProviderTest failure is because there's
another extra Books.class in addition to the classes listed, as
CodeGeneratorProviderTest get removed from trunk and 2.6.x branches,
so I'm not sure CodeGeneratorProviderTest is still valid based on
current jaxrs code.
The InjectionUtilsTest failed because the code
Object id = InjectionUtils.handleParameter(value,
true,
Id.class,
new Annotation[] {},
ParameterType.PATH,
createMessage());
now return id as a String.class, but not the expected Id.class.
Could you please take a look?
[1]https://builds.apache.org/job/CXF-2.5.x/337/#showFailuresLink
Thanks
Freeman
On 2012-6-27, at 下午7:58, serg...@apache.org wrote:
Author: sergeyb
Date: Wed Jun 27 11:58:32 2012
New Revision: 1354452
URL: http://svn.apache.org/viewvc?rev=1354452view=rev
Log:
Merged revisions 1354451 via svnmerge from
https://svn.apache.org/repos/asf/cxf/branches/2.5.x-fixes
r1354451 | sergeyb | 2012-06-27 12:55:57 +0100 (Wed, 27 Jun 2012) |
24 lines
Merged revisions 1354447 via svnmerge from
https://svn.apache.org/repos/asf/cxf/branches/2.6.x-fixes
r1354447 | sergeyb | 2012-06-27 12:51:30 +0100 (Wed, 27 Jun 2012)
| 17 lines
Merged revisions 1354441-1354442,1354446 via svnmerge from
https://svn.apache.org/repos/asf/cxf/trunk
r1354441 | sergeyb | 2012-06-27 12:44:38 +0100 (Wed, 27 Jun
2012) | 1 line
[CXF-4396] Checking a port when 0.0.0.0 address gets replaced
r1354442 | sergeyb | 2012-06-27 12:45:33 +0100 (Wed, 27 Jun
2012) | 1 line
[CXF-4379] Passing corect type for adapters bound to interfaces
to be discoverd
r1354446 | sergeyb | 2012-06-27 12:49:57 +0100 (Wed, 27 Jun
2012) | 1 line
[CXF-4379] Minor optimization
Modified:
cxf/branches/2.4.x-fixes/ (props changed)
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXBUtils.java
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/HttpUtilsTest.java
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/InjectionUtilsTest.java
Propchange: cxf/branches/2.4.x-fixes/
--
Merged /cxf/branches/2.5.x-fixes:r1354451
Merged /cxf/trunk:r1354441-1354446
Merged /cxf/branches/2.6.x-fixes:r1354447
Propchange: cxf/branches/2.4.x-fixes/
--
Binary property 'svnmerge-integrated' - no diff available.
Modified:
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java
URL:
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java?rev=1354452r1=1354451r2=1354452view=diff
==
---
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java
(original)
+++
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/HttpUtils.java
Wed Jun 27 11:58:32 2012
@@ -200,7 +200,10 @@ public final class HttpUtils {
if (!absolute) {
u = URI.create(base + u.toString());
} else {
- u = URI.create(u.toString().replace(ANY_IP_ADDRESS,
serverAndPort));
+ int originalPort = u.getPort();
+ String replaceValue = originalPort == -1 ?
ANY_IP_ADDRESS
+ : ANY_IP_ADDRESS + : + originalPort;
+ u = URI.create(u.toString().replace(replaceValue,
serverAndPort));
}
}
return u;
Modified:
cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java
URL:
http://svn.apache.org/viewvc/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils
Re: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint?
Hi Aki,
On 05/07/12 11:58, Aki Yoshida wrote:
2012/7/5 Sergey Beryozkinsberyoz...@gmail.com:
Hi Aki
On 04/07/12 11:59, Aki Yoshida wrote:
Hi,
I haven been wondering about this for a while and I would like to hear
your thoughts.
Concretely, I am wondering if people are happy with the current file
or resource based keystore instantiation provided by the
tlsClientParameters's configuration schema. The current schema does
not allow any bean referencing from within that structure. So, using
the http's spring or blueprint namespace handlers that are based on
this schema, you need to configure this entire structure. This makes
it difficult to use this configuration handler If you have your own
mechanism to get keystores and you can provide it as a bean or
factory-bean reference.
In such cases, one could directly configure the httpConduit and its
tlsClientParameter as beans directly. Unfortunately, this doesn't work
in blueprint because the blueprint bean element does not have the name
attribute that can be used to configure the conduit's matching
pattern. So, this is not practical. Besides, I think it's pain to
configure beans directly when the specific namespace handlers are
available.
So what are the options? Is this an unusual use case? If this is not
an unusual use case, should we add the reference attribute in some of
those elements so that these can be optionally configured separately
and referenced?
Your comments are appreciated.
I've had a chance to deal with tlsClientParameters few days ago, I've seen
the examples of the references like
sec:keyStore type=JKS password=sspass
url=mtprotocol://mystorejks/
Are you thinking of having something like
ref=mybean ? I guess it makes sense, we'd probably need to have some
interface like KeyResourceStore introduced, sorry if I misunderstood
Hi Sergey,
yes. I was thinking about introducing an optional ref attribute in
some suitable places to do ref=mybean.
Here are some examples.
The current configuration looks like this:
http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters
sec:keyManagers keyPassword=password
sec:keyStore type=JKS password=password
file=my/file/dir/Morpit.jks/
/sec:keyManagers
sec:trustManagers
sec:keyStore type=JKS password=password
file=my/file/dir/Truststore.jks/
/sec:trustManagers
...
Depending on where we allow this optional ref attribute, we could have
several variations in referencing.
For example, we could allow this attribute in the root level as in
http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters ref=mytlsbean
...
In this case, you could configure this bean directly and setting each
of its bean attributes. This may not be very convenient, but it is
simple and does not require any schema changes to its sub components.
or we could allow the ref attribute in the key/trustManagers level, as in
http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters
sec:keyManagers ref=mykeymanagersbean/
sec:trustManagers ref=mytrustmanagersbean/
...
or in the keystore level:
http:conduit name={http://apache.org/hello_world}HelloWorld.http-conduit;
http:tlsClientParameters
sec:keyManagers keyPassword=password
sec:keyStore ref=mykeystorebean/
...
I would like to hear if people want to have something like these.
IMHO both options look good, +1 from me
Thanks, Sergey
Thanks.
Regards, aki
Cheers, Sergey
Thanks.
Regards, Aki
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1356822 - /cxf/trunk/api/src/main/java/org/apache/cxf/configuration/jsse/TLSParameterJaxBUtils.java
JIRA issue to be created once the system is up Sergey On 03/07/12 17:46, serg...@apache.org wrote: Author: sergeyb Date: Tue Jul 3 16:46:26 2012 New Revision: 1356822 URL: http://svn.apache.org/viewvc?rev=1356822view=rev Log: TLSParameterJaxBUtils needs to use ResourceManager to locate the store resources if ClassLoaderUtils can not locate them Modified: cxf/trunk/api/src/main/java/org/apache/cxf/configuration/jsse/TLSParameterJaxBUtils.java
Re: CXF-DOSGi Zookeeper discovery data transformation
Hi David
Thanks for the explanation,
On 25/06/12 09:02, David Bosschaert wrote:
Hi Sergey,
On 22 June 2012 17:43, Sergey Beryozkinsberyoz...@gmail.com wrote:
Hi David
On 22/06/12 15:58, David Bosschaert wrote:
Hi all,
I'm currently playing with CXF-DOSGi in the context of a cloud setup
and I'm also using the Zookeeper-based discovery.
The problem that I'm facing is that the host and port as known by the
local framework (running inside a cloud instance) is not the same as
the public host and port. Obviously to be able to access the remoted
service from outside you need the public host and port.
So I came up with a DiscoveryPlugin interface which bundles can
register in the OSGi Service Registry (in the true OSGi Whiteboard
pattern way) to support such a transformation.
It has the following API:
public interface DiscoveryPlugin {
String process(MapString, ObjectmutableMap, String fullPath);
}
Before the ZooKeeper client code in CXF registers the endpoint with
the ZooKeeper server all registered DiscoveryPlugin are given a chance
to process the data. They can change the properties of the service
registration and change the path. So in my case I can change the URL
where the local framework thinks it registers it (e.g.
127.5.3.123:8080) to the URL from where things are publicly accessible
(e.g. my.cloud.instance:80).
Would everyone be happy with me adding this feature to the
cxf-dosgi-ri-discovery-distributed module? It's backward compatible -
if you have no plugins registered nothing happens.
Looks like a neat idea.
What does mutableMap will represent ?
You're right - I could have made that a little more clear :) It
represents the service registration properties that will be stored in
ZooKeeper. For an example service they look like this:
endpoint.framework.uuid=609a4e6b-9abe-0011-1888-adf8693241e9,
endpoint.id=http://127.0.0.1:8080/repo,
endpoint.package.version.org.acme.foo=1.0.0.SNAPSHOT
endpoint.service.id=44,
objectClass=[org.acme.foo.SomeInterface],
org.apache.cxf.ws.address=http://127.0.0.1:8080/repo,
service.imported.configs=[org.apache.cxf.ws],
service.imported=true,
service.intents=[SOAP.1_1, HTTP, SOAP],
So it might be more appropriate to call the argument mutableProperties
instead of mutableMap (I'll make sure to add proper JavaDoc too :).
Whatever you change in that map will be stored in ZooKeeper using the
changed value (note that the actual service registration in the local
framework doesn't change).
OK
The plugin also allows you to change the path where it is changed by
returning a different path, so for example in my case the fullPath
variable is
/osgi/service_registry/org/acme/foo/SomeInterface/127.0.0.1#8080##foo
It would allow you to change that to something like
/osgi/service_registry/org/acme/foo/SomeInterface/my.cloud.host#80##foo
Sounds good. Minor observation is I guess that the plugin would only be
interested in replacing the the 127.0.0.1#8080##foo part, and if yes
then may be it will be marginally simpler to have:
String process(MapString, Object mutableProperties,
String registryPath,
String hostInformation);
String actualHostInfo = plugin.process(properties,
/osgi/service_registry/org/acme/foo/SomeInterface,
127.0.0.1#8080##foo);
Not sure if it make sense :-). Having a plugin to do a basic parsing of
the fullPath would not ne a big issue I guess :-)
Cheers, Sergey
Cheers,
David
Re: CXF Osgi Rest Provider
On 24/06/12 17:51, dattu.1729 wrote: Hi, Can you please tell me how to add jaxrs provider in blueprint. I am trying like below, but not working.. jaxrs:server address=/user id=userProfileResource jaxrs:serviceBeans ref component-id=userProfileResourceImpl / /jaxrs:serviceBeans jaxrs:providers ref component-id=jsonProvider / /jaxrs:providers /jaxrs:server reference id=jsonProvider interface=javax.ws.rs.ext.MessageBodyReader / This should be a bean with a class name, same as for userProfileResourceImpl Sergey - Thanks Dattu -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-Osgi-Rest-Provider-tp5710179.html Sent from the cxf-issues mailing list archive at Nabble.com. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CXF-DOSGi Zookeeper discovery data transformation
Hi David
On 22/06/12 15:58, David Bosschaert wrote:
Hi all,
I'm currently playing with CXF-DOSGi in the context of a cloud setup
and I'm also using the Zookeeper-based discovery.
The problem that I'm facing is that the host and port as known by the
local framework (running inside a cloud instance) is not the same as
the public host and port. Obviously to be able to access the remoted
service from outside you need the public host and port.
So I came up with a DiscoveryPlugin interface which bundles can
register in the OSGi Service Registry (in the true OSGi Whiteboard
pattern way) to support such a transformation.
It has the following API:
public interface DiscoveryPlugin {
String process(MapString, Object mutableMap, String fullPath);
}
Before the ZooKeeper client code in CXF registers the endpoint with
the ZooKeeper server all registered DiscoveryPlugin are given a chance
to process the data. They can change the properties of the service
registration and change the path. So in my case I can change the URL
where the local framework thinks it registers it (e.g.
127.5.3.123:8080) to the URL from where things are publicly accessible
(e.g. my.cloud.instance:80).
Would everyone be happy with me adding this feature to the
cxf-dosgi-ri-discovery-distributed module? It's backward compatible -
if you have no plugins registered nothing happens.
Looks like a neat idea.
What does mutableMap will represent ?
Cheers, Sergey
Cheers,
David
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: [VOTE] Release Apache CXF Fediz 1.0.0
+1 Cheers, Sergey On 20/06/12 00:22, Oliver Wulff wrote: It's been over 6 months since work started on Fediz and it's time for the first release. The features in this release are: * WS-Federation 1.0/1.1/1.2 * SAML 1.1/2.0 Tokens * Custom token support * Publish WS-Federation Metadata document * Role information encoded as AttributeStatement in SAML 1.1/2.0 tokens * Claims information provided by FederationPrincipal interface The documentation is available here: http://cxf.apache.org/fediz.html The maven staging area: https://repository.apache.org/content/repositories/orgapachecxf-250/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/fediz/tags/fediz-1.0.0 The distributions are in the org/apache/cxf/fediz/apache-fediz/ directory of the Maven staging area. This vote will be open for at least 72 hours. -- Oliver Wulff Blog: http://owulff.blogspot.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CXF-2.6.x - Build # 3495 - Still Failing
Hi On 19/06/12 11:13, Apache Jenkins Server wrote: The Apache Jenkins build system has built CXF-2.6.x (build #3495) Status: Still Failing Check console output at https://builds.apache.org/job/CXF-2.6.x/3495/ to view the results. I'm seeing the strange compilation failure in the results. I can not reproduce it locally, with the Java 1.5 compiler. Does rt/rs/extension/search compile for others ? Thanks, Sergey
Re: CXF-2.6.x - Build # 3495 - Still Failing
I disabled it for now. I suspect it may be caused by the hibernate entity manager test dependency which may be built with newer JDK which is confusing 1.5 compiler. Downgrading to 3.3.1.ga version is not an option given the JPA 2.0 CriteriaBuilder is being tested. One option is only to run this test on 2.7.x and later... Sergey On 19/06/12 11:20, Sergey Beryozkin wrote: Hi On 19/06/12 11:13, Apache Jenkins Server wrote: The Apache Jenkins build system has built CXF-2.6.x (build #3495) Status: Still Failing Check console output at https://builds.apache.org/job/CXF-2.6.x/3495/ to view the results. I'm seeing the strange compilation failure in the results. I can not reproduce it locally, with the Java 1.5 compiler. Does rt/rs/extension/search compile for others ? Thanks, Sergey
Re: CXF-DOSGi Logging
Hi Bert On 14/06/12 22:30, jbert wrote: Hey, I've been using DOSGi for a while, but what annoys me most is that either I get no logging, or I get spammed with INFO messages which don't mean much to me seeing how I just use DOSGi as a library to expose web-services. I've opened a bug report to bundle a few other annoyances (logging to the standard output/error streams) and attached a patch. Could someone review it and give some feedback? I'd love to see this get fixed in a next release. Thanks for this patch, it's been applied. Cheers, Sergey With best regards, Bert -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-DOSGi-Logging-tp5709834.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [DISCUSS] Branch for 2.6.x, trunk thoughts...
Hi Dan, All, sorry for a delay On 08/06/12 20:55, Daniel Kulp wrote: Not really much of a discussion, but no objections either. Thus, I'll go ahead and create the branch. :-) Dan On Friday, June 01, 2012 11:10:26 AM Daniel Kulp wrote: With 2.6.1 hopefully going out shortly, I'd like to get peoples thoughts about creating a 2.6.x-fixes branch and changing trunk to target 2.7. Here is a list of some things I'd like to start thinking about for 2.7: 1) Drop support for Java 5 - this may be a bit contentious. :-) It would simplify the poms a little bit, allow use of @Override, remove some jars from the lib dir, etc... The bigger issue is that several of the things we test with and depend on are now Java 6+ such as ActiveMQ and gwt and such so we've been stuck on older versions. +1 2) Async http client - this is been on my maybe next version of CXF for quite a while. Since 2.3.x I think. Maybe I'll actually get to it. :-) Would definitely help with some of the Camel integration scenarios. 3) WS-Discovery - really two parts to this. Runtime support to broadcast availability and discover endpoints is the first part. Second part MAY be a simple WS-Discovery proxy service for /services. 4) SOAP/UDP - Required for #3. 5) Possible re-write of the http-jetty transport to base it off the Servlet transport or similar so it can take more advantage of things like the services list, etc... Additionally, that may make it easier to create an http-tomcat transport (which people DID ask about at CamelOne BTW). Hope the JAX-RS frontend will benefit from 2) :-) Those are the things *I've* been thinking on and off about. Obviously the other folks around here may have additional things.I'm sure Colm has some security things, Sergey has some REST things, etc :-) There are few new features/improvements I'd like to focus upon in the next 6-12 months, apart from starting to work on implementing JAX-RS 2.0: 1. Security related enhancements - Continue working with Colm and Oli on SAML-based SSO (CXF, Fediz), though I did not work with Fediz yet - OAuth 2.0 and OpendId Connect - at the very least CXF AuthorizationService should be able to work with OpenId Connect endpoints provided by the third party - this part should be fairly easy to implement but there's a lot of new material there so it will take a bit of time to test/implement - OAuth 2.0, Fediz and SAML - we may want to provide an option for Fediz to produce SAML pr even JWT assertions as recommended by the relevant OAuth profiles 2. 'Connecting' FIQL queries with JPA as proposed by Jeff Wang - I think it needs to be prioritized; possible support for the alternative OData language 3. Light weight HTTP RM support - Aki and myself talked briefly about it with, I'll post an update shortly - not sure it's for 2.7 though 4. Looks like Web Sockets can become one of the main tools for building Web UI. People say they are not RESTful, but users will inevitably expect some support for it soon enough. So perhaps we can consider introducing an api similar to the Continuations one CXF already has that will be usable with Tomcat/Jetty, or at least introduce a Jetty centric module - again not sure it's for 2.7 but more investigation is needed So I guess the big question is: anyone OBJECT to creating the 2.6.x-fixes branch now? The only concern I had about it (it came to me when I was on holidays :-)) was where we'd have JAX-RS 2.0 implemented. Postponing it till 2.8 may not be ideal as introducing 2.8 say early in 2013 will give us 5 branches (including the trunk) and starting implementing it later in 2013 will be a bit late. I think the right thing to do would be to state upfront that CXF 2.7 will have at least the basic JAX-RS 2.0 support, for example, CXF 2.7.0 will have the dependencies changed only with the base JAX-RS Response, UriBuilder, etc updated. CXF 2.7.1/etc will start introducing more support. That should work, we don't have to get all JAX-RS 2.0 implemented in one go Does it sound reasonable ? Cheers, Sergey
Re: [VOTE] Apache CXF 2.3.11/2.4.8/2.5.4/2.6.1
+1 Cheers, Sergey On 30/05/12 19:15, Daniel Kulp wrote: We've resolved over 90 issues since 2.6.0 was released. We've back ported over 70 of them to 2.5.4 and 40 to 2.4.8 and 25 to 2.3.11. List of issues: 2.3.11: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12320749 2.4.8: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12320748 2.5.4: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12320747 2.6.1: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511version=12320746 The Maven staging areas are at: 2.3.12: https://repository.apache.org/content/repositories/orgapachecxf-149/ 2.4.8: https://repository.apache.org/content/repositories/orgapachecxf-159/ 2.5.4: https://repository.apache.org/content/repositories/orgapachecxf-160/ 2.6.1: https://repository.apache.org/content/repositories/orgapachecxf-161/ The distributions are in the org/apache/cxf/apache-cxf/ directory of the Maven staging areas. This releases are tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.11 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.4.8 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.5.4 http://svn.apache.org/repos/asf/cxf/tags/cxf-2.6.1 This vote will be open for at least 72 hours.
Re: svn commit: r1343446
+ */
+public staticT T createFromModel(String baseAddress, ClassT cls,
ListUserResource modelBeans,
+ List? providers, String configLocation,
ListAbstractFeature features) {
JAXRSClientFactoryBean bean = WebClient.getBean(baseAddress,
configLocation);
bean.setProviders(providers);
bean.setModelBeans(modelBeans);
bean.setServiceClass(cls);
+bean.setFeatures(features);
return bean.create(cls);
}
@@ -275,8 +430,23 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public staticT T fromClient(Client client, ClassT cls, boolean
inheritHeaders) {
+return fromClient(client, cls, inheritHeaders, null);
+}
+
+/**
+ * Creates a proxy, baseURI will be set to Client currentURI
+ * @param client Client instance
+ * @param cls proxy class, if not interface then a CGLIB proxy will be
created
+ * @param inheritHeaders if true then existing Client headers will be
inherited by new proxy
+ *and subresource proxies if any
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+public staticT T fromClient(Client client, ClassT cls, boolean
inheritHeaders,
+ ListAbstractFeature features) {
JAXRSClientFactoryBean bean =
getBean(client.getCurrentURI().toString(), cls, null);
bean.setInheritHeaders(inheritHeaders);
+bean.setFeatures(features);
ClientState clientState = WebClient.getClientState(client);
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1343446
By the way, Willem, if you have any specific preference on how such a
single method would like then lets work on it, ping me here or IRC
I'm thinking of having the one or max two methods which can take an
address, class, and the list of features. JAXRSClientFactory can not
take all the variations really - one may want then to offer a support
for accepting in or out or both in/out interceptors, etc - hope you see
what I mean
Sergey
On 29/05/12 10:00, Sergey Beryozkin wrote:
Hi Willem
I'd really prefer us discussing updates like this one to the public
client API that the CXF JAX-RS runtime offers.
I can see you just added 5 or so new JAXRSClientFactory methods.
I consider most of them redundant. JAXRSClientFactory is a *utility*
factory and is already a bit overloaded without these new extra 5
methods added.
JAXRSClientFactoryBean is always there to offer a more custom approach
toward creating a proxy and I would like to revert most of the methods
you added.
I agree it may make sense to offer say a single utility method for
accepting the features, but I'd not like to have 5+ variations, the API
will become too 'noisy'. Besides the same would then need to be added to
WebClient factory methods...
I'll take care of updating the api
Thanks, Sergey
On 29/05/12 02:39, ningji...@apache.org wrote:
Author: ningjiang
Date: Tue May 29 01:39:02 2012
New Revision: 1343446
URL: http://svn.apache.org/viewvc?rev=1343446view=rev
Log:
CXF-4345 Allow user-secified feautres for JAXRSClientFactory
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java?rev=1343446r1=1343445r2=1343446view=diff
==
---
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
(original)
+++
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
Tue May 29 01:39:02 2012
@@ -26,6 +26,7 @@ import java.util.List;
import javax.ws.rs.core.MultivaluedMap;
import org.apache.cxf.common.util.ProxyHelper;
+import org.apache.cxf.feature.AbstractFeature;
import org.apache.cxf.jaxrs.model.UserResource;
/**
@@ -56,7 +57,20 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public staticT T create(String baseAddress, ClassT cls,
ClassLoader loader) {
+
+ return create(baseAddress, cls, loader, null);
+ }
+
+ /**
+ * Creates a proxy using a custom class loader
+ * @param baseAddress baseAddress
+ * @param loader class loader
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @return typed proxy
+ */
+ public staticT T create(String baseAddress, ClassT cls,
ClassLoader loader, ListAbstractFeature features) {
JAXRSClientFactoryBean bean = getBean(baseAddress, cls, null);
+ bean.setFeatures(features);
bean.setClassLoader(loader);
return bean.create(cls);
}
@@ -80,18 +94,30 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public staticT T create(URI baseURI, ClassT cls, boolean
inheritHeaders) {
-
+ return create(baseURI, cls, inheritHeaders, null);
+ }
+
+ /**
+ * Creates a proxy
+ * @param baseURI baseURI
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @param inheritHeaders if true then existing proxy headers will be
inherited by
+ * subresource proxies if any
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+ public staticT T create(URI baseURI, ClassT cls, boolean
inheritHeaders, ListAbstractFeature features) {
JAXRSClientFactoryBean bean = getBean(baseURI.toString(), cls, null);
bean.setInheritHeaders(inheritHeaders);
+ bean.setFeatures(features);
return bean.create(cls);
-
}
/**
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
- * @param config classpath location of Spring configuration resource
+ * @param configLocation classpath location of Spring configuration
resource
* @return typed proxy
*/
public staticT T create(String baseAddress, ClassT cls, String
configLocation) {
@@ -103,9 +129,42 @@ public final class JAXRSClientFactory {
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
+ * @param configLocation classpath location of Spring configuration
resource
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+ public staticT T create(String baseAddress, ClassT cls, String
configLocation,
+ ListAbstractFeature features) {
+ JAXRSClientFactoryBean bean = getBean(baseAddress, cls,
configLocation);
+ bean.setFeatures(features);
+ return
Re: svn commit: r1343446
11 new methods have been introduced, with 3 of the existing methods made
to loop by mistake.
I have replaced them with a single one that should catch most of the
typical cases where setting a features is also required. Also added a
similar WebClient factory method.
Lets chat next time before making major changes like this one.
Cheers, Sergey
On 29/05/12 10:12, Sergey Beryozkin wrote:
By the way, Willem, if you have any specific preference on how such a
single method would like then lets work on it, ping me here or IRC
I'm thinking of having the one or max two methods which can take an
address, class, and the list of features. JAXRSClientFactory can not
take all the variations really - one may want then to offer a support
for accepting in or out or both in/out interceptors, etc - hope you see
what I mean
Sergey
On 29/05/12 10:00, Sergey Beryozkin wrote:
Hi Willem
I'd really prefer us discussing updates like this one to the public
client API that the CXF JAX-RS runtime offers.
I can see you just added 5 or so new JAXRSClientFactory methods.
I consider most of them redundant. JAXRSClientFactory is a *utility*
factory and is already a bit overloaded without these new extra 5
methods added.
JAXRSClientFactoryBean is always there to offer a more custom approach
toward creating a proxy and I would like to revert most of the methods
you added.
I agree it may make sense to offer say a single utility method for
accepting the features, but I'd not like to have 5+ variations, the API
will become too 'noisy'. Besides the same would then need to be added to
WebClient factory methods...
I'll take care of updating the api
Thanks, Sergey
On 29/05/12 02:39, ningji...@apache.org wrote:
Author: ningjiang
Date: Tue May 29 01:39:02 2012
New Revision: 1343446
URL: http://svn.apache.org/viewvc?rev=1343446view=rev
Log:
CXF-4345 Allow user-secified feautres for JAXRSClientFactory
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java?rev=1343446r1=1343445r2=1343446view=diff
==
---
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
(original)
+++
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
Tue May 29 01:39:02 2012
@@ -26,6 +26,7 @@ import java.util.List;
import javax.ws.rs.core.MultivaluedMap;
import org.apache.cxf.common.util.ProxyHelper;
+import org.apache.cxf.feature.AbstractFeature;
import org.apache.cxf.jaxrs.model.UserResource;
/**
@@ -56,7 +57,20 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public staticT T create(String baseAddress, ClassT cls,
ClassLoader loader) {
+
+ return create(baseAddress, cls, loader, null);
+ }
+
+ /**
+ * Creates a proxy using a custom class loader
+ * @param baseAddress baseAddress
+ * @param loader class loader
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @return typed proxy
+ */
+ public staticT T create(String baseAddress, ClassT cls,
ClassLoader loader, ListAbstractFeature features) {
JAXRSClientFactoryBean bean = getBean(baseAddress, cls, null);
+ bean.setFeatures(features);
bean.setClassLoader(loader);
return bean.create(cls);
}
@@ -80,18 +94,30 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public staticT T create(URI baseURI, ClassT cls, boolean
inheritHeaders) {
-
+ return create(baseURI, cls, inheritHeaders, null);
+ }
+
+ /**
+ * Creates a proxy
+ * @param baseURI baseURI
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @param inheritHeaders if true then existing proxy headers will be
inherited by
+ * subresource proxies if any
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+ public staticT T create(URI baseURI, ClassT cls, boolean
inheritHeaders, ListAbstractFeature features) {
JAXRSClientFactoryBean bean = getBean(baseURI.toString(), cls, null);
bean.setInheritHeaders(inheritHeaders);
+ bean.setFeatures(features);
return bean.create(cls);
-
}
/**
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
- * @param config classpath location of Spring configuration resource
+ * @param configLocation classpath location of Spring configuration
resource
* @return typed proxy
*/
public staticT T create(String baseAddress, ClassT cls, String
configLocation) {
@@ -103,9 +129,42 @@ public final class JAXRSClientFactory {
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
+ * @param
Re: Thoughts about DOSGI 1.3.2 release
On 29/05/12 08:12, David Bosschaert wrote: Migrating to blueprint will also solve https://issues.apache.org/jira/browse/DOSGI-69 which is a long-standing issue that many people want to see resolved. Agreed. I'd still see this migration as a 1.4-level issue. I can see 4-5 issues in the list that can help people with getting to move forward with DOSGi without requiring a lot of time to spend on fixing them, so I'd look at them for 1.3.2 It's a shame I've a little understanding at the moment how Aries works under the hood, not to say how Gemini does :-). I'm having some little progress with a single patch I just did for Aries though :-) Having someone who has a deeper understanding of Aries and possibly Gemini contributing toward this possible migration would be welcome. Cheers, Sergey David On 28 May 2012 18:51, Sergey Beryozkinsberyoz...@gmail.com wrote: FYI: https://issues.apache.org/jira/browse/DOSGI-115 The proposed fix will probably work with Gemini straight away :-) Sergey On 28/05/12 18:45, Sergey Beryozkin wrote: On 28/05/12 18:35, David Bosschaert wrote: I can understand that it's a significant refactoring. If you stay within the pure Blueprint model (within the spec) you shouldn't get bound to Aries. Eclipse Gemini also has an implementation. Sure and there was a proposal on how to get Gemini used under the hood, but the issue is how to get both used as needed. Having DOSGi migrated to Blueprint and CXF 2.6.x would obviously improve DOSGi CXF a lot, specifically, its OSGI-'awareness' would increase a lot. But as I said, there are still quite a few issues in this list: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+DOSGI+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC which IMHO are quite important to get fixed for the users be able to do their POCs, before making a big 'leap' forward. Unfortunately I can not afford spending several weeks on migrating the code to Blueprint, testing with Aries Gemini, etc...Perhaps we will get a bit of help from DOSGI CXF users :-) Cheers, Sergey Cheers, David On 28 May 2012 18:17, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi David On 28/05/12 18:09, David Bosschaert wrote: Sounds good, Sergey. I'm all for releasing frequently. One of the things that I think would be good to tackle is to migrate to OSGi Blueprint (from of the current Spring-based approach). Is that something that you were thinking of looking at? Not really. Some users would like to use Blueprint but not be bound to Aries. So for me it's a DOSGI 1.4 level issue which will require a significant time investment. Cheers, Sergey Cheers, David On 28 May 2012 17:34, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi I'm thinking of starting working toward releasing DOSGI 1.3.2. I think I'll spend the next 2 or months on fixing few issues I can find some time for, given that there's a lot of other CXF/etc work that needs to be taken care of. I'd like to suggest that the next release will be 1.3.2 as opposed to 1.4.0. Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort, giving that a minimal bundle in CXF 2.6.x has gone. It seems that there are still quite a few issues there that are important to be fixed for the base/simple DOSGI applications to work reliably and given that 2.5.x branch is still relatively 'young', I'd probably prefer to stay on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI 1.3.3), simply to make the most of the limited time that I will be able to spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by that time many of the 'basic' DOSGI features have been fixed... Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1343446
On 29/05/12 14:07, Willem Jiang wrote:
Hi Sergey,
JAXRSClientFactory provides the static method to create the proxy or the
client. I didn't find a better way to apply the features to all these
method by just changing a single method.
If you have a better idea, please share it with me.
BTW, I just found my commit introduced a stall over follow issue, I will
commit a patch to fix the build right way.
I already fixed it
As I said, JAXRSClientFactoryBean can always be used.
Having a single utility method should be enough,
Sergey
On 5/29/12 5:00 PM, Sergey Beryozkin wrote:
Hi Willem
I'd really prefer us discussing updates like this one to the public
client API that the CXF JAX-RS runtime offers.
I can see you just added 5 or so new JAXRSClientFactory methods.
I consider most of them redundant. JAXRSClientFactory is a *utility*
factory and is already a bit overloaded without these new extra 5
methods added.
JAXRSClientFactoryBean is always there to offer a more custom approach
toward creating a proxy and I would like to revert most of the methods
you added.
I agree it may make sense to offer say a single utility method for
accepting the features, but I'd not like to have 5+ variations, the API
will become too 'noisy'. Besides the same would then need to be added to
WebClient factory methods...
I'll take care of updating the api
Thanks, Sergey
On 29/05/12 02:39, ningji...@apache.org wrote:
Author: ningjiang
Date: Tue May 29 01:39:02 2012
New Revision: 1343446
URL: http://svn.apache.org/viewvc?rev=1343446view=rev
Log:
CXF-4345 Allow user-secified feautres for JAXRSClientFactory
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
Modified:
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java?rev=1343446r1=1343445r2=1343446view=diff
==
---
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
(original)
+++
cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/client/JAXRSClientFactory.java
Tue May 29 01:39:02 2012
@@ -26,6 +26,7 @@ import java.util.List;
import javax.ws.rs.core.MultivaluedMap;
import org.apache.cxf.common.util.ProxyHelper;
+import org.apache.cxf.feature.AbstractFeature;
import org.apache.cxf.jaxrs.model.UserResource;
/**
@@ -56,7 +57,20 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public staticT T create(String baseAddress, ClassT cls,
ClassLoader loader) {
+
+ return create(baseAddress, cls, loader, null);
+ }
+
+ /**
+ * Creates a proxy using a custom class loader
+ * @param baseAddress baseAddress
+ * @param loader class loader
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @return typed proxy
+ */
+ public staticT T create(String baseAddress, ClassT cls,
ClassLoader loader, ListAbstractFeature features) {
JAXRSClientFactoryBean bean = getBean(baseAddress, cls, null);
+ bean.setFeatures(features);
bean.setClassLoader(loader);
return bean.create(cls);
}
@@ -80,18 +94,30 @@ public final class JAXRSClientFactory {
* @return typed proxy
*/
public staticT T create(URI baseURI, ClassT cls, boolean
inheritHeaders) {
-
+ return create(baseURI, cls, inheritHeaders, null);
+ }
+
+ /**
+ * Creates a proxy
+ * @param baseURI baseURI
+ * @param cls resource class, if not interface then a CGLIB proxy
will be created
+ * @param inheritHeaders if true then existing proxy headers will be
inherited by
+ * subresource proxies if any
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+ public staticT T create(URI baseURI, ClassT cls, boolean
inheritHeaders, ListAbstractFeature features) {
JAXRSClientFactoryBean bean = getBean(baseURI.toString(), cls, null);
bean.setInheritHeaders(inheritHeaders);
+ bean.setFeatures(features);
return bean.create(cls);
-
}
/**
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
- * @param config classpath location of Spring configuration resource
+ * @param configLocation classpath location of Spring configuration
resource
* @return typed proxy
*/
public staticT T create(String baseAddress, ClassT cls, String
configLocation) {
@@ -103,9 +129,42 @@ public final class JAXRSClientFactory {
* Creates a proxy
* @param baseAddress baseAddress
* @param cls resource class, if not interface then a CGLIB proxy will
be created
+ * @param configLocation classpath location of Spring configuration
resource
+ * @param features, the features which will be applied to the client
+ * @return typed proxy
+ */
+ public staticT T create(String baseAddress, ClassT cls, String
configLocation,
+ ListAbstractFeature features
Re: Discussion about using JMS transport with CXFRS
Hi Willem On 29/05/12 14:53, Willem Jiang wrote: Hi, I just have a chance to go through the missing feature of JMS transport to support cxfrs frontend. Current JMS transport doesn't send out Message.REQUEST_URI and Message.HTTP_REQUEST_METHOD properties as the HTTP transport does. So it hard for use the use the cxfrs frontend with JMS transport. My question is do we need to transfer other properties which could be used by cxfrs frondend? The above properties are defaulted to / and POST respectively but can be customized via JMS properties And The AbstractClient is tend to use HttpConnection to get the headers for build the response, it stops the user to leverage other transports. We may need to update this part of code. +1. I did few changes to address https://issues.apache.org/jira/browse/CXF-3562, but I will prioritize on it after 2.6.1 is out. It is also needed for the future async support, alternative HTTP stacks support, etc, so it's time to start addressing it Cheers, Sergey Any thoughts? -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Delaying 2.6.1/2.5.4 due to test failures...
On 29/05/12 21:10, Daniel Kulp wrote: We have a bunch of test failures in the rs-security stuff with Java 5: https://builds.apache.org/view/A-F/view/CXF/job/CXF-Trunk-JDK15/ https://builds.apache.org/view/A-F/view/CXF/job/CXF-2.5.x/ which needs to get resolved before the release. Thus, I'm going to delay this build until tomorrow. Colm and Sergey: can you look at those please? Looking into it now. I fear I've messed it up with my updates to the client runtime...Though why on Java 5 only, not sure yet Sergey I'm checking 2.4.x as well. I may have to redo that build.
Re: Delaying 2.6.1/2.5.4 due to test failures...
Hi On 29/05/12 21:52, Daniel Kulp wrote: On Tuesday, May 29, 2012 09:49:36 PM Sergey Beryozkin wrote: On 29/05/12 21:10, Daniel Kulp wrote: We have a bunch of test failures in the rs-security stuff with Java 5: https://builds.apache.org/view/A-F/view/CXF/job/CXF-Trunk-JDK15/ https://builds.apache.org/view/A-F/view/CXF/job/CXF-2.5.x/ which needs to get resolved before the release. Thus, I'm going to delay this build until tomorrow. Colm and Sergey: can you look at those please? Looking into it now. I fear I've messed it up with my updates to the client runtime...Though why on Java 5 only, not sure yet Well, they fail on Java 7 as well. :-) I believe I've got it fixed. The issue will be there in CXF 2.4.8 but not in 2.4.9, I think it's very rare that the client code would replace say Book.class with DOMSource class, so hopefully no CXF 2.4.8 users will ever see this problem and I think we will be able to offer a workaround by setting the out message properties if really needed. Sorry for a big mess, Sergey Dan Sergey I'm checking 2.4.x as well. I may have to redo that build. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: Thoughts about DOSGI 1.3.2 release
Hi David On 28/05/12 18:09, David Bosschaert wrote: Sounds good, Sergey. I'm all for releasing frequently. One of the things that I think would be good to tackle is to migrate to OSGi Blueprint (from of the current Spring-based approach). Is that something that you were thinking of looking at? Not really. Some users would like to use Blueprint but not be bound to Aries. So for me it's a DOSGI 1.4 level issue which will require a significant time investment. Cheers, Sergey Cheers, David On 28 May 2012 17:34, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi I'm thinking of starting working toward releasing DOSGI 1.3.2. I think I'll spend the next 2 or months on fixing few issues I can find some time for, given that there's a lot of other CXF/etc work that needs to be taken care of. I'd like to suggest that the next release will be 1.3.2 as opposed to 1.4.0. Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort, giving that a minimal bundle in CXF 2.6.x has gone. It seems that there are still quite a few issues there that are important to be fixed for the base/simple DOSGI applications to work reliably and given that 2.5.x branch is still relatively 'young', I'd probably prefer to stay on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI 1.3.3), simply to make the most of the limited time that I will be able to spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by that time many of the 'basic' DOSGI features have been fixed... Thanks, Sergey
Re: Thoughts about DOSGI 1.3.2 release
On 28/05/12 18:35, David Bosschaert wrote: I can understand that it's a significant refactoring. If you stay within the pure Blueprint model (within the spec) you shouldn't get bound to Aries. Eclipse Gemini also has an implementation. Sure and there was a proposal on how to get Gemini used under the hood, but the issue is how to get both used as needed. Having DOSGi migrated to Blueprint and CXF 2.6.x would obviously improve DOSGi CXF a lot, specifically, its OSGI-'awareness' would increase a lot. But as I said, there are still quite a few issues in this list: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+DOSGI+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC which IMHO are quite important to get fixed for the users be able to do their POCs, before making a big 'leap' forward. Unfortunately I can not afford spending several weeks on migrating the code to Blueprint, testing with Aries Gemini, etc...Perhaps we will get a bit of help from DOSGI CXF users :-) Cheers, Sergey Cheers, David On 28 May 2012 18:17, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi David On 28/05/12 18:09, David Bosschaert wrote: Sounds good, Sergey. I'm all for releasing frequently. One of the things that I think would be good to tackle is to migrate to OSGi Blueprint (from of the current Spring-based approach). Is that something that you were thinking of looking at? Not really. Some users would like to use Blueprint but not be bound to Aries. So for me it's a DOSGI 1.4 level issue which will require a significant time investment. Cheers, Sergey Cheers, David On 28 May 2012 17:34, Sergey Beryozkinsberyoz...@gmail.comwrote: Hi I'm thinking of starting working toward releasing DOSGI 1.3.2. I think I'll spend the next 2 or months on fixing few issues I can find some time for, given that there's a lot of other CXF/etc work that needs to be taken care of. I'd like to suggest that the next release will be 1.3.2 as opposed to 1.4.0. Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort, giving that a minimal bundle in CXF 2.6.x has gone. It seems that there are still quite a few issues there that are important to be fixed for the base/simple DOSGI applications to work reliably and given that 2.5.x branch is still relatively 'young', I'd probably prefer to stay on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI 1.3.3), simply to make the most of the limited time that I will be able to spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by that time many of the 'basic' DOSGI features have been fixed... Thanks, Sergey
Re: Thoughts about DOSGI 1.3.2 release
FYI: https://issues.apache.org/jira/browse/DOSGI-115 The proposed fix will probably work with Gemini straight away :-) Sergey On 28/05/12 18:45, Sergey Beryozkin wrote: On 28/05/12 18:35, David Bosschaert wrote: I can understand that it's a significant refactoring. If you stay within the pure Blueprint model (within the spec) you shouldn't get bound to Aries. Eclipse Gemini also has an implementation. Sure and there was a proposal on how to get Gemini used under the hood, but the issue is how to get both used as needed. Having DOSGi migrated to Blueprint and CXF 2.6.x would obviously improve DOSGi CXF a lot, specifically, its OSGI-'awareness' would increase a lot. But as I said, there are still quite a few issues in this list: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+DOSGI+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC which IMHO are quite important to get fixed for the users be able to do their POCs, before making a big 'leap' forward. Unfortunately I can not afford spending several weeks on migrating the code to Blueprint, testing with Aries Gemini, etc...Perhaps we will get a bit of help from DOSGI CXF users :-) Cheers, Sergey Cheers, David On 28 May 2012 18:17, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi David On 28/05/12 18:09, David Bosschaert wrote: Sounds good, Sergey. I'm all for releasing frequently. One of the things that I think would be good to tackle is to migrate to OSGi Blueprint (from of the current Spring-based approach). Is that something that you were thinking of looking at? Not really. Some users would like to use Blueprint but not be bound to Aries. So for me it's a DOSGI 1.4 level issue which will require a significant time investment. Cheers, Sergey Cheers, David On 28 May 2012 17:34, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi I'm thinking of starting working toward releasing DOSGI 1.3.2. I think I'll spend the next 2 or months on fixing few issues I can find some time for, given that there's a lot of other CXF/etc work that needs to be taken care of. I'd like to suggest that the next release will be 1.3.2 as opposed to 1.4.0. Moving to CXF 2.6.1 at the DOSGI level will be a pretty major effort, giving that a minimal bundle in CXF 2.6.x has gone. It seems that there are still quite a few issues there that are important to be fixed for the base/simple DOSGI applications to work reliably and given that 2.5.x branch is still relatively 'young', I'd probably prefer to stay on 2.5.x (2.5.4 for DOSGI 1.3.2 and might be CXF 2.5.5/2.5.6 for DOSGI 1.3.3), simply to make the most of the limited time that I will be able to spend on DOSGi, before making a major switch to CXF 2.6.x - and hoping by that time many of the 'basic' DOSGI features have been fixed... Thanks, Sergey -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
