Re: Delaying 2.6.1/2.5.4 due to test failures...
On Wednesday, May 30, 2012 09:14:25 AM Willem Jiang wrote: > Hi , > > I just found I forgot to commit merge of r1343561 yesterday. And it was > marked as integrated in CXF-2.4.x branch. > I will commit the patch after running some tests, It could be better if > we redo the CXF 2.4.8 release again. I agree. It's not a big deal so I'll handle that tomorrow as well. Dan > > Sorry for the mass that I made. > > Willem > > On Wed May 30 06:02:54 2012, Sergey Beryozkin wrote: > > 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. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Delaying 2.6.1/2.5.4 due to test failures...
Hi , I just found I forgot to commit merge of r1343561 yesterday. And it was marked as integrated in CXF-2.4.x branch. I will commit the patch after running some tests, It could be better if we redo the CXF 2.4.8 release again. Sorry for the mass that I made. Willem On Wed May 30 06:02:54 2012, Sergey Beryozkin wrote: 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.
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: Delaying 2.6.1/2.5.4 due to test failures...
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. :-) Dan > > Sergey > > > I'm checking 2.4.x as well. I may have to redo that build. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.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.
Delaying 2.6.1/2.5.4 due to test failures...
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? I'm checking 2.4.x as well. I may have to redo that build. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Discussion about using JMS transport with CXFRS
On Tue May 29 22:33:59 2012, Sergey Beryozkin wrote: 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 Thanks, I will try to write some test tomorrow. 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 sounds good. Cheers, Sergey Any thoughts? -- Willem -- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
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
Discussion about using JMS transport with CXFRS
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? 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. Any thoughts? -- Willem
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=1343446&view=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=1343446&r1=1343445&r2=1343446&view=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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls,
ClassLoader loader, List 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 static T create(URI baseURI, Class 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 static T create(URI baseURI, Class cls, boolean
inheritHeaders, List 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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls, String
configLocation,
+ List features) {
+ JAXRSClientFactoryBean bean = getBean(baseAddress, cls,
configLocati
Re: svn commit: r1343446
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.
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=1343446&view=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=1343446&r1=1343445&r2=1343446&view=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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls,
ClassLoader loader, List 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 static T create(URI baseURI, Class 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 static T create(URI baseURI, Class cls, boolean
inheritHeaders, List 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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls, String
configLocation,
+ List features) {
+ JAXRSClientFactoryBean bean = getBean(baseAddress, cls,
configLocation);
+ bean.setFeatures(features);
+ return bean.create(cls);
+ }
+
+ /**
+ * Creates a proxy
+ * @param baseAddress baseAddress
+ * @param cls resource class, if not interfac
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 Beryozkin 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=true&mode=hide&jqlQuery=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 Beryozkin 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 Beryozkin 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
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=1343446&view=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=1343446&r1=1343445&r2=1343446&view=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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls,
ClassLoader loader, List 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 static T create(URI baseURI, Class 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 static T create(URI baseURI, Class cls, boolean
inheritHeaders, List 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 static T create(String baseAddress, Class 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
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=1343446&view=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=1343446&r1=1343445&r2=1343446&view=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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls,
ClassLoader loader, List 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 static T create(URI baseURI, Class 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 static T create(URI baseURI, Class cls, boolean
inheritHeaders, List 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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls, String
configLocation,
+ List features) {
+ JAXRSClientFactoryBean bean = getBean(baseAddress, cls,
configLocation);
+ bean.setFeatures(features);
+ return bean.create(cls);
+ }
+
+ /**
+ * Creates a proxy
+ * @param
Re: svn commit: r1343446
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=1343446&view=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=1343446&r1=1343445&r2=1343446&view=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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls, ClassLoader
loader, List 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 static T create(URI baseURI, Class 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 static T create(URI baseURI, Class cls, boolean inheritHeaders,
List 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 static T create(String baseAddress, Class 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 static T create(String baseAddress, Class cls, String
configLocation,
+ List features) {
+JAXRSClientFactoryBean bean = getBean(baseAddress, cls,
configLocation);
+bean.setFeatures(features);
+return bean.create(cls);
+}
+
+/**
+ * Creates a proxy
+ * @param baseAddress baseAddress
+ * @param cls resourc
Re: Thoughts about DOSGI 1.3.2 release
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. David On 28 May 2012 18:51, Sergey Beryozkin 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=true&mode=hide&jqlQuery=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 Beryozkin 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 Beryozkin 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
