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
