Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 46757 invoked from network); 22 Aug 2009 06:39:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Aug 2009 06:39:20 -0000 Received: (qmail 50353 invoked by uid 500); 22 Aug 2009 06:39:42 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 50287 invoked by uid 500); 22 Aug 2009 06:39:42 -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 50277 invoked by uid 99); 22 Aug 2009 06:39:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Aug 2009 06:39:42 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FM_FAKE_HELO_VERIZON,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [206.46.173.19] (HELO vms173019pub.verizon.net) (206.46.173.19) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Aug 2009 06:39:30 +0000 Received: from [127.0.0.1] ([71.126.236.186]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KOR0028CMGY6345@vms173019.mailsrvcs.net> for dev@cxf.apache.org; Sat, 22 Aug 2009 01:39:09 -0500 (CDT) Message-id: <4A8F9281.7000001@ece.neu.edu> Date: Sat, 22 Aug 2009 02:38:57 -0400 From: Demetris User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-version: 1.0 To: dev@cxf.apache.org Subject: Re: Integrating JAX-RS runtime into DOSGi References: <01c401ca227c$76f99e40$1f02050a@emea.progress.com> <7581E7AD-7125-498F-A1CD-4BEA7D9E0856@ece.neu.edu> <25086130.post@talk.nabble.com> <4A8F8C4C.7070804@ece.neu.edu> In-reply-to: <4A8F8C4C.7070804@ece.neu.edu> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Ok - for whoever will actually read this email - sorry it's late so my previous email may be a bit confusing. The project I mentioned (included the link) and the Apache CXF Distributed OSGi seem to share similarities but the person who is working on that MS thesis is not really making a strong case for his work to differentiate it from RFC 119 and its implementation. That's why I was asking whether these are two different projects and apparently they are. My other two questions were clear: Apache CXF DOSGi is the RFC 119 implementation. I remember reading about that RFC and its early draft release last August - can someone tell me when the implementation in CXF (release 1) began? Thanks - I need sleep. Demetris wrote: > > After looking at the project I mentioned - here is the article here on > their web site: > (http://www.dosgi.com/distributed-osgi-webservices-articles-list/39-distributed-osgi-webservices-articles-category/55-initial-idea-distributed-osgi-through-web-services.html) > > it seems that the similarities between that MS thesis and this project > are a few. In the > article they mention that "*Apache CFX .. *This is the closest one > with this thesis project, > yet some significant differences maybe found as we go through deep to > compare" but they > don't really mention these diffs. So these are two separate projects. > > Apache CXF DOSGi is the RFC 119 implementation. I remember reading > about that RFC - > can someone tell me when the implementation in CXF begun? > > Thanks > > > Sergey Beryozkin wrote: >> Hi >> >> Have a look here please >> http://cxf.apache.org/distributed-osgi.html >> >> cheers, Sergey >> >> >> >> Demetris G wrote: >> >>> Hey Sergei and Josh >>> >>> Is the DOSGi you are referring in the essay of an email below the >>> Masters thesis I read once (and it became an open source branch of >>> an apache project) or is this a separate design? >>> We worked on a design calked p2pSOA the connected distributed OSGi >>> containers over p2p technologies while exposing the endpt bundles >>> as web services. So I am fairly interested in your discussion - I >>> just want a quick clarification so I can position your work in my >>> mind. Thanks >>> >>> On Aug 21, 2009, at 12:28 PM, "Sergey Beryozkin" >>> wrote: >>> >>> >>>> Hi Josh >>>> >>>> Can you please let me know if JAXB is being used for your JAX-RS >>>> endpoints ? >>>> I've spotted that for HTTP Service based JAX-RS endpoints no >>>> AegisProvider is being set - I'would actually like JAXB being used >>>> by default for JAXRS endpoints which will be consistent with the >>>> expectations of JAX-RS users in general - but I'd like to confirm >>>> first that JAXB is working ok in your case... >>>> >>>> thanks, Sergey >>>> >>>> >>>>> Sergey, >>>>> Thanks again for the detailed documentation you've provided in >>>>> this thread. >>>>> I was able to easily convert from JAX-WS to JAX-RS, which (I >>>>> think) will >>>>> make our lives even easier. Once we've got the ability to expose >>>>> a single >>>>> service with both of these frontends, I'll make use of that as well. >>>>> >>>>> I agree that the jaxrs.resource property is no longer needed, as >>>>> you can >>>>> simply register jaxrs resources as a dosgi services. >>>>> >>>>> Josh >>>>> >>>>> On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin >>>>> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I've applied your patch and I've completed the initial >>>>>> integration of >>>>>> JAX-RS into DOSGi RI. As it often happens I underestimated a bit how >>>>>> long it would take me to do it :-) but I'm quite happy now with >>>>>> what has >>>>>> been done so far. >>>>>> >>>>>> I haven't got a chance to write JAX-WS system tests yet - I was >>>>>> a bit >>>>>> constrained in time but judging from the code you did JAXWS/ >>>>>> databindings >>>>>> should be working nicely now - please feel free to add a system >>>>>> test, or >>>>>> either of us will do it asap. >>>>>> >>>>>> Now, the property names have actually changed and differ from >>>>>> those you >>>>>> provided in the patch. As David noted, it was recommended that DOSGI >>>>>> providers would use reverse domain names as prefixes to their custom >>>>>> configuration types, such as 'pojo' in case of DOSGI RI. >>>>>> Furthermore, >>>>>> 'pojo' was a bit constraining in that it did not reflect the >>>>>> fact that >>>>>> say SOAP or RS services were supported. Additionally, the DOSGI >>>>>> way is >>>>>> >>> >> >> >