cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Spring integration using @Configuration & @ComponentScan annotations
Date Mon, 09 Dec 2013 15:18:58 GMT
I think the problem here is that CXF allows to run in very many 
environments. For users this is very nice but it creates a lot of 
complexity in CXF. Of course annotation processing is just a few lines 
of code for each case. The problem is though that this code is scattered 
throughout the whole cxf code.

This is of course only my personal opinion. We currently already support 
a lot of annotations. So adding the ones you planned to add does not 
really make things worse. I just think we should perhaps discuss to 
aproach this differently for cxf 3 or cxf 4.

In any case I think it is better to define our own annotations if we 
plan to parse them ourselfves.

Christian

On 09.12.2013 16:00, Sergey Beryozkin wrote:
> Hi Christian
>
> Sure, let the external frameworks do what they can do well.
> What I've found though over the years is that the users which do not 
> want to depend on those external frameworks miss on the features which 
> can easily be done without those external dependencies.
>
> For example, I'd like to have CXF interceptors easily discovered 
> within Blueprint deployments. It is not that important for JAX-RS 
> endpoints for example, CXF interceptors are not part of JAX-RS model, 
> but nice to have for the completeness.
>
> To be honest, it is always good to keep multiple options open. Some 
> CXF users work with Spring, some now with CDI, some with Blueprint and 
> some do not use the injections frameworks, and I'd like to have a code 
> in place that would would work with or without Spring for discovering 
> simple interceptors & features.
>
> For me, addressing CXF-5439 is about few lines of code. I don't mind 
> if it won't be considered a standard approach, because using a 
> standard approach (Named, etc) to create non-portable deployments (CXF 
> interceptors will obviously won't work without CXF) is not exactly a 
> standard approach in the end
>
> Sergey

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message