Re: JAX-RS test failure with IBM JDK...
Hi Dan I'm working on trying to get things building/passing with the IBM JDK again. (mostly to attempt to get the Progress AIX builds to actually succeed) I'm getting this failure in JAX-RS: testSchemeHostPortQueryFragment(org.apache.cxf.jaxrs.impl.UriBuilderImplTest) Time elapsed: 0.003 sec FAILURE! java.lang.AssertionError: URI is not built correctly expected:http://foo:1234/bar?n2=v2n1=v1#fragment but was:http://foo:1234/bar?n1=v1n2=v2#fragment Does the order of the params in there matter? Is this a legitimate test failure or is the assertion invalid? I think this assertion is too strict as the order of query parameters does not matter. It appears the java.net.URI implementation is done differently in the IBM JDK so may be this test can be changed to compare the expected URI against both n2=v2n1=v1 and n1=v1n2=v2, or may be the better option would be to convert the expected string into URI and compare it to the instance returned by UriBuilder... Let me know please which tests are failing and I update them accordingly cheers, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: svn commit: r763742 - /cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java
When running system tests, I often do
mvn test -Dtest=JAXRS*,
to save the time, if I'm confident no other CXF functionality has been affected
by the current JAXRS related changes.
I always do now 'mvn clean install' when building frontend/jaxrs, as I've already been bitten by Eclipse and Maven collaborating in
hidng the compilation problems. For systests I'll probably just do
mvn clean test -Dtest=JAXRS*,
it should be reliable enough
Dan - thanks for a fix
Cheers, Sergey
- Original Message -
From: dk...@apache.org
To: comm...@cxf.apache.org
Sent: Thursday, April 09, 2009 6:32 PM
Subject: svn commit: r763742 -
/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java
Author: dkulp
Date: Thu Apr 9 17:32:06 2009
New Revision: 763742
URL: http://svn.apache.org/viewvc?rev=763742view=rev
Log:
Fix compile failures
Modified:
cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java
Modified:
cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java
URL:
http://svn.apache.org/viewvc/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java?rev=763742r1=763741r2=763742view=diff
==
---
cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java
(original)
+++
cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java
Thu Apr 9 17:32:06 2009
@@ -33,20 +33,22 @@
public class GenericHandlerWriter implements
MessageBodyWriterGenericHandlerBook {
-public long getSize(GenericHandlerBook t, Class type, Type genericType,
Annotation[] annotations,
+public long getSize(GenericHandlerBook t, Class? type, Type
genericType, Annotation[] annotations,
MediaType mediaType) {
return -1;
}
-public boolean isWriteable(Class type, Type genericType, Annotation[]
annotations, MediaType mediaType) {
+public boolean isWriteable(Class? type, Type genericType,
+ Annotation[] annotations, MediaType mediaType) {
return type == GenericHandler.class
InjectionUtils.getActualType(genericType) == Book.class;
}
-public void writeTo(GenericHandlerBook o, Class c, Type t, Annotation[]
anns, MediaType m,
+public void writeTo(GenericHandlerBook o, Class? c, Type t,
Annotation[] anns, MediaType m,
MultivaluedMapString, Object headers, OutputStream os)
throws IOException, WebApplicationException {
JAXBElementProvider jaxb = new JAXBElementProvider();
jaxb.writeTo(o.getEntity(), c, InjectionUtils.getActualType(t), anns,
m, headers, os);
}
+
}
Re: Distributed OSGi Discovery implementation in CXF
Hi David, This would be a very welcome addition to the distributed OSGi support in CXF! So please, fire away and commit what you've done so far. Thanks, Eoghan 2009/4/10 David Bosschaert david.bosscha...@gmail.com: Hi all, Over the past while I have done some experimentation around a possible implementation of the Distributed OSGi RFC 119 Discovery service. The current CXF-DOSGi codebase only contains the Distribution Software (DSW) component, which means that you need to configure the location of your remote services manually. Adding a Discovery service (as specified in RFC 119) would enable dynamic discovery of remote services as well. I've started using Apache Zookeeper as the underlying technology to implement a Discovery service and at this stage I have it working, although what I have is not completely finished. I think this could be a useful addition to the CXF DOSGi codebase, as together with the DSW code that's already there it would provide the implementation of the two core parts of RFC 119. If folks agree that this is useful to have, I can start contributing this to the http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery and continue working on it from that location. Thoughts anyone? Cheers, David
Re: Distributed OSGi Discovery implementation in CXF
Hi, Hi all, Over the past while I have done some experimentation around a possible implementation of the Distributed OSGi RFC 119 Discovery service. The current CXF-DOSGi codebase only contains the Distribution Software (DSW) component, which means that you need to configure the location of your remote services manually. Adding a Discovery service (as specified in RFC 119) would enable dynamic discovery of remote services as well. I've started using Apache Zookeeper as the underlying technology to implement a Discovery service and at this stage I have it working, although what I have is not completely finished. I think this could be a useful addition to the CXF DOSGi codebase, as together with the DSW code that's already there it would provide the implementation of the two core parts of RFC 119. If folks agree that this is useful to have, I can start contributing this to the http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery and continue working on it from that location. +1. It would make the CXf DOSGi implementation much more self-contained and ready to be used out of the box in distributed environments Would it still make sense to keep the Local Discovery service implementation ? For ex to test against multiple Discovery instances ? cheers, Sergey Thoughts anyone? Cheers, David
Re: Distributed OSGi Discovery implementation in CXF
2009/4/10 Sergey Beryozkin sbery...@progress.com: Would it still make sense to keep the Local Discovery service implementation ? For ex to test against multiple Discovery instances ? I think we definitely need to keep the local discovery service intact in order to support the static remote-services.xml style of configuration. Cheers, Eoghan
