On 10/02/14 19:33, Christian Schneider wrote:
On 10.02.2014 17:50, Sergey Beryozkin wrote:
That looks interesting; if we talk about the two options Andrei
mentioned, I guess you'd like to follow the first one, i.e, have a
pretty comprehensive support, right ?
I wonder, what can we do to get a basic @Inject (ion) of CDI beans
into CXF service classes working ? That would do for a start for me :-)
Not really. I think we should not try to recreate CDI for cxf. Instead
we should attach CXF into a real CDI context using a portable extension.
Not really sure though how to do this. I mentioned deltaspike as they
offer such extensions. So we probably need to create something similar.
What I would like to avoid though is that CDI reaches into every cxf
module like it is the case for spring and blueprint.
If we assume we have about 20 cxf modules with extensions for blueprint
and spring this means we already have 40 "adapters".
If we add 3 more frameworks like this there will be 100 "adapters". So I
think we rather need to find a less intrusive way to integrate cxf into
additional frameworks. One such way would be to rely more on standard
java classes for configuration and use annotations and xml namespaces
rather sparsely.
Right, I was not really going ahead with the specific proposal to update
all the modules and such again to support CDI. We have the namespace
support for Blueprint & Spring and it does help the users which is
important, but I agree, lets try to find a less intrusive way of doing
the basic CDI injection working, you are right.
This is what I meant: what can we do to get a basic @Inject (ion) of CDI
beans into CXF service classes working. I'd like to propose to tackle a
basic issue as POC, have a WS or RS service instance injected with some
other bean (via @Inject)...
Thanks, Sergey
Christian
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
