[jira] [Created] (CXF-6927) check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use IBM JDK
Freeman Fang created CXF-6927: - Summary: check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use IBM JDK Key: CXF-6927 URL: https://issues.apache.org/jira/browse/CXF-6927 Project: CXF Issue Type: Bug Reporter: Freeman Fang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6927) check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use IBM JDK
[ https://issues.apache.org/jira/browse/CXF-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-6927: - Assignee: Freeman Fang > check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use > IBM JDK > - > > Key: CXF-6927 > URL: https://issues.apache.org/jira/browse/CXF-6927 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6927) check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use IBM JDK
[ https://issues.apache.org/jira/browse/CXF-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307379#comment-15307379 ] Freeman Fang commented on CXF-6927: --- If there's no msv fail fast so that can still use the fallback validator, to avoid the exception like java.lang.NoClassDefFoundError: com.sun.msv.reader.GrammarReaderController2 when use IBM jdk > check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use > IBM JDK > - > > Key: CXF-6927 > URL: https://issues.apache.org/jira/browse/CXF-6927 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6927) check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use IBM JDK
[ https://issues.apache.org/jira/browse/CXF-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-6927. --- Resolution: Fixed Fix Version/s: 3.2.0 3.1.7 3.0.10 > check if msv is available in Stax2ValidationUtils to avoid the NCDFE when use > IBM JDK > - > > Key: CXF-6927 > URL: https://issues.apache.org/jira/browse/CXF-6927 > Project: CXF > Issue Type: Bug >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.0.10, 3.1.7, 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6900) invalid signature in case of soap fault
[ https://issues.apache.org/jira/browse/CXF-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307814#comment-15307814 ] Colm O hEigeartaigh commented on CXF-6900: -- Where is this exception being thrown? Could you paste the stacktrace? Colm. > invalid signature in case of soap fault > --- > > Key: CXF-6900 > URL: https://issues.apache.org/jira/browse/CXF-6900 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.3 > Environment: windows 2008 jdk 1.6.0_45 >Reporter: david leruse >Assignee: Colm O hEigeartaigh > Fix For: 3.1.7 > > Attachments: server7.log > > > Hello, > Having signature verification problems on the cxf client-side with a .NET > Ws-fed protected webservice, I ask you a little help... > Here is a summary of the problem : > Most of the time, communication works well excepted when we got a soap fault > message. > Indeed signature validation works usually well excepted when > we receive a fault message inside the body of the soap message. Even In this > boundary case, signature verification works well excepted for one element, > the fault message (see the enclosed server7.log file). > After digging a bit, i've found that the calculated digest couldn't be equal > to the claimed one because the content of the message given to the > DigesterOutpustrream is not well canonicalized or normalized. > Partial decrypted msg > ... > >xmlns="http://www.w3.org/2003/05/soap-envelope";>DataNotFoundFault xml:lang="nl-BE">ContextContactInfo with Id '1' does not > exist. xmlns="http://schemas.riziv.fgov.be/contact/2015/08/faults"; > xmlns:i="http://www.w3.org/2001/XMLSchema-instance";>ContextContactInfoNotFoundContextContactInfo > with Id '1' does not exist. > > ... > Predigested input : > http://www.w3.org/2003/05/soap-envelope"; > xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > u:Id="_3"> xmlns="http://www.w3.org/2003/05/soap-envelope";>DataNotFoundFault xmlns="http://www.w3.org/2003/05/soap-envelope";> xml:lang="nl-BE">ContextContactInfo with Id '1' does not > exist. xmlns="http://schemas.riziv.fgov.be/contact/2015/08/faults";>ContextContactInfoNotFoundContextContactInfo > with Id '1' does not > exist. > Could you please check this problem and give me an advice ? > The library used are : > cxf 3.0.3 > wss4j 2.0.2 > xmlsec 2.0.2 > on a jdk 1.6.0_45 > Thanks in advance > David L -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6926) StaticSTSProperties does not allow initialization of crypto from Properties object
[ https://issues.apache.org/jira/browse/CXF-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-6926: - Fix Version/s: 3.2.0 3.1.7 > StaticSTSProperties does not allow initialization of crypto from Properties > object > -- > > Key: CXF-6926 > URL: https://issues.apache.org/jira/browse/CXF-6926 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.6 >Reporter: Andreas Vallen >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.1.7, 3.2.0 > > > This was working in CXF 3.0.7 courtesy of the getProps method which was > removed by git commit 40c9bfd, effective for 3.1 branch. > The former possibility to set an initialized Properties object was helpful as > an adapter to the spring infrastructure for properties (Resource and > Environment abstraction, property placeholder and such) instead of relying on > an additional external properties file sourced by cxf-specific mechanisms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6298) Memory leak in tomcat webapp
[
https://issues.apache.org/jira/browse/CXF-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307847#comment-15307847
]
GELOT Cédric commented on CXF-6298:
---
I think the problem is not related to CXF but tomcat : [Bug
59138|https://bz.apache.org/bugzilla/show_bug.cgi?id=59138]
> Memory leak in tomcat webapp
>
>
> Key: CXF-6298
> URL: https://issues.apache.org/jira/browse/CXF-6298
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.4
> Environment: Tomcat 7.0.55
>Reporter: Alessandro Canevese
>
> I'm developing a J2EE webapp with Spring 4.1, Struts2, etc.. I'm not able to
> redeploy my app under development more than a couple of times before a
> permgen / out of memory error is fired.
> To see if it's my Spring configuration fault, I've got rid of the jaxws bean
> and I've put the following code directly in a method:
> ...
> JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
> Client client = dcf.createClient(serviceUrl + "?wsdl");
> Object result = null;
> try
> {
> Object[] callResult = client.invoke(methodName, parameter);
> result = callResult[0];
> }
> catch (Exception ex)
> {
> log.error(ex);
> }
> ...use of result (without storing it anywhere)...
>
> Nothing has changed. Sooner or later, when I undeploy the webapp I get a
> couple of the following:
> mar 12, 2015 5:46:05 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> Grave: The web application [/soci-operativi] created a ThreadLocal with key
> of type [com.sun.xml.bind.v2.ClassFactory$1] (value
> [com.sun.xml.bind.v2.ClassFactory$1@2379cbe3]) and a value of type
> [java.util.WeakHashMap] (value [
> {class
> it.cai.auth.ws.core.service.UserGroup=java.lang.ref.WeakReference@1138b647,
> class
> it.cai.auth.ws.core.service.GetUserDataResponse=java.lang.ref.WeakReference@2246f826,
> class java.util.ArrayList=java.lang.ref.WeakReference@614d985e, class
> it.cai.auth.ws.core.service.User=java.lang.ref.WeakReference@2d4e753a, class
> it.cai.auth.ws.core.service.Authority=java.lang.ref.WeakReference@79f24a12}
> ]) but failed to remove it when the web application was stopped. Threads are
> going to be renewed over time to try and avoid a probable memory leak.
> mar 12, 2015 5:46:05 PM org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> Grave: The web application [/soci-operativi] created a ThreadLocal with key
> of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@11dd224a]) and
> a value of type [org.apache.cxf.BusFactory.BusHolder] (value
> [org.apache.cxf.BusFactory$BusHolder@4cf6316f]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> Just to be clear, classes it.cai.auth.ws.core.service.* are those dynamically
> created by CXF accessing the ws pointed by the serviceUrl above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6926) StaticSTSProperties does not allow initialization of crypto from Properties object
[ https://issues.apache.org/jira/browse/CXF-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-6926: Assignee: Colm O hEigeartaigh > StaticSTSProperties does not allow initialization of crypto from Properties > object > -- > > Key: CXF-6926 > URL: https://issues.apache.org/jira/browse/CXF-6926 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.6 >Reporter: Andreas Vallen >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.1.7, 3.2.0 > > > This was working in CXF 3.0.7 courtesy of the getProps method which was > removed by git commit 40c9bfd, effective for 3.1 branch. > The former possibility to set an initialized Properties object was helpful as > an adapter to the spring infrastructure for properties (Resource and > Environment abstraction, property placeholder and such) instead of relying on > an additional external properties file sourced by cxf-specific mechanisms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6925) Make per-realm crypto configuration as flexible as the static one
[ https://issues.apache.org/jira/browse/CXF-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-6925: Assignee: Colm O hEigeartaigh > Make per-realm crypto configuration as flexible as the static one > - > > Key: CXF-6925 > URL: https://issues.apache.org/jira/browse/CXF-6925 > Project: CXF > Issue Type: Improvement > Components: STS >Affects Versions: 3.0.7, 3.1.6 >Reporter: Andreas Vallen >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.1.7, 3.2.0 > > > CXF-4705 updated the StaticSTSProperties object to allow the user to specify > a URL + Properties object for signature + encryption crypto properties, > instead of just a String pointing to a File. > The per-realm configurability introduced in CXF-3924 is however still missing > this more flexible mechanism. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6925) Make per-realm crypto configuration as flexible as the static one
[ https://issues.apache.org/jira/browse/CXF-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-6925: - Fix Version/s: 3.2.0 3.1.7 > Make per-realm crypto configuration as flexible as the static one > - > > Key: CXF-6925 > URL: https://issues.apache.org/jira/browse/CXF-6925 > Project: CXF > Issue Type: Improvement > Components: STS >Affects Versions: 3.0.7, 3.1.6 >Reporter: Andreas Vallen >Priority: Minor > Fix For: 3.1.7, 3.2.0 > > > CXF-4705 updated the StaticSTSProperties object to allow the user to specify > a URL + Properties object for signature + encryption crypto properties, > instead of just a String pointing to a File. > The per-realm configurability introduced in CXF-3924 is however still missing > this more flexible mechanism. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6925) Make per-realm crypto configuration as flexible as the static one
[ https://issues.apache.org/jira/browse/CXF-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-6925. -- Resolution: Fixed > Make per-realm crypto configuration as flexible as the static one > - > > Key: CXF-6925 > URL: https://issues.apache.org/jira/browse/CXF-6925 > Project: CXF > Issue Type: Improvement > Components: STS >Affects Versions: 3.0.7, 3.1.6 >Reporter: Andreas Vallen >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.1.7, 3.2.0 > > > CXF-4705 updated the StaticSTSProperties object to allow the user to specify > a URL + Properties object for signature + encryption crypto properties, > instead of just a String pointing to a File. > The per-realm configurability introduced in CXF-3924 is however still missing > this more flexible mechanism. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6926) StaticSTSProperties does not allow initialization of crypto from Properties object
[ https://issues.apache.org/jira/browse/CXF-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-6926. -- Resolution: Fixed > StaticSTSProperties does not allow initialization of crypto from Properties > object > -- > > Key: CXF-6926 > URL: https://issues.apache.org/jira/browse/CXF-6926 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.6 >Reporter: Andreas Vallen >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.1.7, 3.2.0 > > > This was working in CXF 3.0.7 courtesy of the getProps method which was > removed by git commit 40c9bfd, effective for 3.1 branch. > The former possibility to set an initialized Properties object was helpful as > an adapter to the spring infrastructure for properties (Resource and > Environment abstraction, property placeholder and such) instead of relying on > an additional external properties file sourced by cxf-specific mechanisms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6900) invalid signature in case of soap fault
[
https://issues.apache.org/jira/browse/CXF-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308003#comment-15308003
]
Michael Smith commented on CXF-6900:
This is what I see when the fault comes back:
{noformat}
2016-05-30 15:42:48,299 DEBUG [http-bio-8080-exec-3|]
(PhaseInterceptorChain.java:305) - Invoking handleMessage on interceptor
org.apache.cxf.ws.policy.PolicyVerificationInFaultInterceptor@4214d970
May 30, 2016 3:42:48 PM
com.sun.xml.internal.messaging.saaj.soap.ver1_2.Fault1_2Impl
checkIfStandardFaultCode
SEVERE: SAAJ0435: Sender is not a standard Code value
May 30, 2016 3:42:48 PM com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl
setFaultCode
SEVERE: SAAJ0140: Empty/Null NamespaceURI specified for faultCode fc1:Sender
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy93.xxxomitted(Unknown Source)
at xxxommitted.wcf.xxxomitted.xxxomitted(XXXAdapterWcf.java:24)
...
Caused by: com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl:
Empty/Null NamespaceURI specified for faultCode "fc1:Sender"
at
com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(Unknown
Source)
at
com.sun.xml.internal.messaging.saaj.soap.impl.FaultImpl.setFaultCode(Unknown
Source)
at
org.apache.cxf.binding.soap.saaj.SAAJUtils.setFaultCode(SAAJUtils.java:66)
at
org.apache.cxf.jaxws.JaxWsClientProxy.createSoapFault(JaxWsClientProxy.java:229)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
... 58 more
{noformat}
> invalid signature in case of soap fault
> ---
>
> Key: CXF-6900
> URL: https://issues.apache.org/jira/browse/CXF-6900
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.0.3
> Environment: windows 2008 jdk 1.6.0_45
>Reporter: david leruse
>Assignee: Colm O hEigeartaigh
> Fix For: 3.1.7
>
> Attachments: server7.log
>
>
> Hello,
> Having signature verification problems on the cxf client-side with a .NET
> Ws-fed protected webservice, I ask you a little help...
> Here is a summary of the problem :
> Most of the time, communication works well excepted when we got a soap fault
> message.
> Indeed signature validation works usually well excepted when
> we receive a fault message inside the body of the soap message. Even In this
> boundary case, signature verification works well excepted for one element,
> the fault message (see the enclosed server7.log file).
> After digging a bit, i've found that the calculated digest couldn't be equal
> to the claimed one because the content of the message given to the
> DigesterOutpustrream is not well canonicalized or normalized.
> Partial decrypted msg
> ...
>
>xmlns="http://www.w3.org/2003/05/soap-envelope";>DataNotFoundFault xml:lang="nl-BE">ContextContactInfo with Id '1' does not
> exist. xmlns="http://schemas.riziv.fgov.be/contact/2015/08/faults";
> xmlns:i="http://www.w3.org/2001/XMLSchema-instance";>ContextContactInfoNotFoundContextContactInfo
> with Id '1' does not exist.
>
> ...
> Predigested input :
> http://www.w3.org/2003/05/soap-envelope";
> xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> u:Id="_3"> xmlns="http://www.w3.org/2003/05/soap-envelope";>DataNotFoundFault xmlns="http://www.w3.org/2003/05/soap-envelope";> xml:lang="nl-BE">ContextContactInfo with Id '1' does not
> exist. xmlns="http://schemas.riziv.fgov.be/contact/2015/08/faults";>ContextContactInfoNotFoundContextContactInfo
> with Id '1' does not
> exist.
> Could you please check this problem and give me an advice ?
> The library used are :
> cxf 3.0.3
> wss4j 2.0.2
> xmlsec 2.0.2
> on a jdk 1.6.0_45
> Thanks in advance
> David L
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15309408#comment-15309408
]
Vedran Pavic commented on CXF-6869:
---
Hi Sergey,
Thanks for your feedback and merging the latest set of improvements!
OK on JAX-RS service descriptions, we can revisit that once your changes in
that department unfold.
{quote}
I wonder, if we really should do the frontend specific configurations in a
shared autoconfigure module.
{quote}
{quote}
I'd like to discuss some options, such as introducing frontend specific
auto-configure modules. Or revisiting the idea of having only two modules, two
starters, one for JAX-WS and one for JAX-RS, with starters keeping some
auto-configuration code ? I appreciate the best practice is to keep the
starters code-free, but having a single auto-configure module may become
problematic for us going forward ?
{quote}
The whole point is to have a single auto-configuration module which holds all
the configuration code, and behaves differently depending on what's found on
your classpath (hence the {{@Conditional*}} annotations) and depending on your
configuration properties. For example, take a look at Spring Boot's own
autoconfigure module:
https://github.com/spring-projects/spring-boot/tree/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure
I don't see the point of splitting the code between the auto-configure and
starter modules, since it would IMO defeat the whole purpose of this approach
and could potentially confuse Spring Boot users since it would not be
consistent approach with Boot itself.
Regarding the {{SpringScanComponentServer}} and JAX-RS specific configuration,
I don't know if you noticed this part form one of my previous comments:
{quote}
JAX-RS specific configuration is conditional on presence of
cxf-rt-frontend-jaxrs module and is disabled on presence of bean named
jaxRsServer
{quote}
You need a server bean to register JAX-RS manually anyway, right? Simply name
it {{jaxRsServer}} and the auto-configuration of that part will back off, i.e.
no JAX-RS resources will be discovered and registered automatically.
Alternatively, we could have this conditional on a configuration property, for
example {{cxf.jawrs.component-scan}}. If you prefer not to discover and
register JAX-RS resources automatically, the default for that property would be
{{false}} and user which like that approach would just have to add
{{cxf.jawrs.component-scan=true}} to their configuration properties.
Anyway, I agree that this is a nice start and I'm looking forward to the next
release of CXF :)
BTW what is the targeted release and do you have an approximate ETA?
Thanks,
Vedran
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15309417#comment-15309417
]
Vedran Pavic commented on CXF-6869:
---
Sidenote - I originally named starter modules
{{cxf-spring-boot-starter-jax-rs}} and {{cxf-spring-boot-starter-jax-ws}}, but
looking at the names of other CXF modules (namely {{cxf-rt-frontend-jaxrs}} and
{{cxf-rt-frontend-jaxws}}) I wonder starter should be named
{{cxf-spring-boot-starter-jaxrs}} and {{cxf-spring-boot-starter-jaxws}} for
consistency?
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
