Re: General question about DOSGi
Hi, CXF DOSGi implementation is based on CXF and exposes OSGi services as REST service. That's an approach for DOSGi, but it's not the only one. In Cellar, you have another DOSGi implementation based on NIO/Hazelcast. Another one is Eclipse RemoteService. Each has pros/cons. Anyway, the purpose of DOSGi is to provide remote service invocation. So, a service is exposed on a node and used remotely on another one. It should be transparent for your code (the only minor change is that the service that has to be exposed for remote call should contain exported.service.interface property). Regards JB On 10/23/2017 10:13 PM, Massimo Bono wrote: Hello, I'm trying to grasp my mind on DOSGi; I want to have a general idea on the main concepts before start coding. A while ago I tried (with success) to replicate the awesome tutorial Christian provided (available https://github.com/apache/cxf-dosgi/tree/master/samples/rest). Now, before continuing coding, I want to understand why DOSGi is useful in my use case. Briefly, I want to code with Declarative Services with Karaf because i feel it's a more OSGi oriented way to define and bind services. Furthermore, I want my OSGi framework to recreate a web page the user can interact with: CXF can easily be deployed in Karaf, so I felt like it was a good choice over the other alternatives (like jetty). I used RESTful services as well, just to have something well structured. In a previous question, Christian suggested me to use DOSGi to fullly implement this scenario. After the successful attempt, I read the following resources on the topic. 1) http://cxf.apache.org/distributed-osgi-reference.html; 2) https://github.com/apache/cxf-dosgi; http://www.liquid-reality.de/display/liquid/2013/02/13/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi; Especially from the last one: It seems that DOSGi is used to let an OSGi framework B access to services located on a OSGi framework A. This is all good and dandy but in my scenario (Karaf + CXF exposing a REST service) where are the 2 OSGI containers? I can see only one, namely the one on my laptop in localhost! I'm sure I'm missing something, probably for my inexperience. Can someone solves this question of mine? Thanks! -- *Ing. Massimo Bono* -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: General question about DOSGi
Hi, I'm confuse too, I see the many solutions : DOSGi, CXF servlet with HttpService, CXF via blueprint, CXF via spring, Camel component (Rest, CXF...) Actually I'm trying all this solutions, I don't want to use Blueprint or Spring, I prefere using Declarative Service and in this case I see DOSGi, CXFServlet or Camel. The question about DOSGi for me is, is it the best way for publishing services if this services are not consumed by other OSGi services. Sorry I don't have the response but I'm very interesting to have some advices on this point :) Le 24/10/2017 à 00:13, Massimo Bono a écrit : > Hello, > > I'm trying to grasp my mind on DOSGi; I want to have a general idea on > the main concepts before start coding. > > A while ago I tried (with success) to replicate the awesome tutorial > Christian provided > (available https://github.com/apache/cxf-dosgi/tree/master/samples/rest). > > Now, before continuing coding, I want to understand why DOSGi is > useful in my use case. > > Briefly, I want to code with Declarative Services with Karaf because i > feel it's a more OSGi oriented way to define and bind services. > Furthermore, I want my OSGi framework to recreate a web page the user > can interact with: CXF can easily be deployed in Karaf, so I felt like > it was a good choice over the other alternatives (like jetty). I used > RESTful services as well, just to have something well structured. > In a previous question, Christian suggested me to use DOSGi to fullly > implement this scenario. > After the successful attempt, I read the following resources on the topic. > > 1) http://cxf.apache.org/distributed-osgi-reference.html; > 2) https://github.com/apache/cxf-dosgi; > http://www.liquid-reality.de/display/liquid/2013/02/13/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi; > > Especially from the last one: It seems that DOSGi is used to let an > OSGi framework B access to services located on a OSGi framework A. > This is all good and dandy but in my scenario (Karaf + CXF exposing a > REST service) where are the 2 OSGI containers? I can see only one, > namely the one on my laptop in localhost! > > I'm sure I'm missing something, probably for my inexperience. > Can someone solves this question of mine? > > Thanks! > > -- > *Ing. Massimo Bono*
Re: Karaf git repo gone?
The official repository is now https://gitbox.apache.org/repos/asf?p=karaf.git or https://github.com/apache/karaf This is unfortunate that all the links are broken. Maybe infra can setup a redirect... Guillaume 2017-10-24 0:26 GMT+02:00 Seth Leger: > Hi everyone, > > The Karaf git repo at: > > https://git-wip-us.apache.org/repos/asf?p=karaf.git > > appears to have been removed. Was this intentional? It makes tracking > down things in JIRA very difficult because all of the automated git repo > links are now broken. > > Seth Leger > The OpenNMS Group, Inc. > -- Guillaume Nodet
Re: Karaf git repo gone?
Hi Seth, I've copied in below email from earlier today on Karaf Dev email list: "Hi all, FYI, INFRA moved our git repositories (for Karaf "Container", and subprojects like Cellar, Decanter, ...) on gitbox. You have to update your local copies to reflect that. If you have any issue in term of permission, please let me know. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org" Details are here: https://issues.apache.org/jira/browse/INFRA-15265 All repos have been moved. See https://gitbox.apache.org/repos/asf/ Committers need to visit https://gitbox.apache.org/setup/ to link accounts. On Mon, Oct 23, 2017 at 7:56 PM, Seth Legerwrote: > Hi everyone, > > The Karaf git repo at: > > https://git-wip-us.apache.org/repos/asf?p=karaf.git > > appears to have been removed. Was this intentional? It makes tracking > down things in JIRA very difficult because all of the automated git repo > links are now broken. > > Seth Leger > The OpenNMS Group, Inc.
Karaf git repo gone?
Hi everyone, The Karaf git repo at: https://git-wip-us.apache.org/repos/asf?p=karaf.git appears to have been removed. Was this intentional? It makes tracking down things in JIRA very difficult because all of the automated git repo links are now broken. Seth Leger The OpenNMS Group, Inc.
General question about DOSGi
Hello, I'm trying to grasp my mind on DOSGi; I want to have a general idea on the main concepts before start coding. A while ago I tried (with success) to replicate the awesome tutorial Christian provided (available https://github.com/apache/cxf-dosgi/tree/master/samples/rest). Now, before continuing coding, I want to understand why DOSGi is useful in my use case. Briefly, I want to code with Declarative Services with Karaf because i feel it's a more OSGi oriented way to define and bind services. Furthermore, I want my OSGi framework to recreate a web page the user can interact with: CXF can easily be deployed in Karaf, so I felt like it was a good choice over the other alternatives (like jetty). I used RESTful services as well, just to have something well structured. In a previous question, Christian suggested me to use DOSGi to fullly implement this scenario. After the successful attempt, I read the following resources on the topic. 1) http://cxf.apache.org/distributed-osgi-reference.html; 2) https://github.com/apache/cxf-dosgi; http://www.liquid-reality.de/display/liquid/2013/02/13/Apache+Karaf+Tutorial+Part+8+-+Distributed+OSGi ; Especially from the last one: It seems that DOSGi is used to let an OSGi framework B access to services located on a OSGi framework A. This is all good and dandy but in my scenario (Karaf + CXF exposing a REST service) where are the 2 OSGI containers? I can see only one, namely the one on my laptop in localhost! I'm sure I'm missing something, probably for my inexperience. Can someone solves this question of mine? Thanks! -- *Ing. Massimo Bono*