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
On 09/12/13 14:52, Christian Schneider wrote:
What I could imagine for CDI is to implement a CDI extension for CXF in
deltaspike (http://deltaspike.apache.org/).
This way we could make sure it plays nicely with the cdi frameworks. It
also would have the advantage that we would not have to do the
annotation processing ourselves and instead can use the cdi framework
code for that.
Christian
On 09.12.2013 15:47, Sergey Beryozkin wrote:
It should also work in Spring only, yes.
I don't mind much against the Named/etc. As long as using it is as
simple as working with the CXF annotations.
For example, for JAX-RS, I don;t need Named & friends to get root
JAX-RS resources & providers discovered, the idea of the unification
of the annotations is good but it may not always be realistic to apply
it consistently
Sergey
On 09/12/13 14:37, Przemysław Bielicki wrote:
Christian, what is CDI for you?
You mean javax.inject (fully supported by Spring) or
javax.enterprise.inject (supported by Java EE containers)
On Mon, Dec 9, 2013 at 3:32 PM, cschneider [via CXF] <
[email protected]> wrote:
Basically I also like to use standard annotations instead of our custom
ones. The problem is though that CXF should also be able to run in a
CDI
environment.
In such an environment CXF annotation processing may conflict with CDI
annotation processing.
So I think using @Inject is great but we should leave the annotation
processing to the CDI framework the user chooses. I have not tested how
this works with the current CXF code but I think we should try to make
it compatible with CDI.
Does anyone have some experience with this?
Christian
On 09.12.2013 15:26, Przemysław Bielicki wrote:
Hi Sergey,
I'm not sure CXF-5439 <https://issues.apache.org/jira/browse/CXF-5439>
is a
really great idea. For me all CXF components should be just annotated
with
@javax.inject.Named and then injected using @javax.inject.Inject or
@javax.annotation.Resource. I prefer to use a well established
standards
instead of multiplying annotations - but maybe I am not aware of some
limitations, issue you mentioned could solve.
Anyway, my solution uses only javax.inject annotations and it works
pretty
well.
I will file the jira issue soon (probably not today), and it should be
clear then.
Cheers,
Przemyslaw
On Mon, Dec 9, 2013 at 3:20 PM, Sergey Beryozkin [via CXF] <
[hidden email] <http://user/SendEmail.jtp?type=node&node=5737569&i=0>>
wrote:
Hi
I added a prototype to the JAX-RS frontend,
http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/spring/SpringResourceServer.java
(based on the code fragment from Vladimir Kulev)
I think the similar thing can be done for all frontends indeed
We probably should get
https://issues.apache.org/jira/browse/CXF-5439
fixed first
Sergey
On 09/12/13 14:13, Christian Schneider wrote:
We have some factory classes but they are often not as convenient to
use
as the namespaces.
In any case it would be interesting to see what you did. Can you
open
a
jira and attach your code as a patch?
If it is just a few lines you can also just paste the code or
point to
a
github repo or similar.
Christian
On 09.12.2013 15:05, pbielicki wrote:
Hi,
in order to integrate CXF with Spring developers need to go through
an
XML
file, right (i.e.
http://cxf.apache.org/docs/writing-a-service-with-spring.html)?
Is it possible out-of-the box to integrate CXF with Spring using
annotation-driven context configuration? I am talking about
@org.springframework.context.annotation.Configuration and
@org.springframework.context.annotation.ComponentScan annotations
(
http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/context/annotation/Configuration.html).
Are they supported by CXF integration?
The goal is to avoid any XML configuration.
If it's not part of CXF I may help because I just implemented such
integration (few lines of code, really), and I find it pretty
useful.
Please let me know what you think? I wanted to open a JIRA issue
straight
away but I prefer to ask you before.
Cheers,
Przemyslaw Bielicki
--
View this message in context:
http://cxf.547215.n5.nabble.com/Spring-integration-using-Configuration-ComponentScan-annotations-tp5737561.html
Sent from the cxf-dev mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
------------------------------
If you reply to this email, your message will be added to the
discussion
below:
http://cxf.547215.n5.nabble.com/Spring-integration-using-Configuration-ComponentScan-annotations-tp5737561p5737565.html
To unsubscribe from Spring integration using @Configuration &
@ComponentScan annotations, click here<
.
NAML<
http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
------------------------------
If you reply to this email, your message will be added to the
discussion
below:
http://cxf.547215.n5.nabble.com/Spring-integration-using-Configuration-ComponentScan-annotations-tp5737561p5737569.html
To unsubscribe from Spring integration using @Configuration &
@ComponentScan annotations, click
here<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737561&code=cGJpZWxpY2tpQGdtYWlsLmNvbXw1NzM3NTYxfC0xODU3NDYzNDAz>
.
NAML<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
