[jira] [Updated] (CXF-6783) ReflectionServiceFactoryBean generates invalid WSDL if anonymousWrapperTypes==true
[
https://issues.apache.org/jira/browse/CXF-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barnabas Bodnar updated CXF-6783:
-
Description:
ReflectionServiceFactoryBean has the public property _anonymousWrapperTypes_
controlling whether the type (XSD) of a message is represented as standalone,
named type in the WSDL, or an anonymous, inline type (the default is _false_ ->
standalone, named). Setting it to _true_ effectuates producing the inline,
anonymous type, but this is, however, present also on top-level, as standalone
one, making the WSDL invalid (top-level types must have a name):
{code:xml}
...
...
...
{code}
Correctly:
{code:xml}
...
...
...
{code}
Fix-proposal: use *new XmlSchemaComplexType(schema,
!isAnonymousWrapperTypes())* in the line 1300 instead of *new
XmlSchemaComplexType(schema, true)*.
{code:title=rt/wsdl/src/main/java/org/apache/cxf/wsdl/service/factory/ReflectionServiceFactoryBean.java|borderStyle=solid}
1289 private void createWrappedMessageSchema(ServiceInfo serviceInfo,
AbstractMessageContainer wrappedMessage,
1290 AbstractMessageContainer
unwrappedMessage, SchemaInfo info,
1291 QName wrapperName) {
1292
1293 XmlSchema schema = info.getSchema();
1294 info.setElement(null); // the cached schema will be no good
1295 XmlSchemaElement el = new XmlSchemaElement(schema, true);
1296 el.setName(wrapperName.getLocalPart());
1297
1298 wrappedMessage.getFirstMessagePart().setXmlSchema(el);
1299
1300 XmlSchemaComplexType ct = new XmlSchemaComplexType(schema, true);
1301
1302 if (!isAnonymousWrapperTypes()) {
1303 ct.setName(wrapperName.getLocalPart());
1304 el.setSchemaTypeName(wrapperName);
1305 }
1306 el.setSchemaType(ct);
{code}
was:
ReflectionServiceFactoryBean has the public property _anonymousWrapperTypes_
controlling whether the type (XSD) of a message is represented as standalone,
named type in the WSDL, or an anonymous, inline type (the default is _false_,
also standalone, named). Setting it to _true_ effectuates producing the inline,
anonymous type, but this is, however, present also on top-level, as standalone
one, making the WSDL invalid (top-level types must have a name):
{code:xml}
...
...
...
{code}
Correctly:
{code:xml}
...
...
...
{code}
Fix-proposal: use *new XmlSchemaComplexType(schema,
!isAnonymousWrapperTypes())* in the line 1300 instead of *new
XmlSchemaComplexType(schema, true)*.
{code:title=rt/wsdl/src/main/java/org/apache/cxf/wsdl/service/factory/ReflectionServiceFactoryBean.java|borderStyle=solid}
1289 private void createWrappedMessageSchema(ServiceInfo serviceInfo,
AbstractMessageContainer wrappedMessage,
1290 AbstractMessageContainer
unwrappedMessage, SchemaInfo info,
1291 QName wrapperName) {
1292
1293 XmlSchema schema = info.getSchema();
1294 info.setElement(null); // the cached schema will be no good
1295 XmlSchemaElement el = new XmlSchemaElement(schema, true);
1296 el.setName(wrapperName.getLocalPart());
1297
1298 wrappedMessage.getFirstMessagePart().setXmlSchema(el);
1299
1300 XmlSchemaComplexType ct = new XmlSchemaComplexType(schema, true);
1301
1302 if (!isAnonymousWrapperTypes()) {
1303 ct.setName(wrapperName.getLocalPart());
1304 el.setSchemaTypeName(wrapperName);
1305 }
1306 el.setSchemaType(ct);
{code}
> ReflectionServiceFactoryBean generates invalid WSDL if
> anonymousWrapperTypes==true
> --
>
> Key: CXF-6783
> URL: https://issues.apache.org/jira/browse/CXF-6783
> Project: CXF
> Issue Type: Bug
> Components: Services
>Affects Versions: 3.1.5
>Reporter: Barnabas Bodnar
>Priority: Minor
>
> ReflectionServiceFacto
[jira] [Commented] (CXF-6785) AbstractHTTPDestination should handle the case when pathInfo of HttpServletRequest is null
[ https://issues.apache.org/jira/browse/CXF-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152052#comment-15152052 ] Sergey Beryozkin commented on CXF-6785: --- Hi Freeman What does 'requestUri' return when pathInfo is null ? Are you sure that a servlet path is not lost ? As far as CXF is concerned, if we have "/services/*" servlet path then services is included. Cheers, Sergey > AbstractHTTPDestination should handle the case when pathInfo of > HttpServletRequest is null > --- > > Key: CXF-6785 > URL: https://issues.apache.org/jira/browse/CXF-6785 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.0, 3.1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FEDIZ-153) Support OpenId Connect bridging in the Fediz IdP
Colm O hEigeartaigh created FEDIZ-153: - Summary: Support OpenId Connect bridging in the Fediz IdP Key: FEDIZ-153 URL: https://issues.apache.org/jira/browse/FEDIZ-153 Project: CXF-Fediz Issue Type: New Feature Reporter: Colm O hEigeartaigh Fix For: 1.3.0 Support OpenId Connect bridging in the Fediz IdP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FEDIZ-153) Support OpenId Connect bridging in the Fediz IdP
[ https://issues.apache.org/jira/browse/FEDIZ-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-153: - Assignee: Colm O hEigeartaigh > Support OpenId Connect bridging in the Fediz IdP > > > Key: FEDIZ-153 > URL: https://issues.apache.org/jira/browse/FEDIZ-153 > Project: CXF-Fediz > Issue Type: New Feature >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0 > > > Support OpenId Connect bridging in the Fediz IdP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6785) AbstractHTTPDestination should handle the case when pathInfo of HttpServletRequest is null
[ https://issues.apache.org/jira/browse/CXF-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152198#comment-15152198 ] Freeman Fang commented on CXF-6785: --- Hi Sergey, This issue comes from when I'm working on implementing cxf http-undertow transport. Cxf http-undertow transport will start an embeded undertow server, just like what jetty do. In Camel there's already a camel-undertow component and in Karaf which use pax-web there's also an undertow OSGi http service implementation so I think it's should be good we also have a http-undertow transport in CXF. I'm going to write a HEADUP to summarize what I did and append my code very soon to community(I still left few camel-cxf tests failure when run against the http-undertow transport ). So when I run all CXF system test with cxf http-undertow transport, I found this problem which cause ManualHttpMulitplexClientServerTest and MultiplexHttpAddressClientServerTest failure , I think it's probably undertow implementation specific(getPathInfo is null but use getRequestUri instead just works) and never saw this with jetty. Anyway, this change let me pass system test with cxf http-undertow transport and won't break any existing jetty tests. Best Regards Freeman Freeman > AbstractHTTPDestination should handle the case when pathInfo of > HttpServletRequest is null > --- > > Key: CXF-6785 > URL: https://issues.apache.org/jira/browse/CXF-6785 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.0, 3.1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6785) AbstractHTTPDestination should handle the case when pathInfo of HttpServletRequest is null
[
https://issues.apache.org/jira/browse/CXF-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152212#comment-15152212
]
Sergey Beryozkin commented on CXF-6785:
---
Hi Freeman
Thanks, I understand some HTTP stacks can return null and indeed it is
documented in HttpServletRequest that returning null is possible, that is fine.
But what does 'requestUri' return if pathInfo is null ?
As I said, are you sure 'contextServletPath' is not lost, i.e, should we have:
{code:java}
if (pathInfo != null) {
inMessage.put(Message.PATH_INFO, contextServletPath + pathInfo);
} else {
inMessage.put(Message.PATH_INFO, contextServletPath);
// instead of
// inMessage.put(Message.PATH_INFO, requestURI);
}
{code}
Cheers, Sergey
> AbstractHTTPDestination should handle the case when pathInfo of
> HttpServletRequest is null
> ---
>
> Key: CXF-6785
> URL: https://issues.apache.org/jira/browse/CXF-6785
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.2.0, 3.1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6785) AbstractHTTPDestination should handle the case when pathInfo of HttpServletRequest is null
[
https://issues.apache.org/jira/browse/CXF-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152290#comment-15152290
]
Freeman Fang commented on CXF-6785:
---
Hi Sergey,
No, the contextServletPath isn't lost, the difference is that the getPathInfo
is null for undertow.
For example, for the
MultiplexHttpAddressClientServerTest.testWithGetPortExtensionHttp, I print out
the values when run test against undertow and against jetty separately.
For the undertow
{code}
the contextPath is /NumberService/NumberPort
the servletPath is
the contextServletPath is /NumberService/NumberPort
the pathInfo is null
the requestURI is /NumberService/NumberPort/23
{code}
For the jetty
{code}
the contextPath is /NumberService/NumberPort
the servletPath is
the contextServletPath is /NumberService/NumberPort
the pathInfo is /23
the requestURI is /NumberService/NumberPort/23
{code}
Cheers
Freeman
> AbstractHTTPDestination should handle the case when pathInfo of
> HttpServletRequest is null
> ---
>
> Key: CXF-6785
> URL: https://issues.apache.org/jira/browse/CXF-6785
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.2.0, 3.1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6768) WS-Discovery missing schema when internet connection not present
[ https://issues.apache.org/jira/browse/CXF-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152295#comment-15152295 ] ASF GitHub Bot commented on CXF-6768: - GitHub user nwbirnie opened a pull request: https://github.com/apache/cxf/pull/108 [CXF-6768] Add ws-addr schema to catalog for offline support in WS-Discovery This patch addresses the issue with the ws-addr schema not being available without an internet connection. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nwbirnie/cxf cxf6768 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/108.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 #108 commit 749cf41ce2a410526041018cbd8b485a0a488518 Author: Nick Birnie Date: 2016-02-16T17:15:03Z [CXF-6768] Add ws-addr schema to catalog for offline support > WS-Discovery missing schema when internet connection not present > > > Key: CXF-6768 > URL: https://issues.apache.org/jira/browse/CXF-6768 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.4 >Reporter: Nick Birnie > > When running WS-Discovery without an internet connection, it would appear > that a document (ws-addr.xsd) referenced in the WS-D schema is not available. > The WS-Discovery service is published based on a schema that is included in > cxf-services-ws-discovery-api.jar with the name > wsdd-discovery-1.1-wsdl-os.xsd. This is located by > WSDiscoveryServiceImpl.java directly from the classpath. However, that schema > fails to parse without an internet connection, due to a missing miport on > ws-addr.xsd, which can be found in in cxf-core.jar/schemas.wsdl. However, I > believe there's no reason to expect this to be available to the XML parser, > since it's never registered in a OASIS catalog. > I did try compiling CXF and registering ws-addr.xsd via the > META-INF/jax-ws-catalog.xml format, but didn't get it to work. > Can anyone confirm if this is expected behaviour or if I'm doing something > wrong? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6787) not sufficient WadlGenerator presence detection
Romain Manni-Bucau created CXF-6787: --- Summary: not sufficient WadlGenerator presence detection Key: CXF-6787 URL: https://issues.apache.org/jira/browse/CXF-6787 Project: CXF Issue Type: Bug Affects Versions: 3.1.4, 3.0.3 Reporter: Romain Manni-Bucau org.apache.cxf.jaxrs.provider.ServerProviderFactory#createWadlGenerator do a loadClass to check WadlGenerator is there but if it is there in a upper classloader and cxf in a lower classloader then it will get instantiated but will not work (cause JAXRSUtil.currentmessage() will be loaded in both classloaders and will not be shared if the lower classloader is a webapp one). Would be great to check once loaded the instance is actually usable before adding it. This pattern is used in few other places - I suspect management part as well since I got the issue too - but this one broke archiva in tomee for instance. Side note: reported the versions I tested with but I guess most of CXF versions are affected -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6785) AbstractHTTPDestination should handle the case when pathInfo of HttpServletRequest is null
[ https://issues.apache.org/jira/browse/CXF-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152384#comment-15152384 ] Sergey Beryozkin commented on CXF-6785: --- Hi Freeman Ok, thanks, that seems to provide an equivalent substitution, Sergey > AbstractHTTPDestination should handle the case when pathInfo of > HttpServletRequest is null > --- > > Key: CXF-6785 > URL: https://issues.apache.org/jira/browse/CXF-6785 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.0, 3.1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6788) Allow to specify a filter class in the LogginggFeature
Christian Schneider created CXF-6788: Summary: Allow to specify a filter class in the LogginggFeature Key: CXF-6788 URL: https://issues.apache.org/jira/browse/CXF-6788 Project: CXF Issue Type: New Feature Components: logging Affects Versions: 3.1.5 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 3.1.6 Sometimes not all of the logging data should be sent out. One use case is a UserNameToken authentication where sensitive data is stored in the message body. The user should be able to configure a filter class in the LoggingFeature. The class could have an interface of Event filter(Event); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6787) not sufficient WadlGenerator presence detection
[ https://issues.apache.org/jira/browse/CXF-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152553#comment-15152553 ] Sergey Beryozkin commented on CXF-6787: --- Hi Romain I do not understand. If cxf-rt-rs-services-description is on the classpath then the assumption is it is usable if it can loaded. Why don't you exclude this module from the classpath ? Cheers, Sergey > not sufficient WadlGenerator presence detection > --- > > Key: CXF-6787 > URL: https://issues.apache.org/jira/browse/CXF-6787 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.3, 3.1.4 >Reporter: Romain Manni-Bucau > > org.apache.cxf.jaxrs.provider.ServerProviderFactory#createWadlGenerator do a > loadClass to check WadlGenerator is there but if it is there in a upper > classloader and cxf in a lower classloader then it will get instantiated but > will not work (cause JAXRSUtil.currentmessage() will be loaded in both > classloaders and will not be shared if the lower classloader is a webapp one). > Would be great to check once loaded the instance is actually usable before > adding it. > This pattern is used in few other places - I suspect management part as well > since I got the issue too - but this one broke archiva in tomee for instance. > Side note: reported the versions I tested with but I guess most of CXF > versions are affected -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6787) not sufficient WadlGenerator presence detection
[ https://issues.apache.org/jira/browse/CXF-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152561#comment-15152561 ] Sergey Beryozkin commented on CXF-6787: --- Or is it because you are trying the Swagger Feature ? Yes, we will need to split Swagger into a separate module :-) > not sufficient WadlGenerator presence detection > --- > > Key: CXF-6787 > URL: https://issues.apache.org/jira/browse/CXF-6787 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.3, 3.1.4 >Reporter: Romain Manni-Bucau > > org.apache.cxf.jaxrs.provider.ServerProviderFactory#createWadlGenerator do a > loadClass to check WadlGenerator is there but if it is there in a upper > classloader and cxf in a lower classloader then it will get instantiated but > will not work (cause JAXRSUtil.currentmessage() will be loaded in both > classloaders and will not be shared if the lower classloader is a webapp one). > Would be great to check once loaded the instance is actually usable before > adding it. > This pattern is used in few other places - I suspect management part as well > since I got the issue too - but this one broke archiva in tomee for instance. > Side note: reported the versions I tested with but I guess most of CXF > versions are affected -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6760) extract swagger2 feature in its own module
[ https://issues.apache.org/jira/browse/CXF-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6760: -- Assignee: Sergey Beryozkin Fix Version/s: 3.1.6 3.2.0 Issue Type: Task (was: Bug) > extract swagger2 feature in its own module > -- > > Key: CXF-6760 > URL: https://issues.apache.org/jira/browse/CXF-6760 > Project: CXF > Issue Type: Task >Affects Versions: 3.1.4 >Reporter: Romain Manni-Bucau >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.6 > > > the feature is not provided *with*dependencies so if cxf is in the container > and swagger the webapp then it leads very easily to issues. > Having an external module would make it smoother for integrations and doesnt > really hurt CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6743) Inconsistent versions of jax-rs specs can lead to OSGi pain
[
https://issues.apache.org/jira/browse/CXF-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152579#comment-15152579
]
Sergey Beryozkin commented on CXF-6743:
---
So far only the trunk has been updated
> Inconsistent versions of jax-rs specs can lead to OSGi pain
> ---
>
> Key: CXF-6743
> URL: https://issues.apache.org/jira/browse/CXF-6743
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
>Reporter: Benson Margulies
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.6
>
>
> CXF's dependency tree calls for:
> {code}
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
> {code}
> However, the Karaf features asks for a servicemix bundle that only provides
> version 2.0 of the spec, and indeed, there's no SM bundle for 2.0.1. So, an
> OSGi bundle built with CXF will be prone to try to import 2.0.1 of the
> package in this jar, and then fail to be able to wire it.
> If CXF really needs 2.0.1, then we need an SM bundle for 2.0.1 (and the CXF
> feature should reference it).
> I'll link the SM jira.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6743) Inconsistent versions of jax-rs specs can lead to OSGi pain
[
https://issues.apache.org/jira/browse/CXF-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-6743:
--
Assignee: Sergey Beryozkin
Fix Version/s: 3.1.6
3.2.0
> Inconsistent versions of jax-rs specs can lead to OSGi pain
> ---
>
> Key: CXF-6743
> URL: https://issues.apache.org/jira/browse/CXF-6743
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
>Reporter: Benson Margulies
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.6
>
>
> CXF's dependency tree calls for:
> {code}
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
> {code}
> However, the Karaf features asks for a servicemix bundle that only provides
> version 2.0 of the spec, and indeed, there's no SM bundle for 2.0.1. So, an
> OSGi bundle built with CXF will be prone to try to import 2.0.1 of the
> package in this jar, and then fail to be able to wire it.
> If CXF really needs 2.0.1, then we need an SM bundle for 2.0.1 (and the CXF
> feature should reference it).
> I'll link the SM jira.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6789) SwaggerFeature default resource package calculation should try to support multiple resource classes better
Sergey Beryozkin created CXF-6789: - Summary: SwaggerFeature default resource package calculation should try to support multiple resource classes better Key: CXF-6789 URL: https://issues.apache.org/jira/browse/CXF-6789 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Sergey Beryozkin Priority: Minor Fix For: 3.2.0, 3.1.6 If we have two resource classes, a.b.C and a.c.D, then the 2nd class will not be described because the package of the 1st class is selected, and the path is set to "a.b". The feature should try to set the default resource path to the common super package, example to "a." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6783) ReflectionServiceFactoryBean generates invalid WSDL if anonymousWrapperTypes==true
[
https://issues.apache.org/jira/browse/CXF-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152617#comment-15152617
]
ASF GitHub Bot commented on CXF-6783:
-
GitHub user bbodnar opened a pull request:
https://github.com/apache/cxf/pull/109
[CXF-6783], WSDL-generation: don't create anonymous top-level types
This commit fixes https://issues.apache.org/jira/browse/CXF-6783.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bbodnar/cxf 3.1.x-fixes
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/109.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 #109
commit a8a265f2ee437cc7e9f8bf222486f9563f19d785
Author: Barnabas Bodnar
Date: 2016-02-18T16:52:15Z
[CXF-6783], WSDL-generation: don't create anonymous top-level types
> ReflectionServiceFactoryBean generates invalid WSDL if
> anonymousWrapperTypes==true
> --
>
> Key: CXF-6783
> URL: https://issues.apache.org/jira/browse/CXF-6783
> Project: CXF
> Issue Type: Bug
> Components: Services
>Affects Versions: 3.1.5
>Reporter: Barnabas Bodnar
>Priority: Minor
>
> ReflectionServiceFactoryBean has the public property _anonymousWrapperTypes_
> controlling whether the type (XSD) of a message is represented as standalone,
> named type in the WSDL, or an anonymous, inline type (the default is _false_
> -> standalone, named). Setting it to _true_ effectuates producing the inline,
> anonymous type, but this is, however, present also on top-level, as
> standalone one, making the WSDL invalid (top-level types must have a name):
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...
>
> ...
>
> ...
>
> {code}
> Correctly:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
> ...
>
> ...
>
> ...
>
> {code}
> Fix-proposal: use *new XmlSchemaComplexType(schema,
> !isAnonymousWrapperTypes())* in the line 1300 instead of *new
> XmlSchemaComplexType(schema, true)*.
> {code:title=rt/wsdl/src/main/java/org/apache/cxf/wsdl/service/factory/ReflectionServiceFactoryBean.java|borderStyle=solid}
> 1289 private void createWrappedMessageSchema(ServiceInfo serviceInfo,
> AbstractMessageContainer wrappedMessage,
> 1290 AbstractMessageContainer
> unwrappedMessage, SchemaInfo info,
> 1291 QName wrapperName) {
> 1292
> 1293 XmlSchema schema = info.getSchema();
> 1294 info.setElement(null); // the cached schema will be no good
> 1295 XmlSchemaElement el = new XmlSchemaElement(schema, true);
> 1296 el.setName(wrapperName.getLocalPart());
> 1297
> 1298 wrappedMessage.getFirstMessagePart().setXmlSchema(el);
> 1299
> 1300 XmlSchemaComplexType ct = new XmlSchemaComplexType(schema, true);
> 1301
> 1302 if (!isAnonymousWrapperTypes()) {
> 1303 ct.setName(wrapperName.getLocalPart());
> 1304 el.setSchemaTypeName(wrapperName);
> 1305 }
> 1306 el.setSchemaType(ct);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6783) ReflectionServiceFactoryBean generates invalid WSDL if anonymousWrapperTypes==true
[
https://issues.apache.org/jira/browse/CXF-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152621#comment-15152621
]
ASF GitHub Bot commented on CXF-6783:
-
GitHub user bbodnar opened a pull request:
https://github.com/apache/cxf/pull/110
[CXF-6783], WSDL-generation: don't create anonymous top-level types
This commit fixes https://issues.apache.org/jira/browse/CXF-6783.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bbodnar/cxf master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/110.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 #110
> ReflectionServiceFactoryBean generates invalid WSDL if
> anonymousWrapperTypes==true
> --
>
> Key: CXF-6783
> URL: https://issues.apache.org/jira/browse/CXF-6783
> Project: CXF
> Issue Type: Bug
> Components: Services
>Affects Versions: 3.1.5
>Reporter: Barnabas Bodnar
>Priority: Minor
>
> ReflectionServiceFactoryBean has the public property _anonymousWrapperTypes_
> controlling whether the type (XSD) of a message is represented as standalone,
> named type in the WSDL, or an anonymous, inline type (the default is _false_
> -> standalone, named). Setting it to _true_ effectuates producing the inline,
> anonymous type, but this is, however, present also on top-level, as
> standalone one, making the WSDL invalid (top-level types must have a name):
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...
>
> ...
>
> ...
>
> {code}
> Correctly:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
> ...
>
> ...
>
> ...
>
> {code}
> Fix-proposal: use *new XmlSchemaComplexType(schema,
> !isAnonymousWrapperTypes())* in the line 1300 instead of *new
> XmlSchemaComplexType(schema, true)*.
> {code:title=rt/wsdl/src/main/java/org/apache/cxf/wsdl/service/factory/ReflectionServiceFactoryBean.java|borderStyle=solid}
> 1289 private void createWrappedMessageSchema(ServiceInfo serviceInfo,
> AbstractMessageContainer wrappedMessage,
> 1290 AbstractMessageContainer
> unwrappedMessage, SchemaInfo info,
> 1291 QName wrapperName) {
> 1292
> 1293 XmlSchema schema = info.getSchema();
> 1294 info.setElement(null); // the cached schema will be no good
> 1295 XmlSchemaElement el = new XmlSchemaElement(schema, true);
> 1296 el.setName(wrapperName.getLocalPart());
> 1297
> 1298 wrappedMessage.getFirstMessagePart().setXmlSchema(el);
> 1299
> 1300 XmlSchemaComplexType ct = new XmlSchemaComplexType(schema, true);
> 1301
> 1302 if (!isAnonymousWrapperTypes()) {
> 1303 ct.setName(wrapperName.getLocalPart());
> 1304 el.setSchemaTypeName(wrapperName);
> 1305 }
> 1306 el.setSchemaType(ct);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6787) not sufficient WadlGenerator presence detection
[
https://issues.apache.org/jira/browse/CXF-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152657#comment-15152657
]
Romain Manni-Bucau commented on CXF-6787:
-
if you have:
{code}
common.loader
| |
web1 web2
{code}
if common loader has CXF and web1/WEB-INF/lib has cxf but the description
module then web1 will be able to load the class but its classloader will be
upper the web1 where cxf bus and rs modules for instance will be loaded so the
wadlgenerator will not work.
A quick fix for my case (tomcat/tomee) is to check
wadlgenerator.getClassLoader() != JAXRSUtils.getClassLoader().getParent() but I
guess it would be easier to check it trying to call it or anything else.
Side note: a workaround is to add to web1 the description jar but this is not a
real solution, more a workaround
> not sufficient WadlGenerator presence detection
> ---
>
> Key: CXF-6787
> URL: https://issues.apache.org/jira/browse/CXF-6787
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.3, 3.1.4
>Reporter: Romain Manni-Bucau
>
> org.apache.cxf.jaxrs.provider.ServerProviderFactory#createWadlGenerator do a
> loadClass to check WadlGenerator is there but if it is there in a upper
> classloader and cxf in a lower classloader then it will get instantiated but
> will not work (cause JAXRSUtil.currentmessage() will be loaded in both
> classloaders and will not be shared if the lower classloader is a webapp one).
> Would be great to check once loaded the instance is actually usable before
> adding it.
> This pattern is used in few other places - I suspect management part as well
> since I got the issue too - but this one broke archiva in tomee for instance.
> Side note: reported the versions I tested with but I guess most of CXF
> versions are affected
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6786) avoid Error log from NamePasswordCallbackHandler
[
https://issues.apache.org/jira/browse/CXF-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-6786.
---
Resolution: Fixed
Fix Version/s: 3.0.9
3.1.6
3.2.0
> avoid Error log from NamePasswordCallbackHandler
>
>
> Key: CXF-6786
> URL: https://issues.apache.org/jira/browse/CXF-6786
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.2.0, 3.1.6, 3.0.9
>
>
> If we deploy a cxf rest endpoint in karaf with JAAS enabled, we get Error
> message like
> {code}
> 2016-02-09T09:05:26.515-0600 | ERROR | qtp1245173695-70 |
> NamePasswordCallbackHandler | 74 - org.apache.cxf.cxf-core - 3.0.4 | ... |
> Unsupported callback type
> org.apache.karaf.jaas.modules.publickey.PublickeyCallback
> {code}
> This is because by default Karaf enable multiple jaas modules, like
> {code}
>
> className="org.apache.karaf.jaas.modules.properties.PropertiesLoginModule"
> flags="optional">
> users = $[karaf.etc]/users.properties
> detailed.login.exception = ${detailed.login.exception}
> encryption.name = ${encryption.name}
> encryption.enabled = ${encryption.enabled}
> encryption.prefix = ${encryption.prefix}
> encryption.suffix = ${encryption.suffix}
> encryption.algorithm = ${encryption.algorithm}
> encryption.encoding = ${encryption.encoding}
>
> className="org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule"
> flags="optional">
> users = $[karaf.etc]/keys.properties
> detailed.login.exception = ${detailed.login.exception}
>
> className="org.apache.karaf.jaas.modules.audit.FileAuditLoginModule"
> flags="optional">
> enabled = ${audit.file.enabled}
> file = ${audit.file.file}
>
> className="org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule"
> flags="optional">
> enabled = ${audit.eventadmin.enabled}
> topic = ${audit.eventadmin.topic}
>
>
> {code}
> So when the JAAS try the PublickeyLoginModule, the
> org.apache.karaf.jaas.modules.publickey.PublickeyCallback would be passed
> into CXF NamePasswordCallbackHandler which cause this Error log. As this is
> actually harmless because the "AA" passed using PropertiesLoginModule, we
> should lower this message level
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6790) change accessibility of WadlGenerator.getBaseUri(...) to protected
Xu ShiChang Desmond created CXF-6790: Summary: change accessibility of WadlGenerator.getBaseUri(...) to protected Key: CXF-6790 URL: https://issues.apache.org/jira/browse/CXF-6790 Project: CXF Issue Type: Wish Affects Versions: 3.1.1 Reporter: Xu ShiChang Desmond Priority: Minor I wish to subclass WadlGenerator and override getBaseUri(...) but it is unfortunately private. Would be swell if you could you change it to 'protected' instead.. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
