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

Reply via email to