Mailing-List: contact commits-help@tomee.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tomee.apache.org
Date: Fri, 18 Dec 2015 14:22:46 +0000 (UTC)
From: "Romain Manni-Bucau (JIRA)" <jira@apache.org>
To: commits@openejb.apache.org
Message-ID: <JIRA.12923024.1450448158000.67203.1450448566627@Atlassian.JIRA>
In-Reply-To: <JIRA.12923024.1450448158000@Atlassian.JIRA>
References: <JIRA.12923024.1450448158000@Atlassian.JIRA>
 <JIRA.12923024.1450448158549@arcas>
Subject: [jira] [Commented] (TOMEE-1681) Upgrade '<cxf.version>' property in
 openejb.pom
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/TOMEE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15063987#comment-15063987 ] 

Romain Manni-Bucau commented on TOMEE-1681:
-------------------------------------------

Hi Martin,

seems it is not the case on master so can be a merge issue in M1 branch.

> Upgrade '<cxf.version>' property in openejb.pom
> -----------------------------------------------
>
>                 Key: TOMEE-1681
>                 URL: https://issues.apache.org/jira/browse/TOMEE-1681
>             Project: TomEE
>          Issue Type: Bug
>          Components: TomEE Core Server
>    Affects Versions: 7.0.0-M1
>         Environment: MacOS 10.11.2, Linux (Ubuntu 14.04LTS) - Maven 3.2.5 and 3.3.9, JUnit 4.12 in RS-based webservice test setup with "WebClient" to simulate client access.
>            Reporter: Martin Wiesner
>            Priority: Critical
>              Labels: cxf, cxf-rs, maven, pom
>             Fix For: 7.0.0-M2
>
>
> According to the latest artifact   
>   <groupId>org.apache.tomee</groupId>
>   <artifactId>openejb</artifactId>
> in 7.0.0-M1, the version of CXF is defined as <cxf.version>3.1.0</cxf.version>.
> This, however, conflicts with the bundled CXF version of the released TomEE 7.0.0-M1 bundles (tar.gz/zip) as provided on TomEE's project website. In the provided archives we find CXF artifacts in version 3.1.3 (which is what we would consider correct).
> This inconsistency brings in some trouble with other/related artifacts as well. If one tries to manage this dependency actively in its own project from 3.1.0 to 3.1.3 several runtime incompatibilities are observed as follows:
> java.lang.IllegalStateException: java.lang.NoSuchMethodException: org.apache.cxf.jaxrs.client.ClientProviderFactory.<init>(org.apache.cxf.jaxrs.provider.ProviderFactory, org.apache.cxf.Bus)
> 	at org.apache.openejb.server.cxf.rs.CxfRSService.initCxfClientBuilderProviders(CxfRSService.java:254)
> 	at org.apache.openejb.server.cxf.rs.CxfRSService.init(CxfRSService.java:193)
> 	at org.apache.openejb.server.ServiceManager.initServer(ServiceManager.java:165)
> 	at org.apache.openejb.server.ServiceManager.initServers(ServiceManager.java:90)
> 	at org.apache.openejb.server.SimpleServiceManager.init(SimpleServiceManager.java:149)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.apache.openejb.util.ServiceManagerProxy.invoke(ServiceManagerProxy.java:83)
> 	at org.apache.openejb.util.ServiceManagerProxy.<init>(ServiceManagerProxy.java:69)
> 	at org.apache.openejb.util.ServiceManagerProxy.<init>(ServiceManagerProxy.java:43)
> 	at org.apache.openejb.OpenEjbContainer.startNetworkServices(OpenEjbContainer.java:204)
> 	at org.apache.openejb.OpenEjbContainer.<init>(OpenEjbContainer.java:133)
> 	at org.apache.openejb.OpenEjbContainer.<init>(OpenEjbContainer.java:90)
> 	at org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:346)
> 	at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:56)
> 	at org.apache.openejb.junit.jee.statement.StartingStatement.before(StartingStatement.java:96)
> 	at org.apache.openejb.junit.jee.statement.DecoratingStatement.evaluate(DecoratingStatement.java:30)
> 	at org.apache.openejb.junit.jee.statement.DecoratingStatement.evaluate(DecoratingStatement.java:32)
> 	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> 	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> 	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: java.lang.NoSuchMethodException: org.apache.cxf.jaxrs.client.ClientProviderFactory.<init>(org.apache.cxf.jaxrs.provider.ProviderFactory, org.apache.cxf.Bus)
> 	at java.lang.Class.getConstructor0(Class.java:3082)
> 	at java.lang.Class.getDeclaredConstructor(Class.java:2178)
> 	at org.apache.openejb.server.cxf.rs.CxfRSService.initCxfClientBuilderProviders(CxfRSService.java:204)
> This result from a change in a constructor which is no longer existent in CXF 3.1.3, but was present in 3.1.0 and 3.1.1. Sadly, it is quite hard to get our JUnit test running (simulate JAX-RS client via "WebClient" class). It blocks and fails, as the server part can not bind the JAX-RS http server component correctly.
> Any ideas?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)