[jira] [Commented] (CXF-5193) Support fixed data type
[
https://issues.apache.org/jira/browse/CXF-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199430#comment-15199430
]
Grzegorz Grzybek commented on CXF-5193:
---
[~weberjn], [~dkulp], I checked with 3.1.5 and got:
{noformat}
$ idl2wsdl fixed.idl
$ wsdlvalidator fixed.wsdl
WSIBP Validator found
<{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
is NOT a SOAP binding
WSDLValidator Error : org.xml.sax.SAXParseException; schema_reference: Failed
to read schema document 'xml.xsd', because 'file' access is not allowed due to
restriction set by the accessExternalSchema property.
{noformat}
[~weberjn], you can always use:
{code:java}
module fixeds
{
typedef fixed<5,2> f;
struct FixedStruct
{
f oddFixed; // 123.67
};
interface FunctionTest
{
FixedStruct testFixeds(in FixedStruct aFixedStruct);
};
};
{code}
But I have a fix for anonymous fixed types:
https://github.com/apache/cxf/pull/123
> Support fixed data type
> ---
>
> Key: CXF-5193
> URL: https://issues.apache.org/jira/browse/CXF-5193
> Project: CXF
> Issue Type: Improvement
> Components: CORBA Binding
>Affects Versions: 2.7.6
>Reporter: Jürgen Weber
> Attachments: fixed.idl
>
>
> Looks like the data type fixed is not supported:
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/idl2wsdl fixed.idl
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/wsdlvalidator
> fixed.wsdl
> WSIBP Validator found
> <{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
> is NOT a SOAP binding
> WSDLValidator Error :
> line 15 column 48 of file:/projekte/temp/idl/functiontest/fixed.wsdl:
> Duplicate key value [fixeds.FixedStruct] declared for identity constraint of
> element "schema".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6795) WS-Discovery add support for discovery on localhost
[ https://issues.apache.org/jira/browse/CXF-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197434#comment-15197434 ] ASF GitHub Bot commented on CXF-6795: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/113 > WS-Discovery add support for discovery on localhost > --- > > Key: CXF-6795 > URL: https://issues.apache.org/jira/browse/CXF-6795 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.5 >Reporter: Nick Birnie > > The current WS-Discovery implementation could use support for discovering > services which are provided on localhost. This is currently not the case due > to an obscure detail of multicast communications where, when a multicast > packet is sent, by default it is not echoed back to the host that sent it. > For more info, see: http://www.tldp.org/HOWTO/Multicast-HOWTO-6.html > This should be an easy fix by setting the appropriate options on the > MulticastSocket used by WSDiscoveryClient (which I believe is implemented by > UDPConduit in UDPTransport). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6832) Attachment content-disposition modification-date not parsed correctly
[
https://issues.apache.org/jira/browse/CXF-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-6832:
--
Assignee: Sergey Beryozkin
Fix Version/s: 3.0.9
3.1.6
3.2.0
Component/s: Core
> Attachment content-disposition modification-date not parsed correctly
> -
>
> Key: CXF-6832
> URL: https://issues.apache.org/jira/browse/CXF-6832
> Project: CXF
> Issue Type: Bug
> Components: Core
>Reporter: Nicolas Daniels
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.6, 3.0.9
>
>
> When deserializing multipart content as
> org.apache.cxf.jaxrs.ext.multipart.Attachment, the
> org.apache.cxf.attachment.ContentDisposition data are not correctly filled
> in. Those valid fields are not set:
> * creation-date date when content was created [RFC2183]
> * modification-date date when content was last modified [RFC2183]
> * read-date date when content was last read [RFC2183]
> Exemple of Rest WebService declaration:
> public void put(@PathParam("path") String path,
> @Multipart(value = "file", required = false) Attachment
> attachment) throws IOException {
>
> System.out.println(attachment.getContentDisposition().getParameter("modification-date"));
> --> always null
> }
> Actually, the REGEXP pattern used in
> ContentDisposition.CD_HEADER_PARAMS_PATTERN is not correct as it doesn't
> include '-' character. So the key is not 'modification-date' but rather
> 'date' in the map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6835) Deadlock in WS-Discovery when service called during startup
Nick Birnie created CXF-6835: Summary: Deadlock in WS-Discovery when service called during startup Key: CXF-6835 URL: https://issues.apache.org/jira/browse/CXF-6835 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 3.1.4 Reporter: Nick Birnie When starting up a service with WS-Discovery, there is a deadlock which can occur if the service is invoked from outside. Please see attached stacktraces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-5193) Support fixed data type
[
https://issues.apache.org/jira/browse/CXF-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15201652#comment-15201652
]
ASF GitHub Bot commented on CXF-5193:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/123
> Support fixed data type
> ---
>
> Key: CXF-5193
> URL: https://issues.apache.org/jira/browse/CXF-5193
> Project: CXF
> Issue Type: Improvement
> Components: CORBA Binding
>Affects Versions: 2.7.6
>Reporter: Jürgen Weber
> Attachments: fixed.idl
>
>
> Looks like the data type fixed is not supported:
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/idl2wsdl fixed.idl
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/wsdlvalidator
> fixed.wsdl
> WSIBP Validator found
> <{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
> is NOT a SOAP binding
> WSDLValidator Error :
> line 15 column 48 of file:/projekte/temp/idl/functiontest/fixed.wsdl:
> Duplicate key value [fixeds.FixedStruct] declared for identity constraint of
> element "schema".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6764) Should add RI JAXB Namespacemapper support
[
https://issues.apache.org/jira/browse/CXF-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-6764.
--
Resolution: Fixed
Assignee: Daniel Kulp
Fix Version/s: 3.0.9
3.1.6
> Should add RI JAXB Namespacemapper support
> --
>
> Key: CXF-6764
> URL: https://issues.apache.org/jira/browse/CXF-6764
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
>Assignee: Daniel Kulp
> Fix For: 3.1.6, 3.0.9
>
>
> /cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
> {code:java}
> if (cls == null
> && (mcls.getName().contains(".internal.") ||
> mcls.getName().contains("com.sun"))) {
> try {
> cls =
> ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper",
> JAXBUtils.class);
> } catch (ClassNotFoundException ex2) {
> // ignore
> }
> }
> {code}
> CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends
> com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a
> mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
> So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB
> cann't add the namespace mapping correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-5193) Support fixed data type
[
https://issues.apache.org/jira/browse/CXF-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-5193:
-
Fix Version/s: 3.1.7
3.0.9
3.1.6
> Support fixed data type
> ---
>
> Key: CXF-5193
> URL: https://issues.apache.org/jira/browse/CXF-5193
> Project: CXF
> Issue Type: Improvement
> Components: CORBA Binding
>Affects Versions: 2.7.6
>Reporter: Jürgen Weber
> Fix For: 3.1.6, 3.0.9, 3.1.7
>
> Attachments: fixed.idl
>
>
> Looks like the data type fixed is not supported:
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/idl2wsdl fixed.idl
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/wsdlvalidator
> fixed.wsdl
> WSIBP Validator found
> <{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
> is NOT a SOAP binding
> WSDLValidator Error :
> line 15 column 48 of file:/projekte/temp/idl/functiontest/fixed.wsdl:
> Duplicate key value [fixeds.FixedStruct] declared for identity constraint of
> element "schema".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6832) Attachment content-disposition modification-date not parsed correctly
[
https://issues.apache.org/jira/browse/CXF-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6832.
---
Resolution: Fixed
Thanks
> Attachment content-disposition modification-date not parsed correctly
> -
>
> Key: CXF-6832
> URL: https://issues.apache.org/jira/browse/CXF-6832
> Project: CXF
> Issue Type: Bug
> Components: Core
>Reporter: Nicolas Daniels
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.6, 3.0.9
>
>
> When deserializing multipart content as
> org.apache.cxf.jaxrs.ext.multipart.Attachment, the
> org.apache.cxf.attachment.ContentDisposition data are not correctly filled
> in. Those valid fields are not set:
> * creation-date date when content was created [RFC2183]
> * modification-date date when content was last modified [RFC2183]
> * read-date date when content was last read [RFC2183]
> Exemple of Rest WebService declaration:
> public void put(@PathParam("path") String path,
> @Multipart(value = "file", required = false) Attachment
> attachment) throws IOException {
>
> System.out.println(attachment.getContentDisposition().getParameter("modification-date"));
> --> always null
> }
> Actually, the REGEXP pattern used in
> ContentDisposition.CD_HEADER_PARAMS_PATTERN is not correct as it doesn't
> include '-' character. So the key is not 'modification-date' but rather
> 'date' in the map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6834) add support for CXF inside Spring Boot
[ https://issues.apache.org/jira/browse/CXF-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197238#comment-15197238 ] Sergey Beryozkin edited comment on CXF-6834 at 3/16/16 12:09 PM: - Thanks for the links, I'll investigate as we have a lot of related queries indeed. Can you have a look at this demo: https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot it has 3 SpringBoot resource variations (with/without auto-discovery): https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot/src/main/java/sample/rs/service and this one is currently being used: https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot/src/main/java/sample/rs/service/SampleScanRestApplication.java It loads Hello1 and Hello2 JAX-RS resources and enables a Swagger feature - I could've enabled via a CXF Features annotation directly on the resource class but with two resources it is simpler to return it from a Bean method. I'm going to spend more time asap on this issue to get a better CXF-SpintBoot integration done anyway. If you have any comments on the CXF demo - let me know please was (Author: sergey_beryozkin): Thanks for the links, I'll investigate as we have a lot of related queries indeed. Can you have a look at this demo: https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot it has 3 SpringBot resource variations (with/without auto-discovery): https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot/src/main/java/sample/rs/service and this one is currently being used: https://github.com/apache/cxf/blob/master/distribution/src/main/release/samples/jax_rs/jaxrs_spring_boot/src/main/java/sample/rs/service/SampleScanRestApplication.java It loads Hello1 and Hello2 JAX-RS resources and enables a Swagger feature - I could've enabled via a CXF Features annotation directly on the resource class but with two resources it is simpler to return it from a Bean method. I'm going to spend more time asap on this issue to get a better CXF-SpintBoot integration done anyway. If you have any comments on the CXF demo - let me know please > add support for CXF inside Spring Boot > -- > > Key: CXF-6834 > URL: https://issues.apache.org/jira/browse/CXF-6834 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: james strachan >Assignee: Sergey Beryozkin > Fix For: 3.2.0 > > > right now spring boot has support for Jersey; it'd be great to integrate > support for CXF too. > e.g. > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters/spring-boot-starter-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey1 > mostly this is about submitting a PR against the spring-boot project; but it > may require a few changes in CXF to be more spring/spring-boot ready or to > work better with Spring Boot's auto configuration mechanism and tooling: > * > https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html > * > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html > Docs on creating auto configuration here: > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6834) add support for CXF inside Spring Boot
[ https://issues.apache.org/jira/browse/CXF-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197280#comment-15197280 ] Sergey Beryozkin commented on CXF-6834: --- SampleScanRestApplication2 shows how Application with its @ApplicationPath can help with not setting the specific path with CXFServlet, but that looks heavy-weight indeed. Hopefully we can make it all look better after doing a bit more of the integration work. Not sure yet how to handle the client enhancement, but hopefully it can be done easily enough... > add support for CXF inside Spring Boot > -- > > Key: CXF-6834 > URL: https://issues.apache.org/jira/browse/CXF-6834 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: james strachan >Assignee: Sergey Beryozkin > Fix For: 3.2.0 > > > right now spring boot has support for Jersey; it'd be great to integrate > support for CXF too. > e.g. > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters/spring-boot-starter-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey > * > https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples/spring-boot-sample-jersey1 > mostly this is about submitting a PR against the spring-boot project; but it > may require a few changes in CXF to be more spring/spring-boot ready or to > work better with Spring Boot's auto configuration mechanism and tooling: > * > https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html > * > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html > Docs on creating auto configuration here: > https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6835) Deadlock in WS-Discovery when service called during startup
[ https://issues.apache.org/jira/browse/CXF-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Birnie updated CXF-6835: - Description: When starting up a service with WS-Discovery, there is a deadlock which can occur if the service is invoked from outside before the WS-Discovery registration has completed. Please see attached stacktraces. In order to reproduce, create a spring project and run with new ClasspathXmlApplicationContext(...). Configure this to provide a jaxws service. Then you'll need a client to simply poll this service repeatedly. Start the client first, then the server. In my experience you'll find the deadlock on the server side most of the time. was:When starting up a service with WS-Discovery, there is a deadlock which can occur if the service is invoked from outside. Please see attached stacktraces. > Deadlock in WS-Discovery when service called during startup > --- > > Key: CXF-6835 > URL: https://issues.apache.org/jira/browse/CXF-6835 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.4 >Reporter: Nick Birnie > > When starting up a service with WS-Discovery, there is a deadlock which can > occur if the service is invoked from outside before the WS-Discovery > registration has completed. Please see attached stacktraces. > In order to reproduce, create a spring project and run with new > ClasspathXmlApplicationContext(...). Configure this to provide a jaxws > service. Then you'll need a client to simply poll this service repeatedly. > Start the client first, then the server. In my experience you'll find the > deadlock on the server side most of the time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6835) Deadlock in WS-Discovery when service called during startup
[ https://issues.apache.org/jira/browse/CXF-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199849#comment-15199849 ] Nick Birnie commented on CXF-6835: -- Found one Java-level deadlock: = "qtp1963056288-209 - /neptune/v2/monitor": waiting to lock monitor 0x0d719168 (object 0xf0958480, a java.util.concurrent.ConcurrentHashMap), which is held by "main" "main": waiting to lock monitor 0x0bc9b748 (object 0xf1b7d728, a org.apache.cxf.ws.policy.PolicyEngineImpl), which is held by "qtp1963056288-209 - /neptune/v2/monitor" Java stack information for the threads listed above: === "qtp1963056288-209 - /neptune/v2/monitor": at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:188) - waiting to lock <0xf0958480> (a java.util.concurrent.ConcurrentHashMap) at org.springframework.beans.factory.support.AbstractBeanFactory.isSingleton(AbstractBeanFactory.java:399) at org.springframework.beans.factory.support.DefaultListableBeanFactory.doGetBeanNamesForType(DefaultListableBeanFactory.java:447) at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanNamesForType(DefaultListableBeanFactory.java:415) at org.springframework.context.support.AbstractApplicationContext.getBeanNamesForType(AbstractApplicationContext.java:1156) at org.apache.cxf.bus.spring.SpringBeanLocator.getBeansOfType(SpringBeanLocator.java:145) at org.apache.cxf.ws.policy.PolicyEngineImpl.getPolicyProviders(PolicyEngineImpl.java:141) - locked <0xf1b7d728> (a org.apache.cxf.ws.policy.PolicyEngineImpl) at org.apache.cxf.ws.policy.PolicyEngineImpl.getAggregatedServicePolicy(PolicyEngineImpl.java:437) at org.apache.cxf.ws.policy.EndpointPolicyImpl.initializePolicy(EndpointPolicyImpl.java:151) at org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:140) at org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineImpl.java:584) at org.apache.cxf.ws.policy.PolicyEngineImpl.getEndpointPolicy(PolicyEngineImpl.java:313) - locked <0xf28c29c8> (a org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo) at org.apache.cxf.ws.policy.PolicyEngineImpl.getServerEndpointPolicy(PolicyEngineImpl.java:299) at org.apache.cxf.ws.policy.PolicyDataEngineImpl.getServerEndpointPolicy(PolicyDataEngineImpl.java:84) at org.apache.cxf.transport.http.AbstractHTTPDestination.calcServerPolicyInternal(AbstractHTTPDestination.java:532) - locked <0xf2769530> (a org.apache.cxf.transport.http_jetty.JettyHTTPDestination) at org.apache.cxf.transport.http.AbstractHTTPDestination.calcServerPolicy(AbstractHTTPDestination.java:546) at org.apache.cxf.transport.http.AbstractHTTPDestination.getServer(AbstractHTTPDestination.java:912) at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:219) at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1065) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) "main": at org.apache.cxf.ws.policy.PolicyEngineImpl.getPolicyProviders(PolicyEngineImpl.java:136) - waiting to lock <0xf1b7d728> (a org.apache.cxf.ws.policy.PolicyEngineImpl) at org.apache.cxf.ws.policy.PolicyEngineImpl.getAggregatedServicePolicy(PolicyEngineImpl.java:437) at org.apache.cxf.ws.policy.EndpointPolicyImpl.initializePolicy(EndpointPolicyImpl.java:151) at org.apache.cxf.ws.policy.EndpointPolicyImpl.initialize(EndpointPolicyImpl.java:140) at org.apache.cxf.ws.policy.PolicyEngineImpl.createEndpointPolicyInfo(PolicyEngineIm
[jira] [Commented] (CXF-5193) Support fixed data type
[
https://issues.apache.org/jira/browse/CXF-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199429#comment-15199429
]
ASF GitHub Bot commented on CXF-5193:
-
GitHub user grgrzybek opened a pull request:
https://github.com/apache/cxf/pull/123
[CXF-5193] Fix anonymous fixed IDL type handling
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/grgrzybek/cxf CXF-5193
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/123.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #123
commit e0bff66bc8b10a8fc30cdb02a44c6bea90d5915b
Author: Grzegorz Grzybek
Date: 2016-03-17T12:41:25Z
[CXF-5193] Fix anonymous fixed IDL type handling
> Support fixed data type
> ---
>
> Key: CXF-5193
> URL: https://issues.apache.org/jira/browse/CXF-5193
> Project: CXF
> Issue Type: Improvement
> Components: CORBA Binding
>Affects Versions: 2.7.6
>Reporter: Jürgen Weber
> Attachments: fixed.idl
>
>
> Looks like the data type fixed is not supported:
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/idl2wsdl fixed.idl
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/wsdlvalidator
> fixed.wsdl
> WSIBP Validator found
> <{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
> is NOT a SOAP binding
> WSDLValidator Error :
> line 15 column 48 of file:/projekte/temp/idl/functiontest/fixed.wsdl:
> Duplicate key value [fixeds.FixedStruct] declared for identity constraint of
> element "schema".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6833) support RxJava Observable in return values as a more composeable alternative to Future
[
https://issues.apache.org/jira/browse/CXF-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197225#comment-15197225
]
Sergey Beryozkin commented on CXF-6833:
---
Thanks, FYI, this is what was proposed for JAX-RS 2.1:
https://github.com/spericas/api/blob/master/jaxrs-api/src/test/java/javax/ws/rs/core/RxClientTest.java
I haven't looked deeply into it yet due to the 2.1 process being quite slow,
but from what I understood, that API was designed to work the alternative 3rd
party libraries too. I hope we can start reasonably soon (few months time
frame) with the client side first and then move to supporting it as an
extension on the server side. I don't mind starting before the spec produces
something more specific, it is just difficult to allocate a chunk of time for
it right now.
> support RxJava Observable in return values as a more composeable
> alternative to Future
>
>
> Key: CXF-6833
> URL: https://issues.apache.org/jira/browse/CXF-6833
> Project: CXF
> Issue Type: Improvement
>Reporter: james strachan
>
> when invoking multiple REST services concurrently in a microservice kinda
> world it can be really helpful to use RxJava's Observable so that you can
> easily compose concurrent asynchronous requests together.
> e.g. see this blog:
> http://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
> Its basically about using RxJava's Observable as the result type; which is
> a little like a Future but can handle streams of values and is composable.
> It would be great to do this both on the client and server side; as a server
> may invoke multiple asynchronous back ends and return a composition of
> results etc.
> e.g.
> {code}
> @GET("/session.json")
> Observable login();
> @GET("/user.json")
> Observable getUserState();
> {code}
> you can then use the Observable composition methods to join / flatMap to
> compose multiple requests across different microservice invocations together
> with timeouts etc e.g. to compose the latest from 2 calls:
> {code}
> Observable.combineLatest(api.fetchUserProfile(), api.getUserState(),
> (user, userStatus) -> new Pair<>(user, userStatus));
> {code}
> and you're done! There's support for timeouts and other kinds of composition
> mechanisms too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6758) DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
[
https://issues.apache.org/jira/browse/CXF-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-6758.
--
Resolution: Not A Problem
Assignee: Daniel Kulp
Fix Version/s: Invalid
Resolving as the incoming XML is invalid
> DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar
> parse error of severity ValidationEvent.ERROR
> --
>
> Key: CXF-6758
> URL: https://issues.apache.org/jira/browse/CXF-6758
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
> Environment: CXF 3.1.4 integrated into JBoss Wildly 10.0.0.CR5, java
> version 1.8.0_71
>Reporter: Thorsten Möller
>Assignee: Daniel Kulp
> Fix For: Invalid
>
>
> The implementation of
> {{org.apache.cxf.jaxb.io.DataReaderImpl.handleEvent(ValidationEvent event)}}
> is too strict in comparison to
> {{com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleEvent(ValidationEvent)}}
> and returns {{false}} (cannot recover) if the {{ValidationEvent.severity}}
> equals {{ValidationEvent.ERROR}}.
> In the following, details from a real-world Web service where we have
> encountered this issue.
> The issue can be observed when invoking the method {{GetListModel}} of this
> [Web service|http://webservices.eurotaxglass.com/wsdl/identification-v2.wsdl]
> whose reply message contains elements of the complex type {{ETGdateType}}
> that contains a field of type {{xsd:gMonth}} (and {{xsd:gYear}}). The
> following is an excerpt of the relevant part of a reply message:
> {code:xml}
>
> 07
> 2010
>
> {code}
> If invoked by a service client class from within a Web application deployed
> to Wildfly (which uses CXF), an unmarshalling error occurs and the following
> stack trace is logged:
> {noformat}
> 16:43:46,891 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default
> task-113) Interceptor for
> {http://www.eurotax.com/Webservices/Identification/}IdentificationStub#{http://www.eurotax.com/Webservices/Identification/}GetListModel
> has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault:
> Unmarshalling Error: 07
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:905)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:712)
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:179)
> at
> org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
> at com.sun.proxy.$Proxy147.getListModel(Unknown Source)
> at
> ch.sbi.forte.ws.client.etg.IdentificationServiceImpl.getListModel(IdentificationServiceImpl.java:277)
> at
> ch.sbi.forte.services.rest.CarInsuranceResource.getListModel(CarInsuranceResource.java:302)
> at
> ch.sbi.forte.services.rest.CarInsuranceResource$Proxy$_$$_WeldClientProxy.getListModel(Unknown
> Source)
> 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at
>
[jira] [Updated] (CXF-6836) Swagger2 tests need to be updated to do a more robust JSON or YAML comparison
[ https://issues.apache.org/jira/browse/CXF-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6836: -- Description: Swagger tests are doing the string to string comparison which is not reliable. The JSON/Yaml responses need to be read into some model beans and their properties analyzed (was: Swagger tests are doing the string to string comparison which is not reliable. The JSON/Yaml responses need to read into some model beans and their properties analyzed) > Swagger2 tests need to be updated to do a more robust JSON or YAML comparison > - > > Key: CXF-6836 > URL: https://issues.apache.org/jira/browse/CXF-6836 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Reporter: Sergey Beryozkin > > Swagger tests are doing the string to string comparison which is not > reliable. The JSON/Yaml responses need to be read into some model beans and > their properties analyzed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-5193) Support fixed data type
[
https://issues.apache.org/jira/browse/CXF-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199430#comment-15199430
]
Grzegorz Grzybek edited comment on CXF-5193 at 3/17/16 12:45 PM:
-
[~weberjn], [~dkulp], I checked with 3.1.5 and got:
{noformat}
$ idl2wsdl fixed.idl
$ wsdlvalidator fixed.wsdl
WSIBP Validator found
<{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
is NOT a SOAP binding
WSDLValidator Error :
line 26 column 48 of file:/home/ggrzybek/tmp/idl/fixed.wsdl: Duplicate key
value [fixeds.FixedStruct] declared for identity constraint of element "schema".
{noformat}
[~weberjn], you can always use:
{code:java}
module fixeds
{
typedef fixed<5,2> f;
struct FixedStruct
{
f oddFixed; // 123.67
};
interface FunctionTest
{
FixedStruct testFixeds(in FixedStruct aFixedStruct);
};
};
{code}
But I have a fix for anonymous fixed types:
https://github.com/apache/cxf/pull/123
was (Author: gzres):
[~weberjn], [~dkulp], I checked with 3.1.5 and got:
{noformat}
$ idl2wsdl fixed.idl
$ wsdlvalidator fixed.wsdl
WSIBP Validator found
<{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
is NOT a SOAP binding
WSDLValidator Error : org.xml.sax.SAXParseException; schema_reference: Failed
to read schema document 'xml.xsd', because 'file' access is not allowed due to
restriction set by the accessExternalSchema property.
{noformat}
[~weberjn], you can always use:
{code:java}
module fixeds
{
typedef fixed<5,2> f;
struct FixedStruct
{
f oddFixed; // 123.67
};
interface FunctionTest
{
FixedStruct testFixeds(in FixedStruct aFixedStruct);
};
};
{code}
But I have a fix for anonymous fixed types:
https://github.com/apache/cxf/pull/123
> Support fixed data type
> ---
>
> Key: CXF-5193
> URL: https://issues.apache.org/jira/browse/CXF-5193
> Project: CXF
> Issue Type: Improvement
> Components: CORBA Binding
>Affects Versions: 2.7.6
>Reporter: Jürgen Weber
> Attachments: fixed.idl
>
>
> Looks like the data type fixed is not supported:
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/idl2wsdl fixed.idl
> linda:/idl/functiontest /projekte/apache-cxf-2.7.6/bin/wsdlvalidator
> fixed.wsdl
> WSIBP Validator found
> <{http://cxf.apache.org/bindings/corba/idl/fixed}fixeds.FunctionTestCORBABinding>
> is NOT a SOAP binding
> WSDLValidator Error :
> line 15 column 48 of file:/projekte/temp/idl/functiontest/fixed.wsdl:
> Duplicate key value [fixeds.FixedStruct] declared for identity constraint of
> element "schema".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6836) Swagger2 tests need to be updated to do a more robust JSON or YAML comparison
Sergey Beryozkin created CXF-6836: - Summary: Swagger2 tests need to be updated to do a more robust JSON or YAML comparison Key: CXF-6836 URL: https://issues.apache.org/jira/browse/CXF-6836 Project: CXF Issue Type: Bug Reporter: Sergey Beryozkin Swagger tests are doing the string to string comparison which is not reliable. The JSON/Yaml responses need to read into some model beans and their properties analyzed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
