cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vedran Pavic (JIRA)" <>
Subject [jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
Date Wed, 01 Jun 2016 06:48:12 GMT


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

I wonder, if we really should do the frontend specific configurations in a shared autoconfigure

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 ?

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:

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:

JAX-RS specific configuration is conditional on presence of cxf-rt-frontend-jaxrs module and
is disabled on presence of bean named jaxRsServer

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?


> Consider adding Spring Boot starter
> -----------------------------------
>                 Key: CXF-6869
>                 URL:
>             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:
> 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
> 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

View raw message