[JBoss JIRA] (WFLY-7816) Camel CXF version not compatible with WildFly CXF
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-7816?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-7816:
-------------------------------
Fix Version/s: 11.0.0.CR1
(was: 11.0.0.Beta1)
> Camel CXF version not compatible with WildFly CXF
> -------------------------------------------------
>
> Key: WFLY-7816
> URL: https://issues.jboss.org/browse/WFLY-7816
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Web Services
> Affects Versions: 10.1.0.Final
> Reporter: Thomas Diesler
> Assignee: Alessio Soldano
> Fix For: 10.2.0.Final, 11.0.0.CR1
>
>
> cxf-3.1.9 distributed with camel-2.19.x is not compatible with cxf-3.1.6 from wildfly-10.1.0.Final
> {code}
> Caused by: java.lang.NoSuchMethodError: org.apache.cxf.message.Message.remove(Ljava/lang/Class;)Ljava/lang/Object;
> at org.apache.camel.component.cxf.CxfEndpoint$CamelCxfClientImpl.setParameters(CxfEndpoint.java:1239)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:470)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:416)
> at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:133)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1546
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7537) Review NamingContext.check() method
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-7537?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-7537:
-------------------------------
Fix Version/s: 11.0.0.CR1
(was: 11.0.0.Beta1)
> Review NamingContext.check() method
> -----------------------------------
>
> Key: WFLY-7537
> URL: https://issues.jboss.org/browse/WFLY-7537
> Project: WildFly
> Issue Type: Task
> Components: Naming
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 11.0.0.CR1
>
>
> The new naming client is sending in a SimpleName where the lookup was performed using a String.
> When a SecurityManager is installed the check() method of NamingContext is called and results in the following error: -
> {noformat}
> javax.naming.InvalidNameException: Not a composite name: jms
> at javax.naming.CompositeName.addAll(CompositeName.java:472)
> at org.jboss.as.naming.NamingContext.check(NamingContext.java:592)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:197)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:127)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> A fix has been applied to convert the incoming name to a CompositeName but as we deliberately have a SimpleName to avoid CompositeName I wonder if that is completely correct.
> Some other options I think of: -
> 1. Stick with current fix.
> 2 The client should convert to CompositeName before sending.
> 3. Manually iterate the segments if not a CompositeName
> 4. Check if the NamingStore really needs to use a CompositeName
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months