[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter

["Vedran Pavic (JIRA)" <ji...@apache.org>]

    [ 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)