Re: Missing requirement of org.osgi.service.component
Hi JB, by doing feature:info scr, I have obtained: Feature scr 4.2.7 Description: Declarative Service support Feature has no configuration Feature has no configuration files Feature has no dependencies. Feature contains followed bundles: mvn:org.osgi/org.osgi.util.function/1.0.0 start-level=30 mvn:org.osgi/org.osgi.util.promise/1.0.0 start-level=30 mvn:org.apache.felix/org.apache.felix.metatype/1.2.2 start-level=30 mvn:org.apache.felix/org.apache.felix.scr/2.1.16 start-level=30 Feature contains followed conditionals: Conditional(management) has no configuration Conditional(management) has no configuration files Conditional(management) has no dependencies. Conditional(management) contains followed bundles: mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.2.7 start-level=30 Conditional(webconsole) has no configuration Conditional(webconsole) has no configuration files Conditional(webconsole) has no dependencies. Conditional(webconsole) contains followed bundles: mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 start-level=30 mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.1.0 start-level=30 Conditional(bundle) has no configuration Conditional(bundle) has no configuration files Conditional(bundle) has no dependencies. Conditional(bundle) contains followed bundles: mvn:org.apache.karaf.scr/org.apache.karaf.scr.state/4.2.7 start-level=30 Seems like scr version is 4.2.7. Again I want to highlight the fact that this missing requirement happens only when performing automated testing. When installing the bundle, I can detect that installing and starting the feature "scr" does solve the requirement (since "bundle:diag" shows no unsatisfied requirements from scr after the feature is installed). Il giorno mar 17 dic 2019 alle ore 22:07 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > Hi, > > it's supported. If you take a look on the SCR bundle installed, it > should be good. > > Do you use a different SCR version ? Can you check the scr feature > version installed ? > > Regards > JB > > On 17/12/2019 18:51, Massimo Bono wrote: > > Hi, > > > >> Long story short, annotation inheritance is something that you are > strongly discouraged from doing. > > > > ok, perfect. > > > >> This error is actually not to do with annotation inheritance. Instead > > the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support > it. > > > > I genuinely though karaf supported DS1.3 specification (in constrast to > > the recent DS 1.4, which it shouldn't be supported yet): do you know the > > link where the DS support is publicly announced? Thanks > > > > Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward > <mailto:tim.w...@paremus.com>> ha scritto: > > > > Hi Massimo, > > > >> Am I doing something which is invalid? > > > > Long story short, annotation inheritance is something that you are > > strongly discouraged from doing. > > > > The DS annotations are not designed to be inherited by child > > classes, technically this is a violation of encapsulation because > > the DS runtime is reflectively calling fields/methods on a super > > type which is defined in another bundle. As DS is allowed to (and > > normally does) operate on default or private visibility members this > > means that you can end up referencing the private internals of > > another bundle (the one holding the super type) in another bundle > > (the one holding the component). This can then break at runtime if > > you wire to an updated version of the super type which has (for > > example) changed the name of a private field. > > > > If you do want to use inherited annotations across bundles (not a > > good idea) then you can do so by using bnd configuration > > <https://bnd.bndtools.org/instructions/dsannotations-options.html>. > > > >> org.apache.felix.resolver.reason.ReasonException: Unable to > >> resolve root: missing requirement [root] osgi.identity; > >> osgi.identity=FOO; type=karaf.feature; version=0; > >> filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))" > >> [caused by: Unable to resolve FOO/0.0.1: missing requirement > >> [FOO/0.0.1] osgi.identity; osgi.identity=FOO; type=osgi.bundle; > >> version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable > >> to resolve FOO/0.0.1: missing requirement [FOO/0.0.1] > >> osgi.wiring.package; > >> > > filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(versi
Re: Missing requirement of org.osgi.service.component
Ok, something is not right ( or I'm stupid). by inspecting scr feature (feature:info scr) I obtain the following output: Feature scr 4.2.7 Description: Declarative Service support Feature has no configuration Feature has no configuration files Feature has no dependencies. Feature contains followed bundles: mvn:org.osgi/org.osgi.util.function/1.0.0 start-level=30 mvn:org.osgi/org.osgi.util.promise/1.0.0 start-level=30 mvn:org.apache.felix/org.apache.felix.metatype/1.2.2 start-level=30 mvn:org.apache.felix/org.apache.felix.scr/2.1.16 start-level=30 Feature contains followed conditionals: Conditional(management) has no configuration Conditional(management) has no configuration files Conditional(management) has no dependencies. Conditional(management) contains followed bundles: mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.2.7 start-level=30 Conditional(webconsole) has no configuration Conditional(webconsole) has no configuration files Conditional(webconsole) has no dependencies. Conditional(webconsole) contains followed bundles: mvn:org.apache.felix/org.apache.felix.inventory/1.0.4 start-level=30 mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.1.0 start-level=30 Conditional(bundle) has no configuration Conditional(bundle) has no configuration files Conditional(bundle) has no dependencies. Conditional(bundle) contains followed bundles: mvn:org.apache.karaf.scr/org.apache.karaf.scr.state/4.2.7 start-level=30 in particular, "mvn:org.apache.felix/org.apache.felix.scr/2.1.16 start-level=30" is installed in my framework and by performing "bundle:headers" I obtain an output which export package includes: Export-Package = org.apache.felix.scr.component;uses:=org.osgi.service.component;version=1.1.0, org.apache.felix.scr.info;version=1.0.0, org.osgi.service.component;uses:=org.osgi.framework;version=1.4, org.osgi.service.component.runtime;uses:="org.osgi.framework,org.osgi.service.component.runtime.dto,org.osgi.util.promise";version=1.4, org.osgi.service.component.runtime.dto;uses:="org.osgi.dto,org.osgi.framework.dto";version=1.4 hence scr correctly expose org.osgi.servicve.components (even version 1.4!). I also notice that if i perform these steps on a normal karaf instance (via shell) " org.osgi.service.component" is actually found. *It seems the problem is present only when performing automated testing with Pax-Exam. -.-"* Forget performing annotation inheritance. Any ideas on how to solve the missing requirement of scr? BTW I have apache karaf 4.2.7 Il giorno mar 17 dic 2019 alle ore 19:08 Tim Ward ha scritto: > I genuinely though karaf supported DS1.3 specification (in constrast to > the recent DS 1.4, which it shouldn't be supported yet): do you know the > link where the DS support is publicly announced? Thanks > > > I’ll leave this to someone more expert in Karaf releases than I. My aim > was simply to turn the resolver output into plain English (it’s not > amazingly human readable). > > The exact failure is that nobody is providing the > org.osgi.service.component package (the one containing ComponentContext) at > a version greater than or equal to 1.3, but loader than 2.0. This is > required for any compliant DS implementation at version 1.3 or 1.4, hence > my statement that the Karaf you’re deploying into doesn’t support DS (if it > did it would have the package). You may be able to fix this by referencing > another feature to deploy DS and add the support to your Karaf, but there > are issues in Karaf if you end up with two DS implementations running at > the same time (and there really should be one deployed by default!). > > I hope this helps. > > Tim > > Sent from my iPhone > > On 17 Dec 2019, at 17:51, Massimo Bono wrote: > > Hi, > > > Long story short, annotation inheritance is something that you are > strongly discouraged from doing. > > ok, perfect. > > > This error is actually not to do with annotation inheritance. Instead > the issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it. > > I genuinely though karaf supported DS1.3 specification (in constrast to > the recent DS 1.4, which it shouldn't be supported yet): do you know the > link where the DS support is publicly announced? Thanks > > Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward > ha scritto: > >> Hi Massimo, >> >> Am I doing something which is invalid? >> >> >> Long story short, annotation inheritance is something that you are >> strongly discouraged from doing. >> >> The DS annotations are not designed to be inherited by child classes, >> technically this is a violation of encapsulation because the DS runtime is >> reflectively calling fields/methods on a super type which is defined in >>
Re: Missing requirement of org.osgi.service.component
Hi,
> Long story short, annotation inheritance is something that you are
strongly discouraged from doing.
ok, perfect.
> This error is actually not to do with annotation inheritance. Instead the
issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
I genuinely though karaf supported DS1.3 specification (in constrast to the
recent DS 1.4, which it shouldn't be supported yet): do you know the link
where the DS support is publicly announced? Thanks
Il giorno mar 17 dic 2019 alle ore 18:39 Tim Ward ha
scritto:
> Hi Massimo,
>
> Am I doing something which is invalid?
>
>
> Long story short, annotation inheritance is something that you are
> strongly discouraged from doing.
>
> The DS annotations are not designed to be inherited by child classes,
> technically this is a violation of encapsulation because the DS runtime is
> reflectively calling fields/methods on a super type which is defined in
> another bundle. As DS is allowed to (and normally does) operate on default
> or private visibility members this means that you can end up referencing
> the private internals of another bundle (the one holding the super type) in
> another bundle (the one holding the component). This can then break at
> runtime if you wire to an updated version of the super type which has (for
> example) changed the name of a private field.
>
> If you do want to use inherited annotations across bundles (not a good
> idea) then you can do so by using bnd configuration
> <https://bnd.bndtools.org/instructions/dsannotations-options.html>.
>
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.identity=FOO;
> type=karaf.feature; version=0;
> filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
> osgi.identity; osgi.identity=FOO; type=osgi.bundle;
> version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
> resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))”]]
>
>
> This error is actually not to do with annotation inheritance. Instead the
> issue is that you’re trying to use DS 1.3, but Karaf doesn’t support it.
>
> Tim
>
>
> On 17 Dec 2019, at 17:30, Massimo Bono wrote:
>
> Hi,
>
> I'm developing a bundle which provides an abstract class called
> "AbstractBundle". Such class uses DS annotation over abstract methods, like:
>
> @Deactivate
> public abstract void deactivate();
>
> This leads to the fact that the class imports classes from
> "org.osgi.service.component". I want to declare this abstract class mainly
> for allowing developers to automatically implements some important DS
> methods and for documentation purposes.
>
> The generated bundles has the correctly Import-Package entry
> (org.osgi.service.component;version="[1.3,2)"). However, when I try to test
> its installation in a "KarafTestSupport" derived class (where in the config
> i install the SCR feature via:
>
> KarafDistributionOption.features("standard", "scr")
>
> karaf still complaints about the missing reference. here the error:
>
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.identity=FOO;
> type=karaf.feature; version=0;
> filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
> [caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
> osgi.identity; osgi.identity=FOO; type=osgi.bundle;
> version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
> resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
>
> Note that I install the artifact exposing class AbstractBundle via a karaf
> feature.
>
> Am I doing something which is invalid?
>
> Thanks for any kind reply
>
> --
> *Ing. Massimo Bono*
>
>
>
--
*Ing. Massimo Bono*
Missing requirement of org.osgi.service.component
Hi,
I'm developing a bundle which provides an abstract class called
"AbstractBundle". Such class uses DS annotation over abstract methods, like:
@Deactivate
public abstract void deactivate();
This leads to the fact that the class imports classes from
"org.osgi.service.component". I want to declare this abstract class mainly
for allowing developers to automatically implements some important DS
methods and for documentation purposes.
The generated bundles has the correctly Import-Package entry
(org.osgi.service.component;version="[1.3,2)"). However, when I try to test
its installation in a "KarafTestSupport" derived class (where in the config
i install the SCR feature via:
KarafDistributionOption.features("standard", "scr")
karaf still complaints about the missing reference. here the error:
org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=FOO;
type=karaf.feature; version=0;
filter:="(&(osgi.identity=FOO)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve FOO/0.0.1: missing requirement [FOO/0.0.1]
osgi.identity; osgi.identity=FOO; type=osgi.bundle;
version="[0.0.1,0.0.1]"; resolution:=mandatory [caused by: Unable to
resolve FOO/0.0.1: missing requirement [FOO/0.0.1] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.osgi.service.component)(version>=1.3.0)(!(version>=2.0.0)))"]]
Note that I install the artifact exposing class AbstractBundle via a karaf
feature.
Am I doing something which is invalid?
Thanks for any kind reply
--
*Ing. Massimo Bono*
Re: XML Parsing Error in Apache Cave repository.xml
Thanks, really appreciating it! Il giorno mer 11 dic 2019 alle ore 20:12 ha scritto: > It's fine. Let me check if I can improve a bit the descriptor handling. > > Regards > JB > > Le 11 déc. 2019 10:59, Massimo Bono a écrit : > > ATM no, but in the future probably yes. > As a workaround, at the moment I'm deleting the repository.xml file before > calling "cave:repository-update-bundle-descriptor foo". Do you if this may > cause misbehaviours? > > Il giorno mer 11 dic 2019 alle ore 19:00 ha scritto: > > Hi > > That's the way OBR works unfortunately. You can split the artifacts in > different repositories. > > Do you have a lot of artifacts in your repository ? > > Regards > JB > > Le 11 déc. 2019 09:43, Massimo Bono a écrit : > > Hi, now the http url works. However, I'm getting the same problem I > previously described in > http://karaf.922171.n3.nabble.com/Testing-a-HTTP-GET-from-WAB-td4057052.html > > Specifically, everytime I run "cave:repository-update-bundle-descriptor > foo", new entries representing the same artifact are appended in the > repository.xml file, making the file bigger and bigger. This in turn make > obr:deploy fail. Is there a workaround? > > Il giorno mer 11 dic 2019 alle ore 17:20 Massimo Bono < > massimobo...@gmail.com> ha scritto: > > yes, I'm using Cave 4.2.0. Let me try 4.2.1 > > Il giorno mer 11 dic 2019 alle ore 16:27 Jean-Baptiste Onofré < > j...@nanthrax.net> ha scritto: > > Hi, > > I know what's the problem, I think ;) > > I guess you are using Cave 4.2.0. If so, can you please update to Cave > 4.2.1 ? I fixed issues on the repository location. > > Regards > JB > > On 11/12/2019 16:07, Massimo Bono wrote: > > Hi JB, > > > > here's the steps: > > 1) I've created the repository with "cave:repository-create foo"; > > 2) I changed the location with "cave:repository-location foo > > /home/x/.m2/repository" (I don't know why, but using -l argument in > > "cave:repository-create" didn't change the output of > > "cave:repository-info foo"); > > 3) I've populated the maven repo with some artifacts; > > 4) I've called "cave:repository-update-bundle-descriptor foo" > > > >> By the way, the cave feature doesn't exist, it's just cave-repository. > > > > Sorry, my bad: I wanted to write cave-repository > > > >> Did you clean you Karaf instance (data folder) if you migrated from a > > previous Cave version ? > > > > No, it's a clean installation > > > > Il giorno mer 11 dic 2019 alle ore 14:18 Jean-Baptiste Onofré > > mailto:j...@nanthrax.net>> ha scritto: > > > > Hi, > > > > did you generate the descriptor with the command first: > > > > cave:repository-update-bundle-descriptor foo > > > > ? > > > > By the way, the cave feature doesn't exist, it's just > cave-repository. > > Did you clean you Karaf instance (data folder) if you migrated from a > > previous Cave version ? > > > > Regards > > JB > > > > On 10/12/2019 15:47, Massimo Bono wrote: > > > Hi, > > > > > > I'm using apache cave 4.2.0 on an apache karaf instance 4.2.7. > > > > > > I've installed "cave" feature repo, and "cave-repository" feature. > I > > > then created a repository FOO and made pointing the storage to > maven > > > local repository (using "cave:repository-create > > > FOO"/"cave:repository-location"). > > > > > > Using "mvn" I've uploaded some artifacts in maven local repository. > > > Then, using "cave:repository-update-bundle-descriptor FOO" I've > > updated > > > repository.xml file. > > > > > > The problem is that if I connect to > > > "http://IPADDRESS:8181/cave/repository/foo/repository.xml; I > obtain: > > > > > > XML Parsing Error: no root element found > > > Location: > > http://172.17.0.2:8181/cave/repository/fibonacci/repository.xml > > > Line Number 1, Column 1: > > > > > > (Note that when I first create the repository the http link > correctly > > > works, albeit it doesn't contain anything) > > > However, by manually inspecting repository.xml I cannot find any > > syntax > > > issues (full file is not posted since it's a huge file): > > > >
Re: XML Parsing Error in Apache Cave repository.xml
ATM no, but in the future probably yes. As a workaround, at the moment I'm deleting the repository.xml file before calling "cave:repository-update-bundle-descriptor foo". Do you if this may cause misbehaviours? Il giorno mer 11 dic 2019 alle ore 19:00 ha scritto: > Hi > > That's the way OBR works unfortunately. You can split the artifacts in > different repositories. > > Do you have a lot of artifacts in your repository ? > > Regards > JB > > Le 11 déc. 2019 09:43, Massimo Bono a écrit : > > Hi, now the http url works. However, I'm getting the same problem I > previously described in > http://karaf.922171.n3.nabble.com/Testing-a-HTTP-GET-from-WAB-td4057052.html > > Specifically, everytime I run "cave:repository-update-bundle-descriptor > foo", new entries representing the same artifact are appended in the > repository.xml file, making the file bigger and bigger. This in turn make > obr:deploy fail. Is there a workaround? > > Il giorno mer 11 dic 2019 alle ore 17:20 Massimo Bono < > massimobo...@gmail.com> ha scritto: > > yes, I'm using Cave 4.2.0. Let me try 4.2.1 > > Il giorno mer 11 dic 2019 alle ore 16:27 Jean-Baptiste Onofré < > j...@nanthrax.net> ha scritto: > > Hi, > > I know what's the problem, I think ;) > > I guess you are using Cave 4.2.0. If so, can you please update to Cave > 4.2.1 ? I fixed issues on the repository location. > > Regards > JB > > On 11/12/2019 16:07, Massimo Bono wrote: > > Hi JB, > > > > here's the steps: > > 1) I've created the repository with "cave:repository-create foo"; > > 2) I changed the location with "cave:repository-location foo > > /home/x/.m2/repository" (I don't know why, but using -l argument in > > "cave:repository-create" didn't change the output of > > "cave:repository-info foo"); > > 3) I've populated the maven repo with some artifacts; > > 4) I've called "cave:repository-update-bundle-descriptor foo" > > > >> By the way, the cave feature doesn't exist, it's just cave-repository. > > > > Sorry, my bad: I wanted to write cave-repository > > > >> Did you clean you Karaf instance (data folder) if you migrated from a > > previous Cave version ? > > > > No, it's a clean installation > > > > Il giorno mer 11 dic 2019 alle ore 14:18 Jean-Baptiste Onofré > > mailto:j...@nanthrax.net>> ha scritto: > > > > Hi, > > > > did you generate the descriptor with the command first: > > > > cave:repository-update-bundle-descriptor foo > > > > ? > > > > By the way, the cave feature doesn't exist, it's just > cave-repository. > > Did you clean you Karaf instance (data folder) if you migrated from a > > previous Cave version ? > > > > Regards > > JB > > > > On 10/12/2019 15:47, Massimo Bono wrote: > > > Hi, > > > > > > I'm using apache cave 4.2.0 on an apache karaf instance 4.2.7. > > > > > > I've installed "cave" feature repo, and "cave-repository" feature. > I > > > then created a repository FOO and made pointing the storage to > maven > > > local repository (using "cave:repository-create > > > FOO"/"cave:repository-location"). > > > > > > Using "mvn" I've uploaded some artifacts in maven local repository. > > > Then, using "cave:repository-update-bundle-descriptor FOO" I've > > updated > > > repository.xml file. > > > > > > The problem is that if I connect to > > > "http://IPADDRESS:8181/cave/repository/foo/repository.xml; I > obtain: > > > > > > XML Parsing Error: no root element found > > > Location: > > http://172.17.0.2:8181/cave/repository/fibonacci/repository.xml > > > Line Number 1, Column 1: > > > > > > (Note that when I first create the repository the http link > correctly > > > works, albeit it doesn't contain anything) > > > However, by manually inspecting repository.xml I cannot find any > > syntax > > > issues (full file is not posted since it's a huge file): > > > > > > > > > http://www.osgi.org/xmlns/repository/v1.0.0; > > > name="foo" increment="1575988990424"> > > > > > > > > > .. > > > > > > > > > > > > > > > Note that if I query the same http url with "get", I obtain a 404 > > error. > > > > > > Am I doing something wrong? > > > Thanks for any kind reply > > > > > > -- > > > *Ing. Massimo Bono* > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org <mailto:jbono...@apache.org> > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > > > -- > > *Ing. Massimo Bono* > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > > > > -- > *Ing. Massimo Bono* > > > > -- > *Ing. Massimo Bono* > > > -- *Ing. Massimo Bono*
Re: XML Parsing Error in Apache Cave repository.xml
Sorry, I put the wrong link. The correct one is http://karaf.922171.n3.nabble.com/Bug-on-cave-repository-update-td4056780.html Il giorno mer 11 dic 2019 alle ore 18:43 Massimo Bono < massimobo...@gmail.com> ha scritto: > Hi, now the http url works. However, I'm getting the same problem I > previously described in > http://karaf.922171.n3.nabble.com/Testing-a-HTTP-GET-from-WAB-td4057052.html > > Specifically, everytime I run "cave:repository-update-bundle-descriptor > foo", new entries representing the same artifact are appended in the > repository.xml file, making the file bigger and bigger. This in turn make > obr:deploy fail. Is there a workaround? > > Il giorno mer 11 dic 2019 alle ore 17:20 Massimo Bono < > massimobo...@gmail.com> ha scritto: > >> yes, I'm using Cave 4.2.0. Let me try 4.2.1 >> >> Il giorno mer 11 dic 2019 alle ore 16:27 Jean-Baptiste Onofré < >> j...@nanthrax.net> ha scritto: >> >>> Hi, >>> >>> I know what's the problem, I think ;) >>> >>> I guess you are using Cave 4.2.0. If so, can you please update to Cave >>> 4.2.1 ? I fixed issues on the repository location. >>> >>> Regards >>> JB >>> >>> On 11/12/2019 16:07, Massimo Bono wrote: >>> > Hi JB, >>> > >>> > here's the steps: >>> > 1) I've created the repository with "cave:repository-create foo"; >>> > 2) I changed the location with "cave:repository-location foo >>> > /home/x/.m2/repository" (I don't know why, but using -l argument in >>> > "cave:repository-create" didn't change the output of >>> > "cave:repository-info foo"); >>> > 3) I've populated the maven repo with some artifacts; >>> > 4) I've called "cave:repository-update-bundle-descriptor foo" >>> > >>> >> By the way, the cave feature doesn't exist, it's just cave-repository. >>> > >>> > Sorry, my bad: I wanted to write cave-repository >>> > >>> >> Did you clean you Karaf instance (data folder) if you migrated from a >>> > previous Cave version ? >>> > >>> > No, it's a clean installation >>> > >>> > Il giorno mer 11 dic 2019 alle ore 14:18 Jean-Baptiste Onofré >>> > mailto:j...@nanthrax.net>> ha scritto: >>> > >>> > Hi, >>> > >>> > did you generate the descriptor with the command first: >>> > >>> > cave:repository-update-bundle-descriptor foo >>> > >>> > ? >>> > >>> > By the way, the cave feature doesn't exist, it's just >>> cave-repository. >>> > Did you clean you Karaf instance (data folder) if you migrated >>> from a >>> > previous Cave version ? >>> > >>> > Regards >>> > JB >>> > >>> > On 10/12/2019 15:47, Massimo Bono wrote: >>> > > Hi, >>> > > >>> > > I'm using apache cave 4.2.0 on an apache karaf instance 4.2.7. >>> > > >>> > > I've installed "cave" feature repo, and "cave-repository" >>> feature. I >>> > > then created a repository FOO and made pointing the storage to >>> maven >>> > > local repository (using "cave:repository-create >>> > > FOO"/"cave:repository-location"). >>> > > >>> > > Using "mvn" I've uploaded some artifacts in maven local >>> repository. >>> > > Then, using "cave:repository-update-bundle-descriptor FOO" I've >>> > updated >>> > > repository.xml file. >>> > > >>> > > The problem is that if I connect to >>> > > "http://IPADDRESS:8181/cave/repository/foo/repository.xml; I >>> obtain: >>> > > >>> > > XML Parsing Error: no root element found >>> > > Location: >>> > http://172.17.0.2:8181/cave/repository/fibonacci/repository.xml >>> > > Line Number 1, Column 1: >>> > > >>> > > (Note that when I first create the repository the http link >>> correctly >>> > > works, albeit it doesn't contain anything) >>> > > However, by manually inspecting repository.xml I cannot find any >>> > syntax >>> > > issues (full file is not posted since it's a huge file): >>> > > >>> > > >>> > > http://www.osgi.org/xmlns/repository/v1.0.0; >>> > > name="foo" increment="1575988990424"> >>> > > >>> > > >>> > > .. >>> > > >>> > > >>> > > >>> > > >>> > > Note that if I query the same http url with "get", I obtain a 404 >>> > error. >>> > > >>> > > Am I doing something wrong? >>> > > Thanks for any kind reply >>> > > >>> > > -- >>> > > *Ing. Massimo Bono* >>> > >>> > -- >>> > Jean-Baptiste Onofré >>> > jbono...@apache.org <mailto:jbono...@apache.org> >>> > http://blog.nanthrax.net >>> > Talend - http://www.talend.com >>> > >>> > >>> > >>> > -- >>> > *Ing. Massimo Bono* >>> >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> >> -- >> *Ing. Massimo Bono* >> > > > -- > *Ing. Massimo Bono* > -- *Ing. Massimo Bono*
Re: XML Parsing Error in Apache Cave repository.xml
Hi, now the http url works. However, I'm getting the same problem I previously described in http://karaf.922171.n3.nabble.com/Testing-a-HTTP-GET-from-WAB-td4057052.html Specifically, everytime I run "cave:repository-update-bundle-descriptor foo", new entries representing the same artifact are appended in the repository.xml file, making the file bigger and bigger. This in turn make obr:deploy fail. Is there a workaround? Il giorno mer 11 dic 2019 alle ore 17:20 Massimo Bono < massimobo...@gmail.com> ha scritto: > yes, I'm using Cave 4.2.0. Let me try 4.2.1 > > Il giorno mer 11 dic 2019 alle ore 16:27 Jean-Baptiste Onofré < > j...@nanthrax.net> ha scritto: > >> Hi, >> >> I know what's the problem, I think ;) >> >> I guess you are using Cave 4.2.0. If so, can you please update to Cave >> 4.2.1 ? I fixed issues on the repository location. >> >> Regards >> JB >> >> On 11/12/2019 16:07, Massimo Bono wrote: >> > Hi JB, >> > >> > here's the steps: >> > 1) I've created the repository with "cave:repository-create foo"; >> > 2) I changed the location with "cave:repository-location foo >> > /home/x/.m2/repository" (I don't know why, but using -l argument in >> > "cave:repository-create" didn't change the output of >> > "cave:repository-info foo"); >> > 3) I've populated the maven repo with some artifacts; >> > 4) I've called "cave:repository-update-bundle-descriptor foo" >> > >> >> By the way, the cave feature doesn't exist, it's just cave-repository. >> > >> > Sorry, my bad: I wanted to write cave-repository >> > >> >> Did you clean you Karaf instance (data folder) if you migrated from a >> > previous Cave version ? >> > >> > No, it's a clean installation >> > >> > Il giorno mer 11 dic 2019 alle ore 14:18 Jean-Baptiste Onofré >> > mailto:j...@nanthrax.net>> ha scritto: >> > >> > Hi, >> > >> > did you generate the descriptor with the command first: >> > >> > cave:repository-update-bundle-descriptor foo >> > >> > ? >> > >> > By the way, the cave feature doesn't exist, it's just >> cave-repository. >> > Did you clean you Karaf instance (data folder) if you migrated from >> a >> > previous Cave version ? >> > >> > Regards >> > JB >> > >> > On 10/12/2019 15:47, Massimo Bono wrote: >> > > Hi, >> > > >> > > I'm using apache cave 4.2.0 on an apache karaf instance 4.2.7. >> > > >> > > I've installed "cave" feature repo, and "cave-repository" >> feature. I >> > > then created a repository FOO and made pointing the storage to >> maven >> > > local repository (using "cave:repository-create >> > > FOO"/"cave:repository-location"). >> > > >> > > Using "mvn" I've uploaded some artifacts in maven local >> repository. >> > > Then, using "cave:repository-update-bundle-descriptor FOO" I've >> > updated >> > > repository.xml file. >> > > >> > > The problem is that if I connect to >> > > "http://IPADDRESS:8181/cave/repository/foo/repository.xml; I >> obtain: >> > > >> > > XML Parsing Error: no root element found >> > > Location: >> > http://172.17.0.2:8181/cave/repository/fibonacci/repository.xml >> > > Line Number 1, Column 1: >> > > >> > > (Note that when I first create the repository the http link >> correctly >> > > works, albeit it doesn't contain anything) >> > > However, by manually inspecting repository.xml I cannot find any >> > syntax >> > > issues (full file is not posted since it's a huge file): >> > > >> > > >> > > http://www.osgi.org/xmlns/repository/v1.0.0; >> > > name="foo" increment="1575988990424"> >> > > >> > > >> > > .. >> > > >> > > >> > > >> > > >> > > Note that if I query the same http url with "get", I obtain a 404 >> > error. >> > > >> > > Am I doing something wrong? >> > > Thanks for any kind reply >> > > >> > > -- >> > > *Ing. Massimo Bono* >> > >> > -- >> > Jean-Baptiste Onofré >> > jbono...@apache.org <mailto:jbono...@apache.org> >> > http://blog.nanthrax.net >> > Talend - http://www.talend.com >> > >> > >> > >> > -- >> > *Ing. Massimo Bono* >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > -- > *Ing. Massimo Bono* > -- *Ing. Massimo Bono*
Re: XML Parsing Error in Apache Cave repository.xml
yes, I'm using Cave 4.2.0. Let me try 4.2.1 Il giorno mer 11 dic 2019 alle ore 16:27 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > Hi, > > I know what's the problem, I think ;) > > I guess you are using Cave 4.2.0. If so, can you please update to Cave > 4.2.1 ? I fixed issues on the repository location. > > Regards > JB > > On 11/12/2019 16:07, Massimo Bono wrote: > > Hi JB, > > > > here's the steps: > > 1) I've created the repository with "cave:repository-create foo"; > > 2) I changed the location with "cave:repository-location foo > > /home/x/.m2/repository" (I don't know why, but using -l argument in > > "cave:repository-create" didn't change the output of > > "cave:repository-info foo"); > > 3) I've populated the maven repo with some artifacts; > > 4) I've called "cave:repository-update-bundle-descriptor foo" > > > >> By the way, the cave feature doesn't exist, it's just cave-repository. > > > > Sorry, my bad: I wanted to write cave-repository > > > >> Did you clean you Karaf instance (data folder) if you migrated from a > > previous Cave version ? > > > > No, it's a clean installation > > > > Il giorno mer 11 dic 2019 alle ore 14:18 Jean-Baptiste Onofré > > mailto:j...@nanthrax.net>> ha scritto: > > > > Hi, > > > > did you generate the descriptor with the command first: > > > > cave:repository-update-bundle-descriptor foo > > > > ? > > > > By the way, the cave feature doesn't exist, it's just > cave-repository. > > Did you clean you Karaf instance (data folder) if you migrated from a > > previous Cave version ? > > > > Regards > > JB > > > > On 10/12/2019 15:47, Massimo Bono wrote: > > > Hi, > > > > > > I'm using apache cave 4.2.0 on an apache karaf instance 4.2.7. > > > > > > I've installed "cave" feature repo, and "cave-repository" feature. > I > > > then created a repository FOO and made pointing the storage to > maven > > > local repository (using "cave:repository-create > > > FOO"/"cave:repository-location"). > > > > > > Using "mvn" I've uploaded some artifacts in maven local repository. > > > Then, using "cave:repository-update-bundle-descriptor FOO" I've > > updated > > > repository.xml file. > > > > > > The problem is that if I connect to > > > "http://IPADDRESS:8181/cave/repository/foo/repository.xml; I > obtain: > > > > > > XML Parsing Error: no root element found > > > Location: > > http://172.17.0.2:8181/cave/repository/fibonacci/repository.xml > > > Line Number 1, Column 1: > > > > > > (Note that when I first create the repository the http link > correctly > > > works, albeit it doesn't contain anything) > > > However, by manually inspecting repository.xml I cannot find any > > syntax > > > issues (full file is not posted since it's a huge file): > > > > > > > > > http://www.osgi.org/xmlns/repository/v1.0.0; > > > name="foo" increment="1575988990424"> > > > > > > > > > .. > > > > > > > > > > > > > > > Note that if I query the same http url with "get", I obtain a 404 > > error. > > > > > > Am I doing something wrong? > > > Thanks for any kind reply > > > > > > -- > > > *Ing. Massimo Bono* > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org <mailto:jbono...@apache.org> > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > > > -- > > *Ing. Massimo Bono* > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- *Ing. Massimo Bono*
Re: XML Parsing Error in Apache Cave repository.xml
Hi JB, here's the steps: 1) I've created the repository with "cave:repository-create foo"; 2) I changed the location with "cave:repository-location foo /home/x/.m2/repository" (I don't know why, but using -l argument in "cave:repository-create" didn't change the output of "cave:repository-info foo"); 3) I've populated the maven repo with some artifacts; 4) I've called "cave:repository-update-bundle-descriptor foo" > By the way, the cave feature doesn't exist, it's just cave-repository. Sorry, my bad: I wanted to write cave-repository > Did you clean you Karaf instance (data folder) if you migrated from a previous Cave version ? No, it's a clean installation Il giorno mer 11 dic 2019 alle ore 14:18 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > Hi, > > did you generate the descriptor with the command first: > > cave:repository-update-bundle-descriptor foo > > ? > > By the way, the cave feature doesn't exist, it's just cave-repository. > Did you clean you Karaf instance (data folder) if you migrated from a > previous Cave version ? > > Regards > JB > > On 10/12/2019 15:47, Massimo Bono wrote: > > Hi, > > > > I'm using apache cave 4.2.0 on an apache karaf instance 4.2.7. > > > > I've installed "cave" feature repo, and "cave-repository" feature. I > > then created a repository FOO and made pointing the storage to maven > > local repository (using "cave:repository-create > > FOO"/"cave:repository-location"). > > > > Using "mvn" I've uploaded some artifacts in maven local repository. > > Then, using "cave:repository-update-bundle-descriptor FOO" I've updated > > repository.xml file. > > > > The problem is that if I connect to > > "http://IPADDRESS:8181/cave/repository/foo/repository.xml; I obtain: > > > > XML Parsing Error: no root element found > > Location: > http://172.17.0.2:8181/cave/repository/fibonacci/repository.xml > > Line Number 1, Column 1: > > > > (Note that when I first create the repository the http link correctly > > works, albeit it doesn't contain anything) > > However, by manually inspecting repository.xml I cannot find any syntax > > issues (full file is not posted since it's a huge file): > > > > > > http://www.osgi.org/xmlns/repository/v1.0.0; > > name="foo" increment="1575988990424"> > > > > > > .. > > > > > > > > > > Note that if I query the same http url with "get", I obtain a 404 error. > > > > Am I doing something wrong? > > Thanks for any kind reply > > > > -- > > *Ing. Massimo Bono* > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- *Ing. Massimo Bono*
XML Parsing Error in Apache Cave repository.xml
Hi, I'm using apache cave 4.2.0 on an apache karaf instance 4.2.7. I've installed "cave" feature repo, and "cave-repository" feature. I then created a repository FOO and made pointing the storage to maven local repository (using "cave:repository-create FOO"/"cave:repository-location"). Using "mvn" I've uploaded some artifacts in maven local repository. Then, using "cave:repository-update-bundle-descriptor FOO" I've updated repository.xml file. The problem is that if I connect to " http://IPADDRESS:8181/cave/repository/foo/repository.xml; I obtain: XML Parsing Error: no root element found Location: http://172.17.0.2:8181/cave/repository/fibonacci/repository.xml Line Number 1, Column 1: (Note that when I first create the repository the http link correctly works, albeit it doesn't contain anything) However, by manually inspecting repository.xml I cannot find any syntax issues (full file is not posted since it's a huge file): http://www.osgi.org/xmlns/repository/v1.0.0; name="foo" increment="1575988990424"> .. Note that if I query the same http url with "get", I obtain a 404 error. Am I doing something wrong? Thanks for any kind reply -- *Ing. Massimo Bono*
Re: Testing a HTTP GET from WAB
just tried with web:list and http:list: the output seems fine but when i
try to actually connect, I'm still experiencing Connection Refused.
http:list
> ID │ Servlet │ Servlet-Name │ State │ Alias │
> Url
>
> ┼───┼──┼─┼─┼─
> 140 │ ResourceServlet │ default │ Deployed│ /hello-example/ │
> [/hello-example/]
> 140 │ JspServletWrapper │ jsp │ Deployed│ │
> [/hello-example/*.jsp, /hello-example/*.jspx, /hello-example/*.jspf,
> /hello-example/*.xsp, /hello-example/*.JSP, /hello-example/*.JSPX,
> /hello-example/*.JSPF, /hello-example/*.XSP]
>
web:list
> ID │ State │ Web-State │ Level │ Web-ContextPath │ Name
> ┼─┼─┼───┼─┼
> 140 │ Active │ Deployed│ 81│ /hello-example │ task-ui (0.0.1)
I followed the example shown in
https://github.com/apache/karaf/blob/master/itests/test/src/test/java/org/apache/karaf/itests/WebTest.java:
to test, you call the command "feature:install war" and "web:install"
directly with executeCommand. Then I realized that the port open was not
8181 (as I was lead to believe from the WAR Deployer manual) but 9080 (Set
from KarafTestSupport HTTP_PORT!). By using this.getHttpPort() method I was
able to make it work!
Some code:
this.installAndAssertFeature("war");
stdout = this.executeCommand("web:install
mvn:com.fibonacci.microsi/task-ui/0.0.1/jar hello-example");
System.out.println(stdout);
stdout = this.executeCommand("web:list", 5000L, false);
System.out.println(stdout);
this.installAndAssertFeature("war");
this.assertBundleInstalled("task-ui");
URL url = new URL("http://localhost:; + this.getHttpPort() +
"/hello-example");
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setDoInput(true);
connection.setRequestMethod("GET");
StringBuilder buffer = new StringBuilder();
try (BufferedReader reader = new BufferedReader(new
InputStreamReader(connection.getInputStream( {
String line = null;
while ((line = reader.readLine()) != null) {
buffer.append(line).append("\n");
}
}
System.out.println(buffer.toString());
Thanks for pointing to the right direction!
Il giorno sab 16 nov 2019 alle ore 11:08 ha scritto:
> Hi
>
> In the test, you can check with web:list and http:list if the status is
> deployed (and not deploying).
> Maybe you test the connection before the endpoint is actually started.
> You can see how we do it in the karaf examples itests.
>
> Regards
> JB
>
> Le 16 nov. 2019 11:01, Massimo Bono a écrit :
>
> Hi,
>
> I've generated a wab file containing a simple "hello world" index.html.
> Inside this wab there is the standard manifest with the WebContext-Path
> manifest entry.
>
> When I manually start a karaf container, everything goes smoothly: I
> install the war feature (by using "feature:install war") and then I can
> successfully view the Webapp on a browser (http:/
> 127.0.0.1:8181/hello-example).
>
> However, things go south when I try to test automatically the webapp.
> I've created a simple test (by extension KaratTestSupport) where I
> install the "war" feature using KarafDistributionOption.features and then
> start the webapp bundle (via CoreOptions.mavenBundle()). I'm using
> httpcomponents.httpclient
> (with a OSGi compliant manifest header) to request the HTTP GET
> connection; however, albeit http:list show the endpoint, I always obtain
> a "ConnectionRefused" (in the browser I cannot see anything as well).
>
> Surely I'm doing something wrong. Is this the correct way to test a webapp?
>
> Thanks for any kind reply!
>
> --
> *Ing. Massimo Bono*
>
>
>
--
*Ing. Massimo Bono*
Testing a HTTP GET from WAB
Hi, I've generated a wab file containing a simple "hello world" index.html. Inside this wab there is the standard manifest with the WebContext-Path manifest entry. When I manually start a karaf container, everything goes smoothly: I install the war feature (by using "feature:install war") and then I can successfully view the Webapp on a browser (http:/ 127.0.0.1:8181/hello-example). However, things go south when I try to test automatically the webapp. I've created a simple test (by extension KaratTestSupport) where I install the "war" feature using KarafDistributionOption.features and then start the webapp bundle (via CoreOptions.mavenBundle()). I'm using httpcomponents.httpclient (with a OSGi compliant manifest header) to request the HTTP GET connection; however, albeit http:list show the endpoint, I always obtain a " ConnectionRefused" (in the browser I cannot see anything as well). Surely I'm doing something wrong. Is this the correct way to test a webapp? Thanks for any kind reply! -- *Ing. Massimo Bono*
Re: Bug on cave:repository-update?
Oh perfect! I'll wait for cave next release then. Thank you very much Il giorno ven 18 ott 2019 alle ore 06:14 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > Hi Massimo, > > I would recommend to wait Cave 4.2.0 where Cave has completely changed > with a full refactoring: > > https://github.com/apache/karaf-cave/pull/27 > > I plan to merge the PR later today and cut Cave 4.2.0 soon (probably > during the weekend). > > Cave will be simpler, first Maven focus, and the repository.xml > generation will only use local artifacts. > > Regards > JB > > On 17/10/2019 23:04, Massimo Bono wrote: > > Hi, > > > > I was tweaking with apache:cave and i stumble across an interesting > > behavior. > > > > 1) I've created a repository and populate it with some artifacts (via > > cave:repository-create -l); > > 2) I then created new artifacts and I have manually copied them within > > the repository. > > 3) I then run cave:repository-update to refresh the > > repository.xml file > > > > To my surprise, lots of resources have been duplicated: while before the > > "repository-update" the resources were accessible through one http URI, > > after the update the resources were accessible through one http URI and > > via one file URI. > > If I try to deploy a bundle with multiple URI within the repository.xml > > the obr:deploy command does not deploy anything. If I try to access to > > the bundle via web browser with the http URI I obtain Error 500 Resource > > not found. > > > > I found a workaround to this "interesting feature" as well: > > > > 1) Open the repository associated file repository.xml and annotate the > > attributes of "repository" tag; > > 2) Delete the repository.xml file; > > 3) Create the file again; > > 4) Add in such file the string " > increment="INCREMENT">" where "REPOSITORY_NAME" and > > "INCREMENT" are the values you have look at in the first step; > > 5) run cave:repository-update REPOSITORY_NAME > > > > Everything should run smoothly now. > > > > Now, maybe it's feature, I don't know, but I think it's not obvious that > > cave:repository-update can lead to duplicate entries in the > > repository.xml file. > > > > Another note while I was digging into this behaviour: I found that the > > "repository-update" command hides a call of CaveReposiitory.scan(): here > > the javadoc of this interface method is, at least in my opinion, wrong: > > it says: "Scan the whole repository, reading bundle MANIFEST, ect to > > update *or generate* the repository.xml"(enphasis mine). > > However, cave:repository-update will fail if the file is deleted from > > the filesystem, hence the workaround. > > > > Finally, my setup: > > > > OBR SERVER: > > Operating system: Raspian buster 10 > > Apache karaf hosting cave: 4.2.6 > > Apache cave: 4.1.2 > > > > OBR CLIENT: > > Apache karaf where bundles will be deployed: 4.2.6 > > Operating system: Ubuntu 18.04 > > > > Best Regards, > > > > -- > > *Ing. Massimo Bono* > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- *Ing. Massimo Bono*
Bug on cave:repository-update?
Hi, I was tweaking with apache:cave and i stumble across an interesting behavior. 1) I've created a repository and populate it with some artifacts (via cave:repository-create -l); 2) I then created new artifacts and I have manually copied them within the repository. 3) I then run cave:repository-update to refresh the repository.xml file To my surprise, lots of resources have been duplicated: while before the "repository-update" the resources were accessible through one http URI, after the update the resources were accessible through one http URI and via one file URI. If I try to deploy a bundle with multiple URI within the repository.xml the obr:deploy command does not deploy anything. If I try to access to the bundle via web browser with the http URI I obtain Error 500 Resource not found. I found a workaround to this "interesting feature" as well: 1) Open the repository associated file repository.xml and annotate the attributes of "repository" tag; 2) Delete the repository.xml file; 3) Create the file again; 4) Add in such file the string "" where "REPOSITORY_NAME" and "INCREMENT" are the values you have look at in the first step; 5) run cave:repository-update REPOSITORY_NAME Everything should run smoothly now. Now, maybe it's feature, I don't know, but I think it's not obvious that cave:repository-update can lead to duplicate entries in the repository.xml file. Another note while I was digging into this behaviour: I found that the "repository-update" command hides a call of CaveReposiitory.scan(): here the javadoc of this interface method is, at least in my opinion, wrong: it says: "Scan the whole repository, reading bundle MANIFEST, ect to update *or generate* the repository.xml" (enphasis mine). However, cave:repository-update will fail if the file is deleted from the filesystem, hence the workaround. Finally, my setup: OBR SERVER: Operating system: Raspian buster 10 Apache karaf hosting cave: 4.2.6 Apache cave: 4.1.2 OBR CLIENT: Apache karaf where bundles will be deployed: 4.2.6 Operating system: Ubuntu 18.04 Best Regards, -- *Ing. Massimo Bono*
Re: Karaf Cave obr:add-url
Hi Jean-Baptiste, Thanks for the reply. The first question is: do you really need OBR ? Is feature with mvn url > not convenient for you (or even resources repositories) ? > I know there are other provisioning solutions (i.e., features) but at the moment I want to experiment with OBR a bit. I've chosen Cave since it felt a natural choice. Back to your question, if you install the cave generic feature it > installs http support. So if you create a cave repository and you > populate (or proxy) then you can access on > http:///cave/repositories/good > This solve my first and part of the second question. However it still uncertain to me if adding a custom port is still valid. For example, can I use the following HTTP url? http://192.168.0.42:9000/cave/repositories/good Do I need to change some Apache Cave default configurations? (192.168.0.42 is the IP of the server apache cave is located. 9000 is just a custom port) I also have another question: Where should I put the OBR Http URL on the Karaf client in order for "obr:deploy" to automatically connect to apache cave? Inside a configuration file? If so, which one? Thanks for the attention Il giorno lun 16 set 2019 alle ore 10:18 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > Hi Massimo > > It seems my previous e-mail didn't reach the mailing list. > > Here's my answer: > > The first question is: do you really need OBR ? Is feature with mvn url > not convenient for you (or even resources repositories) ? > > Back to your question, if you install the cave generic feature it > installs http support. So if you create a cave repository and you > populate (or proxy) then you can access on > http:///cave/repositories/good > > It's where you will have the repository.xml with the metadata. > > Regards > JB > > Le 9 sept. 2019 14:07, Massimo Bono a écrit : > > Hi all, > > I've successfully setup in a local Docker container an instance of > karaf cave with an OBR repository and I have populate it with some > bundles. > > Now I would like to use "obr" feature to deploy such bundles on > another client karaf instance. > However, I'm unsure about what URL I need to put in the command > "obr:add-url": > > - do I need to open a particular port in order for OBR to work (e.g. > port 80)? > - should is use protocol HTTP? If so, does karaf support the url > notation "http:/domain-name:/resource"? > - where should I put this url? directly in obr:add-url? Inside a > configuration file? I think it would be better inside a > configuration file, but I'm unsure about which one. > > Sorry for the newbie question and thank for any kind reply. > > -- *Ing. Massimo Bono* > > > -- *Ing. Massimo Bono*
Re: Karaf Cave obr:add-url
Hi all, Do you any update regarding this question? Thanks Il giorno lun 9 set 2019 alle ore 23:07 Massimo Bono ha scritto: > Hi all, > > I've successfully setup in a local Docker container an instance of karaf > cave with an OBR repository and I have populate it with some bundles. > > Now I would like to use "obr" feature to deploy such bundles on another > client karaf instance. > However, I'm unsure about what URL I need to put in the command > "obr:add-url": > > - do I need to open a particular port in order for OBR to work (e.g. port > 80)? > - should is use protocol HTTP? If so, does karaf support the url notation > "http:/domain-name:/resource"? > - where should I put this url? directly in obr:add-url? Inside a > configuration file? I think it would be better inside a configuration file, > but I'm unsure about which one. > > Sorry for the newbie question and thank for any kind reply. > > -- > *Ing. Massimo Bono* > -- *Ing. Massimo Bono*
Karaf Cave obr:add-url
Hi all, I've successfully setup in a local Docker container an instance of karaf cave with an OBR repository and I have populate it with some bundles. Now I would like to use "obr" feature to deploy such bundles on another client karaf instance. However, I'm unsure about what URL I need to put in the command "obr:add-url": - do I need to open a particular port in order for OBR to work (e.g. port 80)? - should is use protocol HTTP? If so, does karaf support the url notation "http:/domain-name:/resource"? - where should I put this url? directly in obr:add-url? Inside a configuration file? I think it would be better inside a configuration file, but I'm unsure about which one. Sorry for the newbie question and thank for any kind reply. -- *Ing. Massimo Bono*
Re: Pax Exam + Karaf + Conditional Packages
Ok,
I've solve my issue (using a really naive solution). With maven I've
created a bundle out of all the classes which were in the
conditional-package BND instruction. Then I've simply added the newly
created bundle within the @Configuration Pax-Exam method.
Maybe it's not the best solution, but works.
Il giorno mar 20 nov 2018 alle ore 11:34 Massimo Bono <
massimobo...@gmail.com> ha scritto:
> Hello,
>
> I want to test an OSGi bundle built with bnd using conditional-packages
> via pax-exam. The conditional-package allows the bundle to use some utility
> classes (e.g., like from https://stackoverflow.com/a/39500621/1887602)
>
> The test is setup like the following:
>
> @Test
> public void exampleTest() {
> UtilityClass.foo(this.wiredService)
> }
>
> where:
> - wiredService is a service which has been injected via @javax.Inject;
> - UtilityClass is the class which has been bundled in the jar with the
> conditional-package.
>
> The test container I'm using is Karaf.
>
> When testing the application, Osgi alerts me that it cannot find the class
> "x.y.z.UtilityClass".
>
> So my question is: how can I retrieve conditional-package classes using
> pax-exam?
>
> Here's the (anonymized) stack trace:
>
> java.lang.ClassNotFoundException: x.y.z.UtilityClass not found by
>> PAXEXAM-PROBE-1ac529cd-015d-4378-a3fa-f4cef4789ef8 [75]
>> at
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
>> at
>> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
>> at
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>> at x.y.z.TestOsgiCommon.test00(TestOsgiCommon.java:271)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>> at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>> at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>> at
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>> at
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>> at
>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>> at
>> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runLeafWithRetry(ContainerTestRunner.java:97)
>> at
>> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChildWithRetry(ContainerTestRunner.java:84)
>> at
>> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:75)
>> at
>> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:43)
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>> at
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>> at
>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
>> at
>> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
>> at
>> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
>> at
>> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at
>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:85)
>>
Pax Exam + Karaf + Conditional Packages
Hello,
I want to test an OSGi bundle built with bnd using conditional-packages via
pax-exam. The conditional-package allows the bundle to use some utility
classes (e.g., like from https://stackoverflow.com/a/39500621/1887602)
The test is setup like the following:
@Test
public void exampleTest() {
UtilityClass.foo(this.wiredService)
}
where:
- wiredService is a service which has been injected via @javax.Inject;
- UtilityClass is the class which has been bundled in the jar with the
conditional-package.
The test container I'm using is Karaf.
When testing the application, Osgi alerts me that it cannot find the class
"x.y.z.UtilityClass".
So my question is: how can I retrieve conditional-package classes using
pax-exam?
Here's the (anonymized) stack trace:
java.lang.ClassNotFoundException: x.y.z.UtilityClass not found by
> PAXEXAM-PROBE-1ac529cd-015d-4378-a3fa-f4cef4789ef8 [75]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1639)
> at
> org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at x.y.z.TestOsgiCommon.test00(TestOsgiCommon.java:271)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runLeafWithRetry(ContainerTestRunner.java:97)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChildWithRetry(ContainerTestRunner.java:84)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:75)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:43)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:85)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
>
Re: Conditional-Package
Hello Stephen, I investigated that bnd entry too. For me the following 2 resources were really helpful: - http://njbartlett.name/2014/05/26/static-linking.html; - https://stackoverflow.com/questions/39494328/how-useful-is-to-create-an-osgi-utility-bundle ; Maybe there might be useful for you too. As for "here an example of how to use them in maven-bundle plugin, it's the same as in bnd: you need to add "Conditional-Package" entry in the configuration and add whatever pacakge you want to statically include in the bundle. As Bartlett specified in one of the 2 resoruces I've linked you, Conditional-Pacakge is useful for when "the implementation is the contract of your bundle" (e.g. utility classes). 2017-12-10 12:18 GMT+01:00 smunro <stephen.ross.mu...@gmail.com>: > Hello Peter, > > Thanks for the quick reply. I came across this page indirectly that > commented on the instruction, but I only noticed the header section. > > I tinkered with this locally and it seems to work as expected. I am still > very curious why conditional-package isn't covered as well as all the other > plugin instructions. Perhaps , as you say, its an isolated incident where > it > simply didn't have enough TLC, but at the same time It made be question how > useful the instruction was. > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > -- *Ing. Massimo Bono*
Re: Karaf maven plugin features-generate-descriptor questions
Hello, So I need to intend such goal as a simple customizer of a given template? I have been mislead by the name of the goal: I thought it could generate general feature.xml from scratch. Thanks for the clarification 2017-11-13 9:56 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi Massimo, > > 1. You can see the Maven plugin as a "substituter" for features repository > XML templates. So, you can start with a XML template and replace dependency > version or extend with this template based on the pom.xml. You don't have > to use it, you can use a finalized XML directly. > 2. It's related to the features XML generated: if the inner feature > contains the prerequesite=true and dependency=true flags. > > Regards > JB > > On 11/13/2017 09:50 AM, Massimo Bono wrote: > >> Hello, >> >> I've several questions about Karaf Maven Plugin, >> features-generate-descriptor goal; I hope you don't mind if I've put all of >> them in a single thread. >> >> 1) I wonder why you couldn't declare feature dependencies inside the >> pom.xml. I know you need to declare them in a inputFile xml template (as I >> discovered both in http://karaf.922171.n3.nabble. >> com/Getting-the-plugin-to-generate-feature-dependencies-td4043053.html >> and in https://stackoverflow.com/questions/29645553/karaf-maven- >> plugin-defining-a-dependency-as-a-feature). However, I still don't grasp >> what is the underlying reason not to have them declared in the pom. I've >> looked at the code of the goal (on https://github.com/apache/kara >> f/blob/master/tooling/karaf-maven-plugin/src/main/java/ >> org/apache/karaf/tooling/features/GenerateDescriptorMojo.java ) but I >> didn't fully understand the decision (probably because it's the first time >> I've looked into a Mojo). Why can't we have a "dependentFeature" tag? >> 2) Related to the first question: what is the purpose of >> "prerequisiteFeatures" and "dependencyFeatures" parameters? >> >> Thanks for any kind reply! >> >> -- >> *Ing. Massimo Bono* >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- *Ing. Massimo Bono*
General question about feature cxf and http/war
Hello, In this question *my objective is to understand the difference between cxf, feature http and feature war*. I'm exploring ways to deploy on Karaf RESTful services and angular scripts (in the future I will probably need to add javascripts fand css files, but for the moment angular files are just fine). Right now I deployed RESTful services via DOSGI while I successfully deployed a WAB archive by following the links [1] and [2]. All works but it left me with a question: I thought Apache CXF as a service dispatcher which could deploy war files as well. Instead I need to use "http" feature (I guess to install a real werb server) and a "war" feature (I guess to install WAR and WAB via the command "bundle:install"). So, my question is: 1) In what regard "feature:install cxf", "feature:install http" and "feature:install war" differ? (A simple link to the correct and latest documentation is enough); can they conflict in some way (do their objective overlaps in some way?) 2) Can I install other web servers on Karaf (ie. Tomcat)? If so, is there some updated documentation in this regard? Sorry for this wide question and thanks for any kind reply [1] https://stackoverflow.com/questions/24640515/how-deploy-a-war-web-project-in-karaf-3 [2] https://karaf.apache.org/manual/latest/webcontainer -- *Ing. Massimo Bono*
Karaf maven plugin features-generate-descriptor questions
Hello, I've several questions about Karaf Maven Plugin, features-generate-descriptor goal; I hope you don't mind if I've put all of them in a single thread. 1) I wonder why you couldn't declare feature dependencies inside the pom.xml. I know you need to declare them in a inputFile xml template (as I discovered both in http://karaf.922171.n3.nabble.com/Getting-the-plugin-to-generate-feature-dependencies-td4043053.html and in https://stackoverflow.com/questions/29645553/karaf-maven-plugin-defining-a-dependency-as-a-feature). However, I still don't grasp what is the underlying reason not to have them declared in the pom. I've looked at the code of the goal (on https://github.com/apache/karaf/blob/master/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/features/GenerateDescriptorMojo.java ) but I didn't fully understand the decision (probably because it's the first time I've looked into a Mojo). Why can't we have a "dependentFeature" tag? 2) Related to the first question: what is the purpose of " prerequisiteFeatures" and "dependencyFeatures" parameters? Thanks for any kind reply! -- *Ing. Massimo Bono*
Re: General question about DOSGi
Ok, now my doubt has been cleared out. Thank you! 2017-10-24 12:09 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Correct. > > Regards > JB > > On 10/24/2017 11:19 AM, Massimo Bono wrote: > >> In that case the user wouldn't interact with the browser, but with a >> client embedded inside the OSGi application itself, correct? >> >> 2017-10-24 9:44 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net > j...@nanthrax.net>>: >> >> Or a remote instance can "ship" a client interacting with a remote >> REST >> service exposed from an OSGi service. >> >> Regards >> JB >> >> On 10/24/2017 09:24 AM, Massimo Bono wrote: >> >> So, it's like saying: >> >> We know DOSGI implements RPC with REST-ful services, so we >> exploit that >> in order to create some rest webservices. Then, instead of query >> them >> from another OSGi container, we directly query them from the >> browser. >> >> Is my understanding correct? >> >> 2017-10-24 6:29 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net >> <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net > j...@nanthrax.net>>>: >> >> >> 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 >> <https://github.com/apache/cxf-dosgi/tree/master/samples/rest> >> <https://github.com/apache/cxf >> -dosgi/tree/master/samples/rest >> <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 >> <http://cxf.apache.org/distributed-osgi-reference.html> >> <http://cxf.apache.org/distributed-osgi-reference.html >> <http://cxf.apache.org/distributed-osgi-reference.html>>; >> 2) https://github.com/apache/cxf-dosgi >> <https://github.com/apache/cxf-dosgi> >>
Re: General question about DOSGi
In that case the user wouldn't interact with the browser, but with a client embedded inside the OSGi application itself, correct? 2017-10-24 9:44 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Or a remote instance can "ship" a client interacting with a remote REST > service exposed from an OSGi service. > > Regards > JB > > On 10/24/2017 09:24 AM, Massimo Bono wrote: > >> So, it's like saying: >> >> We know DOSGI implements RPC with REST-ful services, so we exploit that >> in order to create some rest webservices. Then, instead of query them from >> another OSGi container, we directly query them from the browser. >> >> Is my understanding correct? >> >> 2017-10-24 6:29 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net > j...@nanthrax.net>>: >> >> 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 >> <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 >> <http://cxf.apache.org/distributed-osgi-reference.html>; >> 2) https://github.com/apache/cxf-dosgi >> <https://github.com/apache/cxf-dosgi>; >> http://www.liquid-reality.de/display/liquid/2013/02/13/Apach >> e+Karaf+Tutorial+Part+8+-+Distributed+OSGi >> <http://www.liquid-reality.de/display/liquid/2013/02/13/Apac >> he+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 <mailto:jbono...@apache.org> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> >> -- >> *Ing. Massimo Bono* >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- *Ing. Massimo Bono*
Re: General question about DOSGi
So, it's like saying: We know DOSGI implements RPC with REST-ful services, so we exploit that in order to create some rest webservices. Then, instead of query them from another OSGi container, we directly query them from the browser. Is my understanding correct? 2017-10-24 6:29 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > 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/Apach >> e+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 > -- *Ing. Massimo Bono*
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*
