Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5227110312 for ; Tue, 11 Feb 2014 12:27:52 +0000 (UTC) Received: (qmail 49207 invoked by uid 500); 11 Feb 2014 12:27:50 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 48758 invoked by uid 500); 11 Feb 2014 12:27:46 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 48750 invoked by uid 99); 11 Feb 2014 12:27:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Feb 2014 12:27:45 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of drreta@gmail.com designates 209.85.223.173 as permitted sender) Received: from [209.85.223.173] (HELO mail-ie0-f173.google.com) (209.85.223.173) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Feb 2014 12:27:38 +0000 Received: by mail-ie0-f173.google.com with SMTP id y20so1737819ier.32 for ; Tue, 11 Feb 2014 04:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bLaB84pPNMtVUnAdFBqhG0IMtBKjhvaSLpR1K92ShCI=; b=ggDJOgQFD6X2+2P6ObU1ufW8vovaEcQ3auOoYfgWEXWKa6SuAOdNjxkDlT7fDYu4/j tevT78kBXHCCbSKko1nlE1IBeTmL9Bs73lV+KRVxUuWKjT5WhmTXDeHBwILbzUe7UpMF TwRaK586QyCTfA6qwLJRGmXCf+qTuTuCNzafxh7loXIHVrS06c6pzwwlKNRv3+z6dvYG FDH+s863jJn9FUVbYsBTA7afAw1iL7ptcyIGnKKALcKwZMPLNE83kJ/qDoMSmSPJu0SG kjItOVwOUC+YVq9k0S/CLwH8psfgF9a+1s/bnNdGmdJFwsHQ7r8M5AvIKbecDYxHaN+T glOQ== MIME-Version: 1.0 X-Received: by 10.50.120.105 with SMTP id lb9mr19623144igb.22.1392121637988; Tue, 11 Feb 2014 04:27:17 -0800 (PST) Received: by 10.42.222.74 with HTTP; Tue, 11 Feb 2014 04:27:17 -0800 (PST) In-Reply-To: <52FA06E7.60808@gmail.com> References: <52F7CC4D.1030405@gmail.com> <52F8F7E2.5070306@die-schneider.net> <52F9036B.40201@gmail.com> <52FA06E7.60808@gmail.com> Date: Tue, 11 Feb 2014 07:27:17 -0500 Message-ID: Subject: Re: Optional support for CDI integration ? From: Andrey Redko To: dev@cxf.apache.org Content-Type: multipart/alternative; boundary=047d7bd756dcb76e1304f22093fa X-Virus-Checked: Checked by ClamAV on apache.org --047d7bd756dcb76e1304f22093fa Content-Type: text/plain; charset=ISO-8859-1 Hi Sergey, That sounds exactly what I have in mind and, following Christian's comment, we may attach to existing CDI context if available and never create one. Thanks. Best Regards, Andriy Redko On Tue, Feb 11, 2014 at 6:17 AM, Sergey Beryozkin wrote: > Hi Andriy > > On 10/02/14 17:53, Andrey Redko wrote: > >> Hi guys, >> >> I have done some work trying to make CXF and CDI (Weld 2.x) working >> together and though I failed to make it work, I have got the approximate >> understanding how it might be implemented. >> From my prospective, to get basic @Inject working won't be very hard. The >> one assumption I have is that we don't have objection to use JNDI as it is >> the (one of) way to share BeanManager instance. >> Or we may look on Weld SE to see the possible alternatives to create and >> share BeanManager instance in non-JEE environments so we can have similar >> implementation in CXF. >> Thanks. >> >> I wonder, as far as the basic @Inject is concerned, can we just add Weld > and may be DeltaSpike. And then somehow load the CDI context from > CXFNonSpringServlet extension (ex, CXFCdiServlet), similarly to the way > CXFServlet, which is Spring aware, loads the Spring context... > > Looking for the cheapest/fastest way to do it :-) > Cheers, Sergey > > > Best Regards, >> Andriy Redko >> >> >> On Mon, Feb 10, 2014 at 11:50 AM, Sergey Beryozkin > >wrote: >> >> Hi Christian >>> >>> On 10/02/14 16:01, Christian Schneider wrote: >>> >>> Hi Sergey, >>>> >>>> CDI support could be quite interesting indeed. I already started >>>> experimenting with it too. >>>> See: >>>> https://github.com/cschneider/Karaf-Tutorial/tree/master/ >>>> tasklist-cdi/tasklist-webservice/src/main/java/net/lr/cxf/cdi >>>> >>>> >>>> I think we have to create a portable CDI extension like the ones in >>>> apache deltaspike: >>>> http://deltaspike.apache.org/documentation.html#module-overview >>>> In my experiments I even used a less advanced aproach and just created a >>>> custom annotation that is processed by cdi. This is probably not enough >>>> for good support though. >>>> >>>> So I propose we first experiment in some directions and then try to work >>>> out a first design. >>>> >>>> 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 :-) >>> >>> DeltaSpike looks interesting; I wonder if one can delegate to it in Java >>> SE...for it to inject the beans >>> >>> Cheers, Sergey >>> >>> >>> >>> Christian >>>> >>>> >>>> On 09.02.2014 19:43, Sergey Beryozkin wrote: >>>> >>>> Hi All, >>>>> Does it make sense to offer some optional support for CDI directly in >>>>> CXF ? I guess we can expect more and more queries about it going >>>>> forward, >>>>> >>>>> I'll want to investigate more about it in scope of the JAX-RS 2.0 spec >>>>> work anyway, but I wonder what can be done in CXF in general >>>>> >>>>> Thanks, Sergey >>>>> >>>>> >>>> >>>> >>>> >>> >> --047d7bd756dcb76e1304f22093fa--