Re: svn commit: r1302802 - in /cxf/branches/2.5.x-fixes: rt/bindings/http/ rt/databinding/aegis/ rt/databinding/xmlbeans/ rt/frontend/jaxrs/ rt/javascript/javascript-tests/ rt/transports/http/ systest
Thank you sirs!
On Mar 20, 2012, at 6:54 PM, Freeman Fang wrote:
> Ok, rallback this change on our fixes branches.
>
> Thanks
> Freeman
> On 2012-3-20, at 下午9:34, Daniel Kulp wrote:
>
>>
>> I'm concerned about this commit. This could potentially remove jars from
>> peoples classpaths which can easily cause breakages. As an example, with
>> this change the wsdl_first example doesn't even compile anymore. I'm
>> definitely OK with the idea on trunk (think it's already done there), but
>> definitely have concerns about it on the fixes branches. Especially on
>> 2.4.x where spring is a bit more heavily used internally. The fact that
>> some of our own samples break shows it could have impact on users.
>>
>> Dan
>>
>>
>>
>> On Tuesday, March 20, 2012 10:12:12 AM ff...@apache.org wrote:
>>> Author: ffang
>>> Date: Tue Mar 20 09:08:19 2012
>>> New Revision: 1302802
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1302802&view=rev
>>> Log:
>>> rt-transports-http module should optionally depend on spring
>>>
>>> Modified:
>>> cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml
>>> cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml
>>> cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
>>> cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml
>>> cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml
>>> cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml
>>> cxf/branches/2.5.x-fixes/systests/databinding/pom.xml
>>> cxf/branches/2.5.x-fixes/systests/jaxrs/pom.xml
>>> cxf/branches/2.5.x-fixes/systests/rs-security/pom.xml
>>> cxf/branches/2.5.x-fixes/systests/ws-security-examples/pom.xml
>>> cxf/branches/2.5.x-fixes/systests/ws-security/pom.xml
>>> cxf/branches/2.5.x-fixes/tools/javato/ws/pom.xml
>>>
>>> Modified: cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/bindings/http/po
>>> m.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
>>> =
>>> = --- cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml (original) +++
>>> cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml Tue Mar 20 09:08:19
>>> 2012 @@ -87,6 +87,11 @@
>>>slf4j-jdk14
>>>test
>>>
>>> +
>>> +org.springframework
>>> +spring-context
>>> +test
>>> +
>>>
>>>
>>>
>>>
>>> Modified: cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/databinding/aegi
>>> s/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
>>> =
>>> = --- cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml (original)
>>> +++ cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml Tue Mar 20
>>> 09:08:19 2012 @@ -62,6 +62,11 @@
>>>test
>>>
>>>
>>> +org.springframework
>>> +spring-context
>>> +test
>>> +
>>> +
>>>org.apache.cxf
>>>cxf-rt-transports-http-jetty
>>>${project.version}
>>>
>>> Modified: cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/databinding/xmlb
>>> eans/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
>>> =
>>> = --- cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
>>> (original) +++ cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
>>> Tue Mar 20 09:08:19 2012 @@ -102,6 +102,11 @@
>>>${project.version}
>>>test
>>>
>>> +
>>> +org.springframework
>>> +spring-context
>>> +test
>>> +
>>>
>>>
>>>
>>>
>>> Modified: cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/p
>>> om.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
>>> =
>>> = --- cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml (original)
>>> +++ cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml Tue Mar 20
>>> 09:08:19 2012 @@ -182,6 +182,10 @@
>>>easymock
>>>test
>>>
>>> +
>>> +org.springframework
>>> +spring-context
>>> +
>>>
>>>
>>>
>>>
>>> Modified: cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/javascript/javas
>>> cript-tests/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
>>> =
>>> = --- cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml
>>> (original) +++
>>> cxf/branches/2.5.x-fixes/rt/j
Re: svn commit: r1302802 - in /cxf/branches/2.5.x-fixes: rt/bindings/http/ rt/databinding/aegis/ rt/databinding/xmlbeans/ rt/frontend/jaxrs/ rt/javascript/javascript-tests/ rt/transports/http/ systest
Ok, rallback this change on our fixes branches.
Thanks
Freeman
On 2012-3-20, at 下午9:34, Daniel Kulp wrote:
I'm concerned about this commit. This could potentially remove
jars from
peoples classpaths which can easily cause breakages. As an
example, with
this change the wsdl_first example doesn't even compile anymore. I'm
definitely OK with the idea on trunk (think it's already done
there), but
definitely have concerns about it on the fixes branches. Especially
on
2.4.x where spring is a bit more heavily used internally. The
fact that
some of our own samples break shows it could have impact on users.
Dan
On Tuesday, March 20, 2012 10:12:12 AM ff...@apache.org wrote:
Author: ffang
Date: Tue Mar 20 09:08:19 2012
New Revision: 1302802
URL: http://svn.apache.org/viewvc?rev=1302802&view=rev
Log:
rt-transports-http module should optionally depend on spring
Modified:
cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml
cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml
cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml
cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml
cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml
cxf/branches/2.5.x-fixes/systests/databinding/pom.xml
cxf/branches/2.5.x-fixes/systests/jaxrs/pom.xml
cxf/branches/2.5.x-fixes/systests/rs-security/pom.xml
cxf/branches/2.5.x-fixes/systests/ws-security-examples/pom.xml
cxf/branches/2.5.x-fixes/systests/ws-security/pom.xml
cxf/branches/2.5.x-fixes/tools/javato/ws/pom.xml
Modified: cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/bindings/http/po
m.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
=
=
=
=
=
= --- cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml
(original) +++
cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml Tue Mar 20 09:08:19
2012 @@ -87,6 +87,11 @@
slf4j-jdk14
test
+
+org.springframework
+spring-context
+test
+
Modified: cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/databinding/aegi
s/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
=
=
=
=
=
= --- cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml
(original)
+++ cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml Tue Mar 20
09:08:19 2012 @@ -62,6 +62,11 @@
test
+org.springframework
+spring-context
+test
+
+
org.apache.cxf
cxf-rt-transports-http-jetty
${project.version}
Modified: cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/databinding/xmlb
eans/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
=
=
=
=
=
= --- cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
(original) +++ cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/
pom.xml
Tue Mar 20 09:08:19 2012 @@ -102,6 +102,11 @@
${project.version}
test
+
+org.springframework
+spring-context
+test
+
Modified: cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/p
om.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
=
=
=
=
=
= --- cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml
(original)
+++ cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml Tue Mar 20
09:08:19 2012 @@ -182,6 +182,10 @@
easymock
test
+
+org.springframework
+spring-context
+
Modified: cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/
pom.xml
URL:
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/javascript/javas
cript-tests/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
=
=
=
=
=
= --- cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/
pom.xml
(original) +++
cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml Tue
Mar
20 09:08:19 2012 @@ -67,6 +67,11 @@
test
+org.springframework
+spring-context
+test
+
+
xerces
xercesImpl
test
Modified: cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml
URL:
http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/transports/http/
pom.xml?rev=1302802&r1=1302801&r2
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi David On 20/03/12 11:00, David Bosschaert wrote: Hi Sergey, On 20 March 2012 09:47, Sergey Beryozkin wrote: Hi David On 20/03/12 08:00, David Bosschaert wrote: I just got confirmation that the current trunk of the CXF-DOSGi passes the TCK again. Great news, thanks for the support from your side, It would be *really* good if we could release this version so that the Remote Services and RSA RI in the OSGi systems is a released version of CXF-DOSGi rather than a snapshot. Sergey, could I maybe ask you to do a release again? I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs have been opened against 1.3 so I'll try to address some of them too before cutting a new release. The TCK compliance work I did was part of the OSGi 4.3 Compendium cycle and I expect that the RIs for that (of which CXF-DOSGi is part) will be collected soon - within 2 weeks is my guess, but I can get a more detailed deadline if needed. If we want a released version of CXF-DOSGi to be part of that RI, we need to have that release before then. Otherwise they'll take the current version which is based on a 1.4 snapshot... Would there be an issue with just releasing what's there now (read: really soon) and maybe do a 1.3.2 in June/July? I've never done an Apache release so I'm not really sure how much work is involved, but if it's just a matter of a few commands, I think it would be worth it doing it now - but obviously that all depends on time people have available too... How does this Compendium cycle work ? Having CXF DOSGi RI 'endorced' as TCK-compliant is a strong enough reason to try to cut an interim release in the next few weeks, however, I'm wondering, when would be DOSGi CXF 1.3.1 (released say in June/Jule) collected during the next cycle ? I guess you are right in won't take long to quickly do another release, my priorities are all on CXF 2.6.0 (and related projects) due in 2-3 weeks, but I guess this can be done quickly enough. Personally I'd prefer to have at least couple of user-reported issues addressed along the way but I definitely have no time for it now, So if the collection can be easily organized in the next few months then I'd prefer to wait till then, but if not doing this release now would mean the collection will happen in one year time then I guess we should go for it. Thoughts ? Here's a summary of the fixes: * Fixed exports from Single Bundle Distro * Fixed deadlock * Fixed cleanup * Fixed ExportReferenceImpl.equals() and hashCode() * Fixed RemoteServiceAdminCore.exportService() As these issues are all exposed by the OSGi TCK I didn't write any additional tests for them in the CXF-DOSGi codebase. As an aside. Note that it is possible for Apache committers to run the OSGi TCK. If anyone is interested let me know and I'll dig up the details. Is that info in the public domain ? If yes then may be you can add this info to the DOSGi wiki ? It is documented for Felix and Equinox projects that implement other OSGi specs, but I'll take an action item to document this on the DOSGi wiki as well. Sounds good, thanks Sergey Cheers, David -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: svn commit: r1302802 - in /cxf/branches/2.5.x-fixes: rt/bindings/http/ rt/databinding/aegis/ rt/databinding/xmlbeans/ rt/frontend/jaxrs/ rt/javascript/javascript-tests/ rt/transports/http/ systest
I'm concerned about this commit. This could potentially remove jars from
peoples classpaths which can easily cause breakages. As an example, with
this change the wsdl_first example doesn't even compile anymore. I'm
definitely OK with the idea on trunk (think it's already done there), but
definitely have concerns about it on the fixes branches. Especially on
2.4.x where spring is a bit more heavily used internally. The fact that
some of our own samples break shows it could have impact on users.
Dan
On Tuesday, March 20, 2012 10:12:12 AM ff...@apache.org wrote:
> Author: ffang
> Date: Tue Mar 20 09:08:19 2012
> New Revision: 1302802
>
> URL: http://svn.apache.org/viewvc?rev=1302802&view=rev
> Log:
> rt-transports-http module should optionally depend on spring
>
> Modified:
> cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml
> cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml
> cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
> cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml
> cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml
> cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml
> cxf/branches/2.5.x-fixes/systests/databinding/pom.xml
> cxf/branches/2.5.x-fixes/systests/jaxrs/pom.xml
> cxf/branches/2.5.x-fixes/systests/rs-security/pom.xml
> cxf/branches/2.5.x-fixes/systests/ws-security-examples/pom.xml
> cxf/branches/2.5.x-fixes/systests/ws-security/pom.xml
> cxf/branches/2.5.x-fixes/tools/javato/ws/pom.xml
>
> Modified: cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml
> URL:
> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/bindings/http/po
> m.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
> =
> = --- cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml (original) +++
> cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml Tue Mar 20 09:08:19
> 2012 @@ -87,6 +87,11 @@
> slf4j-jdk14
> test
>
> +
> +org.springframework
> +spring-context
> +test
> +
>
>
>
>
> Modified: cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml
> URL:
> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/databinding/aegi
> s/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
> =
> = --- cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml (original)
> +++ cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml Tue Mar 20
> 09:08:19 2012 @@ -62,6 +62,11 @@
> test
>
>
> +org.springframework
> +spring-context
> +test
> +
> +
> org.apache.cxf
> cxf-rt-transports-http-jetty
> ${project.version}
>
> Modified: cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
> URL:
> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/databinding/xmlb
> eans/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
> =
> = --- cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
> (original) +++ cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml
> Tue Mar 20 09:08:19 2012 @@ -102,6 +102,11 @@
> ${project.version}
> test
>
> +
> +org.springframework
> +spring-context
> +test
> +
>
>
>
>
> Modified: cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml
> URL:
> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/p
> om.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
> =
> = --- cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml (original)
> +++ cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml Tue Mar 20
> 09:08:19 2012 @@ -182,6 +182,10 @@
> easymock
> test
>
> +
> +org.springframework
> +spring-context
> +
>
>
>
>
> Modified: cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml
> URL:
> http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/javascript/javas
> cript-tests/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff
> =
> = --- cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml
> (original) +++
> cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml Tue Mar
> 20 09:08:19 2012 @@ -67,6 +67,11 @@
> test
>
>
> +org.springframework
> +spring-context
> +test
> +
> +
> xerces
> xercesImpl
> test
>
> Modified: cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml
> URL:
Re: Issue in Virgo Deployment
Hi,
It looks some thing wrong on the server side which your client want to
access.
Caused by: java.io.IOException: The https URL hostname does not match
the
Common Name (CN) on the server certificate. To disable this check (NOT
recommended for production) set the CXF client TLS configuration
property
"disableCNCheck" to true.
Can you check if the server certificate Common Name is march to the
Host Name ?
On Tue Mar 20 14:41:31 2012, rajesh babu wrote:
Hi All,
I have application that will act as webservices client and i need to
submit to request to my server which is having an "https" endpoint, my
http-conduit looks like ,
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:sec="http://cxf.apache.org/configuration/security";
xmlns:http="http://cxf.apache.org/transports/http/configuration";
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";
xmlns:ctx="http://www.springframework.org/schema/context";
xmlns:camel="http://camel.apache.org/schema/spring";
xmlns:camel-cxf="http://camel.apache.org/schema/cxf";
xmlns:http-conf="http://cxf.apache.org/transports/http/configuration";
xsi:schemaLocation="
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://camel.apache.org/schema/osgi
http://camel.apache.org/schema/osgi/camel-osgi.xsd
http://camel.apache.org/schema/cxf
http://camel.apache.org/schema/cxf/camel-cxf.xsd
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd";>
.*_EXPORT_.*
.*_EXPORT1024_.*
.*_WITH_DES_.*
NULL-SHA
.*_WITH_NULL_.*
.*_RSA_.*
.*_NULL-SHA_.*
.*_DH_anon_.*
But when i am trying to send a request i get the following error,
2012-03-19 23:34:09.043] INFO l Thread 69 - MinaThreadPool System.out
: 15 03 01 00 12 AA
B4 0C 44 D5 99 BE 86 6C 3D 07 Dl=.
[2012-03-19 23:34:09.051] INFO l Thread 69 - MinaThreadPool System.out
0010: 63 1B 8C 71 56 6C
8F c..qVl.
[2012-03-19 23:34:09.052] INFO l Thread 69 - MinaThreadPool System.out
%% Invalidated:
[Session-13, SSL_RSA_WITH_RC4_128_MD5]
[2012-03-19 23:34:09.052] INFO l Thread 69 - MinaThreadPool System.out
Camel Thread 69 -
MinaThreadPool, called close()
[2012-03-19 23:34:09.053] INFO l Thread 69 - MinaThreadPool System.out
Camel Thread 69 -
MinaThreadPool, called closeInternal(true)
[2012-03-19 23:34:09.063] WARN l Thread 69 - MinaThreadPool
org.apache.cxf.phase.PhaseInterceptorChain
Interceptor for
{urn:ihe:iti:xds-b:2007}DocumentRepository_Service#{urn:ihe:iti:xds-b:2007}DocumentRepository_ProvideAndRegisterDocumentSet-b
has thrown exception, unwinding now org.apache.cxf.interceptor.Fault:
Marshalling Error: The https URL hostname does not match the Common Name
(CN) on the server certificate. To disable this check (NOT recommended for
production) set the CXF client TLS configuration property "disableCNCheck"
to true.
at
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:252)
at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
at
org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:111)
at
org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at $Proxy199.documentRepositoryProvideAndRegisterDocumentSetB(Unknown
Source)
at
org.openehealth.ipf.platform.camel.ihe.xds.iti41.component.Iti41Producer.callService(Iti41Producer.java:42)
at
org.openehealth.ipf.platform.camel.ihe.xds.iti
Re: svn commit: r1302802 - in /cxf/branches/2.5.x-fixes
On 2012-3-20, at 下午6:19, Sergey Beryozkin wrote: Hi Freeman On 20/03/12 10:12, ff...@apache.org wrote: Author: ffang Date: Tue Mar 20 09:08:19 2012 New Revision: 1302802 URL: http://svn.apache.org/viewvc?rev=1302802&view=rev Log: rt-transports-http module should optionally depend on spring Modified: cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml cxf/branches/2.5.x-fixes/systests/databinding/pom.xml cxf/branches/2.5.x-fixes/systests/jaxrs/pom.xml cxf/branches/2.5.x-fixes/systests/rs-security/pom.xml cxf/branches/2.5.x-fixes/systests/ws-security-examples/pom.xml cxf/branches/2.5.x-fixes/systests/ws-security/pom.xml cxf/branches/2.5.x-fixes/tools/javato/ws/pom.xml Modified: cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml URL: http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff = = = = = = = = = = --- cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml (original) +++ cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml Tue Mar 20 09:08:19 2012 @@ -182,6 +182,10 @@ easymock test + +org.springframework +spring-context + Did you mean to add a 'test' scope here like in all the other modules ? Cheers, Sergey Hi Sergey, No, because the main code in jaxrs also depend on spring, there's already a spring-core dependency. But I think the spring dependency should be optional there also, just like other modules, wdyt? Best Regards Freeman - Freeman Fang FuseSource Email:ff...@fusesource.com Web: fusesource.com Twitter: freemanfang Blog: http://freemanfang.blogspot.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi Sergey, On 20 March 2012 09:47, Sergey Beryozkin wrote: > Hi David > > On 20/03/12 08:00, David Bosschaert wrote: >> >> I just got confirmation that the current trunk of the CXF-DOSGi passes >> the TCK again. > > Great news, thanks for the support from your side, > >> It would be *really* good if we could release this >> version so that the Remote Services and RSA RI in the OSGi systems is >> a released version of CXF-DOSGi rather than a snapshot. Sergey, could >> I maybe ask you to do a release again? > > I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs > have been opened against 1.3 so I'll try to address some of them too before > cutting a new release. The TCK compliance work I did was part of the OSGi 4.3 Compendium cycle and I expect that the RIs for that (of which CXF-DOSGi is part) will be collected soon - within 2 weeks is my guess, but I can get a more detailed deadline if needed. If we want a released version of CXF-DOSGi to be part of that RI, we need to have that release before then. Otherwise they'll take the current version which is based on a 1.4 snapshot... Would there be an issue with just releasing what's there now (read: really soon) and maybe do a 1.3.2 in June/July? I've never done an Apache release so I'm not really sure how much work is involved, but if it's just a matter of a few commands, I think it would be worth it doing it now - but obviously that all depends on time people have available too... >> Here's a summary of the fixes: >> * Fixed exports from Single Bundle Distro >> * Fixed deadlock >> * Fixed cleanup >> * Fixed ExportReferenceImpl.equals() and hashCode() >> * Fixed RemoteServiceAdminCore.exportService() >> >> As these issues are all exposed by the OSGi TCK I didn't write any >> additional tests for them in the CXF-DOSGi codebase. >> As an aside. Note that it is possible for Apache committers to run the >> OSGi TCK. If anyone is interested let me know and I'll dig up the >> details. > > Is that info in the public domain ? If yes then may be you can add this info > to the DOSGi wiki ? It is documented for Felix and Equinox projects that implement other OSGi specs, but I'll take an action item to document this on the DOSGi wiki as well. Cheers, David
Re: svn commit: r1302802 - in /cxf/branches/2.5.x-fixes
Hi Freeman On 20/03/12 10:12, ff...@apache.org wrote: Author: ffang Date: Tue Mar 20 09:08:19 2012 New Revision: 1302802 URL: http://svn.apache.org/viewvc?rev=1302802&view=rev Log: rt-transports-http module should optionally depend on spring Modified: cxf/branches/2.5.x-fixes/rt/bindings/http/pom.xml cxf/branches/2.5.x-fixes/rt/databinding/aegis/pom.xml cxf/branches/2.5.x-fixes/rt/databinding/xmlbeans/pom.xml cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml cxf/branches/2.5.x-fixes/rt/javascript/javascript-tests/pom.xml cxf/branches/2.5.x-fixes/rt/transports/http/pom.xml cxf/branches/2.5.x-fixes/systests/databinding/pom.xml cxf/branches/2.5.x-fixes/systests/jaxrs/pom.xml cxf/branches/2.5.x-fixes/systests/rs-security/pom.xml cxf/branches/2.5.x-fixes/systests/ws-security-examples/pom.xml cxf/branches/2.5.x-fixes/systests/ws-security/pom.xml cxf/branches/2.5.x-fixes/tools/javato/ws/pom.xml Modified: cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml URL: http://svn.apache.org/viewvc/cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml?rev=1302802&r1=1302801&r2=1302802&view=diff == --- cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml (original) +++ cxf/branches/2.5.x-fixes/rt/frontend/jaxrs/pom.xml Tue Mar 20 09:08:19 2012 @@ -182,6 +182,10 @@ easymock test + +org.springframework +spring-context + Did you mean to add a 'test' scope here like in all the other modules ? Cheers, Sergey
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi David On 20/03/12 08:00, David Bosschaert wrote: I just got confirmation that the current trunk of the CXF-DOSGi passes the TCK again. Great news, thanks for the support from your side, It would be *really* good if we could release this version so that the Remote Services and RSA RI in the OSGi systems is a released version of CXF-DOSGi rather than a snapshot. Sergey, could I maybe ask you to do a release again? I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs have been opened against 1.3 so I'll try to address some of them too before cutting a new release. Here's a summary of the fixes: * Fixed exports from Single Bundle Distro * Fixed deadlock * Fixed cleanup * Fixed ExportReferenceImpl.equals() and hashCode() * Fixed RemoteServiceAdminCore.exportService() As these issues are all exposed by the OSGi TCK I didn't write any additional tests for them in the CXF-DOSGi codebase. As an aside. Note that it is possible for Apache committers to run the OSGi TCK. If anyone is interested let me know and I'll dig up the details. Is that info in the public domain ? If yes then may be you can add this info to the DOSGi wiki ? Thanks, Sergey Cheers, David On 13 March 2012 07:30, David Bosschaert wrote: Just a little update on this. I made some more changes and at this point in time we're getting close. For me the OSGi Remote Services and Remote Service Admin TCKs are 100% passing but other people did report a failure that we have to investigate a little further. I'll chime in again when everything is good, as we could do a release at that point. Cheers, David On 20 February 2012 22:38, Sergey Beryozkin wrote: Hi David On 19/02/12 00:42, David Bosschaert wrote: Hi all, I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK to make sure it's still compliant with the spec. It turned out that the changes made between 1.2 and 1.3 cause a number of TCK failures, so I've been looking at fixing them. Here's a quick summary. * the single-bundle distro (which is used with the TCK) now includes the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't export/import the types defined in there which meant that these types existed twice in the VM, once inside the single bundle distro and once outside. This caused issues with ConfigAdmin and some event types since communication with the outside world wasn't possible with these types any more. I fixed this for the single-bundle distro (it doesn't apply to the multi-bundle distro). * ExportReferenceImpl, which is really a wrapper, was used in a Map but missing hashCode and equals(). I added these. * There were some issues around close() calls not completely properly behaving, I fixed those * RemoteServiceAdminCore was putting objects of the wrong type in the collection returned by exportService() Some more changes may be needed in order to fully pass the TCK, but I've committed the above in r1290914. Cool, guess you are thinking about 1.3.1 already :-) Cheers, Sergey Cheers, David -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
I just got confirmation that the current trunk of the CXF-DOSGi passes the TCK again. It would be *really* good if we could release this version so that the Remote Services and RSA RI in the OSGi systems is a released version of CXF-DOSGi rather than a snapshot. Sergey, could I maybe ask you to do a release again? Here's a summary of the fixes: * Fixed exports from Single Bundle Distro * Fixed deadlock * Fixed cleanup * Fixed ExportReferenceImpl.equals() and hashCode() * Fixed RemoteServiceAdminCore.exportService() As these issues are all exposed by the OSGi TCK I didn't write any additional tests for them in the CXF-DOSGi codebase. As an aside. Note that it is possible for Apache committers to run the OSGi TCK. If anyone is interested let me know and I'll dig up the details. Cheers, David On 13 March 2012 07:30, David Bosschaert wrote: > Just a little update on this. > I made some more changes and at this point in time we're getting > close. For me the OSGi Remote Services and Remote Service Admin TCKs > are 100% passing but other people did report a failure that we have to > investigate a little further. > > I'll chime in again when everything is good, as we could do a release > at that point. > > Cheers, > > David > > On 20 February 2012 22:38, Sergey Beryozkin wrote: >> Hi David >> >> On 19/02/12 00:42, David Bosschaert wrote: >>> >>> Hi all, >>> >>> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK >>> to make sure it's still compliant with the spec. >>> It turned out that the changes made between 1.2 and 1.3 cause a number >>> of TCK failures, so I've been looking at fixing them. >>> Here's a quick summary. >>> * the single-bundle distro (which is used with the TCK) now includes >>> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't >>> export/import the types defined in there which meant that these types >>> existed twice in the VM, once inside the single bundle distro and once >>> outside. This caused issues with ConfigAdmin and some event types >>> since communication with the outside world wasn't possible with these >>> types any more. >>> I fixed this for the single-bundle distro (it doesn't apply to the >>> multi-bundle distro). >>> * ExportReferenceImpl, which is really a wrapper, was used in a Map >>> but missing hashCode and equals(). I added these. >>> * There were some issues around close() calls not completely properly >>> behaving, I fixed those >>> * RemoteServiceAdminCore was putting objects of the wrong type in the >>> collection returned by exportService() >>> >>> Some more changes may be needed in order to fully pass the TCK, but >>> I've committed the above in r1290914. >>> >> Cool, guess you are thinking about 1.3.1 already :-) >> Cheers, Sergey >> >>> Cheers, >>> >>> David >> >>
