You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by "Leschke, Scott" <SL...@medline.com> on 2018/11/27 19:27:32 UTC
Aries
I was wondering if there is a possibility that the Aries project would provide OSGi Feature Subsystems for each of the OSGi services they've implemented (with the exception of the subsystem spec of course). There is a Karaf Feature for installing the Subsystem service so it would be nice if the remaining services were available as Feature Subsystems (or Karaf Features I guess but the former seems like a more neutral solution).
Scott
Re: Aries
Posted by Ryan Moquin <fr...@gmail.com>.
I was always wondering how to use a resource repository with Karaf.. I want
to be able to leverage requirements and capabilities.. I haven't really
quite figured out how to leverage them properly yet.. figuring that out is
on my to do list though :)
Ryan
On Wed, Nov 28, 2018, 1:23 AM Jean-Baptiste Onofré <jb@nanthrax.net wrote:
> Hi,
>
> I think it's related to the mail I sent last week: better and dynamic
> usage of resource repository with features resolver. It's what we
> discussed with Christian.
>
> Clearly today, Karaf features provide unique functionalities and
> description, not covered by other repository (like subsystem or resource
> repository), I'm thinking about configuration, features flags, inner
> features, etc.
>
> However, it would make sense to start Karaf with a minimal features set
> and then leverage resources repositories at runtime, dynamically.
>
> The first step I proposed is basically to add commands to manipulate the
> resources repository at runtime and add resource repository element in
> features repositories.
> Today, it's already possible to use resources repositories, defining it
> (in XML or JSON) in etc/org.apache.karaf.features.cfg. This
> configuration is evaluated when the features service starts and used by
> the features resolver.
> The propose is:
> 1. add resource:repo-add and other commands to add/remove resource
> repositories at runtime and then perform a new evaluation of the
> resolution.
> 2. add <resource/> element in features repo (as we have <repository/>)
> allowing to define "open" features and relay on resources repository.
>
> So, to be clear, I don't want to change the current features service
> which, again, provide unique features, and it's the minimal layer to
> start a karaf runtime. My proposal is to extend & improve the features
> service to better leverage the resources repositories. The user then can
> focus only on a resource repository and won't be "forced" to use a
> features repository.
>
> Regards
> JB
>
> On 28/11/2018 06:38, Christian Schneider wrote:
> > I understand that you are seeking a more standard way than karaf
> > features to deploy parts of an application. Indeed subsystems look like
> > a good way at first. Unfortunately they add a lot of complexity to a
> > system. So almost no one uses them.
> >
> > Currently there are two major ways of packaging an application:
> > - karaf features (uses repository + + requirements under the covers). A
> > feature repo is described in xml. The bundles from all the required
> > features form the repository. The bundles with dependency=false form the
> > requirements.
> > - repository + requirements based approach like used by bnd (without
> > features). They currently use a pom file to describe a repository +
> > requirements in a bndrun file.
> >
> > So I agree it would be great to have a more standard way to package
> > applications. I discussed with JB that we could make more explicit use
> > of repositories for karaf features. The idea is to describe karaf
> > features using a backing repository + required bundles for each feature.
> > We could describe the repository for the feature in a pom and refer to
> > it in the feature repo file. The features would then only contain the
> > required bundles.
> >
> > This approach would provide a repository in pom form for all karaf
> > features that is then also usable by bnd for packaging. So projects like
> > aries would only need to provide one common form of feature description.
> >
> > Besides this there is a standardisation effort at the OSGi alliance for
> > features. Currently the work in progress there looks more like karaf 2
> > featues, so it is not usable for karaf but maybe in the next iteraion a
> > repository based approach is considered.
> >
> > Chritian
> >
> >
> > Am Di., 27. Nov. 2018 um 21:56 Uhr schrieb Leschke, Scott
> > <SLeschke@medline.com <ma...@medline.com>>:
> >
> > It wasn’t really a dev request per se, more of a curiosity question
> > as to whether something along those lines was being considered as it
> > would seem to make the implementations more easily consumable in a
> > variety of OSGi environments. My primary interest is in Karaf which
> > is why I guess I targeted this list. Perhaps I should have thought
> > that through better.____
> >
> > __ __
> >
> > As for how something like that were structured, I don’t know
> > really. I only have passing familiarity with the Subsystem spec and
> > that it sort of overlaps and extends what Karaf Features do, at
> > least to my knowledge. My take is that a Karaf Feature commonly maps
> > to an OSGi service spec. implementation, even if the names don’t
> > match exactly____
> >
> > __ __
> >
> > I readily admit that I could be grossly mistaken on that.____
> >
> > __ __
> >
> > Scott____
> >
> > __ __
> >
> > *From:* David Jencks <david.a.jencks@gmail.com
> > <ma...@gmail.com>>
> > *Sent:* Tuesday, November 27, 2018 2:08 PM
> > *To:* user@karaf.apache.org <ma...@karaf.apache.org>
> > *Subject:* Re: Aries____
> >
> > __ __
> >
> > I’m somewhat curious how you decided on this karaf list for a Dev
> > request for Aries.____
> >
> > I’m more curious how a feature subsystem would help deploying an
> > aries osgi service implementation. I haven’t looked for several
> > years at how Aries sub projects divide up their artifact
> > functionality, but I’d hope that all the spec functionality, and
> > api, would be from a single bundle, with, possibly additional
> > bundles for extensions. If this is how a project is structured, how
> > does a feature subsystem make deployment easier? If not, would it
> > make more sense to adopt such a structure than to imitate it with a
> > feature subsystem?____
> >
> > Thanks____
> >
> > David Jencks ____
> >
> > Sent from my iPhone____
> >
> >
> > On Nov 27, 2018, at 11:27 AM, Leschke, Scott <SLeschke@medline.com
> > <ma...@medline.com>> wrote:____
> >
> > I was wondering if there is a possibility that the Aries project
> > would provide OSGi Feature Subsystems for each of the OSGi
> > services they’ve implemented (with the exception of the
> > subsystem spec of course). There is a Karaf Feature for
> > installing the Subsystem service so it would be nice if the
> > remaining services were available as Feature Subsystems (or
> > Karaf Features I guess but the former seems like a more neutral
> > solution).____
> >
> > ____
> >
> > Scott____
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
RE: Aries
Posted by "Leschke, Scott" <SL...@medline.com>.
So, the implication seems to be that the Subsystem spec is effectively broken and not worth pursuing. It sounds as if it's simultaneously too complicated and yet not complicated enough. Note that I'm not saying that's the case but that's what I take from what's written below and it's apparent lack of uptake.
Scott
-----Original Message-----
From: Jean-Baptiste Onofré <jb...@nanthrax.net>
Sent: Wednesday, November 28, 2018 12:23 AM
To: user@karaf.apache.org
Subject: Re: Aries
Hi,
I think it's related to the mail I sent last week: better and dynamic usage of resource repository with features resolver. It's what we discussed with Christian.
Clearly today, Karaf features provide unique functionalities and description, not covered by other repository (like subsystem or resource repository), I'm thinking about configuration, features flags, inner features, etc.
However, it would make sense to start Karaf with a minimal features set and then leverage resources repositories at runtime, dynamically.
The first step I proposed is basically to add commands to manipulate the resources repository at runtime and add resource repository element in features repositories.
Today, it's already possible to use resources repositories, defining it (in XML or JSON) in etc/org.apache.karaf.features.cfg. This configuration is evaluated when the features service starts and used by the features resolver.
The propose is:
1. add resource:repo-add and other commands to add/remove resource repositories at runtime and then perform a new evaluation of the resolution.
2. add <resource/> element in features repo (as we have <repository/>) allowing to define "open" features and relay on resources repository.
So, to be clear, I don't want to change the current features service which, again, provide unique features, and it's the minimal layer to start a karaf runtime. My proposal is to extend & improve the features service to better leverage the resources repositories. The user then can focus only on a resource repository and won't be "forced" to use a features repository.
Regards
JB
On 28/11/2018 06:38, Christian Schneider wrote:
> I understand that you are seeking a more standard way than karaf
> features to deploy parts of an application. Indeed subsystems look
> like a good way at first. Unfortunately they add a lot of complexity
> to a system. So almost no one uses them.
>
> Currently there are two major ways of packaging an application:
> - karaf features (uses repository + + requirements under the covers).
> A feature repo is described in xml. The bundles from all the required
> features form the repository. The bundles with dependency=false form
> the requirements.
> - repository + requirements based approach like used by bnd (without
> features). They currently use a pom file to describe a repository +
> requirements in a bndrun file.
>
> So I agree it would be great to have a more standard way to package
> applications. I discussed with JB that we could make more explicit
> use of repositories for karaf features. The idea is to describe karaf
> features using a backing repository + required bundles for each feature.
> We could describe the repository for the feature in a pom and refer to
> it in the feature repo file. The features would then only contain the
> required bundles.
>
> This approach would provide a repository in pom form for all karaf
> features that is then also usable by bnd for packaging. So projects
> like aries would only need to provide one common form of feature description.
>
> Besides this there is a standardisation effort at the OSGi alliance
> for features. Currently the work in progress there looks more like
> karaf 2 featues, so it is not usable for karaf but maybe in the next
> iteraion a repository based approach is considered.
>
> Chritian
>
>
> Am Di., 27. Nov. 2018 um 21:56 Uhr schrieb Leschke, Scott
> <SLeschke@medline.com <ma...@medline.com>>:
>
> It wasn’t really a dev request per se, more of a curiosity question
> as to whether something along those lines was being considered as it
> would seem to make the implementations more easily consumable in a
> variety of OSGi environments. My primary interest is in Karaf which
> is why I guess I targeted this list. Perhaps I should have thought
> that through better.____
>
> __ __
>
> As for how something like that were structured, I don’t know
> really. I only have passing familiarity with the Subsystem spec and
> that it sort of overlaps and extends what Karaf Features do, at
> least to my knowledge. My take is that a Karaf Feature commonly maps
> to an OSGi service spec. implementation, even if the names don’t
> match exactly____
>
> __ __
>
> I readily admit that I could be grossly mistaken on that.____
>
> __ __
>
> Scott____
>
> __ __
>
> *From:* David Jencks <david.a.jencks@gmail.com
> <ma...@gmail.com>>
> *Sent:* Tuesday, November 27, 2018 2:08 PM
> *To:* user@karaf.apache.org <ma...@karaf.apache.org>
> *Subject:* Re: Aries____
>
> __ __
>
> I’m somewhat curious how you decided on this karaf list for a Dev
> request for Aries.____
>
> I’m more curious how a feature subsystem would help deploying an
> aries osgi service implementation. I haven’t looked for several
> years at how Aries sub projects divide up their artifact
> functionality, but I’d hope that all the spec functionality, and
> api, would be from a single bundle, with, possibly additional
> bundles for extensions. If this is how a project is structured, how
> does a feature subsystem make deployment easier? If not, would it
> make more sense to adopt such a structure than to imitate it with a
> feature subsystem?____
>
> Thanks____
>
> David Jencks ____
>
> Sent from my iPhone____
>
>
> On Nov 27, 2018, at 11:27 AM, Leschke, Scott <SLeschke@medline.com
> <ma...@medline.com>> wrote:____
>
> I was wondering if there is a possibility that the Aries project
> would provide OSGi Feature Subsystems for each of the OSGi
> services they’ve implemented (with the exception of the
> subsystem spec of course). There is a Karaf Feature for
> installing the Subsystem service so it would be nice if the
> remaining services were available as Feature Subsystems (or
> Karaf Features I guess but the former seems like a more neutral
> solution).____
>
> ____
>
> Scott____
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Aries
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I think it's related to the mail I sent last week: better and dynamic
usage of resource repository with features resolver. It's what we
discussed with Christian.
Clearly today, Karaf features provide unique functionalities and
description, not covered by other repository (like subsystem or resource
repository), I'm thinking about configuration, features flags, inner
features, etc.
However, it would make sense to start Karaf with a minimal features set
and then leverage resources repositories at runtime, dynamically.
The first step I proposed is basically to add commands to manipulate the
resources repository at runtime and add resource repository element in
features repositories.
Today, it's already possible to use resources repositories, defining it
(in XML or JSON) in etc/org.apache.karaf.features.cfg. This
configuration is evaluated when the features service starts and used by
the features resolver.
The propose is:
1. add resource:repo-add and other commands to add/remove resource
repositories at runtime and then perform a new evaluation of the resolution.
2. add <resource/> element in features repo (as we have <repository/>)
allowing to define "open" features and relay on resources repository.
So, to be clear, I don't want to change the current features service
which, again, provide unique features, and it's the minimal layer to
start a karaf runtime. My proposal is to extend & improve the features
service to better leverage the resources repositories. The user then can
focus only on a resource repository and won't be "forced" to use a
features repository.
Regards
JB
On 28/11/2018 06:38, Christian Schneider wrote:
> I understand that you are seeking a more standard way than karaf
> features to deploy parts of an application. Indeed subsystems look like
> a good way at first. Unfortunately they add a lot of complexity to a
> system. So almost no one uses them.
>
> Currently there are two major ways of packaging an application:
> - karaf features (uses repository + + requirements under the covers). A
> feature repo is described in xml. The bundles from all the required
> features form the repository. The bundles with dependency=false form the
> requirements.
> - repository + requirements based approach like used by bnd (without
> features). They currently use a pom file to describe a repository +
> requirements in a bndrun file.
>
> So I agree it would be great to have a more standard way to package
> applications. I discussed with JB that we could make more explicit use
> of repositories for karaf features. The idea is to describe karaf
> features using a backing repository + required bundles for each feature.
> We could describe the repository for the feature in a pom and refer to
> it in the feature repo file. The features would then only contain the
> required bundles.
>
> This approach would provide a repository in pom form for all karaf
> features that is then also usable by bnd for packaging. So projects like
> aries would only need to provide one common form of feature description.
>
> Besides this there is a standardisation effort at the OSGi alliance for
> features. Currently the work in progress there looks more like karaf 2
> featues, so it is not usable for karaf but maybe in the next iteraion a
> repository based approach is considered.
>
> Chritian
>
>
> Am Di., 27. Nov. 2018 um 21:56 Uhr schrieb Leschke, Scott
> <SLeschke@medline.com <ma...@medline.com>>:
>
> It wasn’t really a dev request per se, more of a curiosity question
> as to whether something along those lines was being considered as it
> would seem to make the implementations more easily consumable in a
> variety of OSGi environments. My primary interest is in Karaf which
> is why I guess I targeted this list. Perhaps I should have thought
> that through better.____
>
> __ __
>
> As for how something like that were structured, I don’t know
> really. I only have passing familiarity with the Subsystem spec and
> that it sort of overlaps and extends what Karaf Features do, at
> least to my knowledge. My take is that a Karaf Feature commonly maps
> to an OSGi service spec. implementation, even if the names don’t
> match exactly____
>
> __ __
>
> I readily admit that I could be grossly mistaken on that.____
>
> __ __
>
> Scott____
>
> __ __
>
> *From:* David Jencks <david.a.jencks@gmail.com
> <ma...@gmail.com>>
> *Sent:* Tuesday, November 27, 2018 2:08 PM
> *To:* user@karaf.apache.org <ma...@karaf.apache.org>
> *Subject:* Re: Aries____
>
> __ __
>
> I’m somewhat curious how you decided on this karaf list for a Dev
> request for Aries.____
>
> I’m more curious how a feature subsystem would help deploying an
> aries osgi service implementation. I haven’t looked for several
> years at how Aries sub projects divide up their artifact
> functionality, but I’d hope that all the spec functionality, and
> api, would be from a single bundle, with, possibly additional
> bundles for extensions. If this is how a project is structured, how
> does a feature subsystem make deployment easier? If not, would it
> make more sense to adopt such a structure than to imitate it with a
> feature subsystem?____
>
> Thanks____
>
> David Jencks ____
>
> Sent from my iPhone____
>
>
> On Nov 27, 2018, at 11:27 AM, Leschke, Scott <SLeschke@medline.com
> <ma...@medline.com>> wrote:____
>
> I was wondering if there is a possibility that the Aries project
> would provide OSGi Feature Subsystems for each of the OSGi
> services they’ve implemented (with the exception of the
> subsystem spec of course). There is a Karaf Feature for
> installing the Subsystem service so it would be nice if the
> remaining services were available as Feature Subsystems (or
> Karaf Features I guess but the former seems like a more neutral
> solution).____
>
> ____
>
> Scott____
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Aries
Posted by Ranx <ra...@enjekt.org>.
Christian,
That's interesting that the features being defined by the OSGi Alliance
would be more like Karaf 2. Why is that? It would seem that the Karaf team
would have a lot of insight into why that worked, what didn't work, and why
the new features mechanics were adopted for later versions of Karaf.
Does anyone else really use feature sets?
I've noticed that the OSGi Alliance doesn't appear to have a lot of
simpatico with the Karaf world in general. I'll be the first to admit that
that may be due to a limited knowledge of the group.
I love OSGi technology but we've always seemed to be plagued with the Un*x
problem - everybody has their flavor and way of doing things and multiple
standards and implementations which results in a fractured world. We often
feature that because we can't fix it.
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Aries
Posted by Christian Schneider <ch...@die-schneider.net>.
I understand that you are seeking a more standard way than karaf features
to deploy parts of an application. Indeed subsystems look like a good way
at first. Unfortunately they add a lot of complexity to a system. So almost
no one uses them.
Currently there are two major ways of packaging an application:
- karaf features (uses repository + + requirements under the covers). A
feature repo is described in xml. The bundles from all the required
features form the repository. The bundles with dependency=false form the
requirements.
- repository + requirements based approach like used by bnd (without
features). They currently use a pom file to describe a repository +
requirements in a bndrun file.
So I agree it would be great to have a more standard way to package
applications. I discussed with JB that we could make more explicit use of
repositories for karaf features. The idea is to describe karaf features
using a backing repository + required bundles for each feature. We could
describe the repository for the feature in a pom and refer to it in the
feature repo file. The features would then only contain the required
bundles.
This approach would provide a repository in pom form for all karaf features
that is then also usable by bnd for packaging. So projects like aries would
only need to provide one common form of feature description.
Besides this there is a standardisation effort at the OSGi alliance for
features. Currently the work in progress there looks more like karaf 2
featues, so it is not usable for karaf but maybe in the next iteraion a
repository based approach is considered.
Chritian
Am Di., 27. Nov. 2018 um 21:56 Uhr schrieb Leschke, Scott <
SLeschke@medline.com>:
> It wasn’t really a dev request per se, more of a curiosity question as to
> whether something along those lines was being considered as it would seem
> to make the implementations more easily consumable in a variety of OSGi
> environments. My primary interest is in Karaf which is why I guess I
> targeted this list. Perhaps I should have thought that through better.
>
>
>
> As for how something like that were structured, I don’t know really. I
> only have passing familiarity with the Subsystem spec and that it sort of
> overlaps and extends what Karaf Features do, at least to my knowledge. My
> take is that a Karaf Feature commonly maps to an OSGi service spec.
> implementation, even if the names don’t match exactly
>
>
>
> I readily admit that I could be grossly mistaken on that.
>
>
>
> Scott
>
>
>
> *From:* David Jencks <da...@gmail.com>
> *Sent:* Tuesday, November 27, 2018 2:08 PM
> *To:* user@karaf.apache.org
> *Subject:* Re: Aries
>
>
>
> I’m somewhat curious how you decided on this karaf list for a Dev request
> for Aries.
>
> I’m more curious how a feature subsystem would help deploying an aries
> osgi service implementation. I haven’t looked for several years at how
> Aries sub projects divide up their artifact functionality, but I’d hope
> that all the spec functionality, and api, would be from a single bundle,
> with, possibly additional bundles for extensions. If this is how a project
> is structured, how does a feature subsystem make deployment easier? If not,
> would it make more sense to adopt such a structure than to imitate it with
> a feature subsystem?
>
> Thanks
>
> David Jencks
>
> Sent from my iPhone
>
>
> On Nov 27, 2018, at 11:27 AM, Leschke, Scott <SL...@medline.com> wrote:
>
> I was wondering if there is a possibility that the Aries project would
> provide OSGi Feature Subsystems for each of the OSGi services they’ve
> implemented (with the exception of the subsystem spec of course). There is
> a Karaf Feature for installing the Subsystem service so it would be nice if
> the remaining services were available as Feature Subsystems (or Karaf
> Features I guess but the former seems like a more neutral solution).
>
>
>
> Scott
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com
RE: Aries
Posted by "Leschke, Scott" <SL...@medline.com>.
It wasn’t really a dev request per se, more of a curiosity question as to whether something along those lines was being considered as it would seem to make the implementations more easily consumable in a variety of OSGi environments. My primary interest is in Karaf which is why I guess I targeted this list. Perhaps I should have thought that through better.
As for how something like that were structured, I don’t know really. I only have passing familiarity with the Subsystem spec and that it sort of overlaps and extends what Karaf Features do, at least to my knowledge. My take is that a Karaf Feature commonly maps to an OSGi service spec. implementation, even if the names don’t match exactly
I readily admit that I could be grossly mistaken on that.
Scott
From: David Jencks <da...@gmail.com>
Sent: Tuesday, November 27, 2018 2:08 PM
To: user@karaf.apache.org
Subject: Re: Aries
I’m somewhat curious how you decided on this karaf list for a Dev request for Aries.
I’m more curious how a feature subsystem would help deploying an aries osgi service implementation. I haven’t looked for several years at how Aries sub projects divide up their artifact functionality, but I’d hope that all the spec functionality, and api, would be from a single bundle, with, possibly additional bundles for extensions. If this is how a project is structured, how does a feature subsystem make deployment easier? If not, would it make more sense to adopt such a structure than to imitate it with a feature subsystem?
Thanks
David Jencks
Sent from my iPhone
On Nov 27, 2018, at 11:27 AM, Leschke, Scott <SL...@medline.com>> wrote:
I was wondering if there is a possibility that the Aries project would provide OSGi Feature Subsystems for each of the OSGi services they’ve implemented (with the exception of the subsystem spec of course). There is a Karaf Feature for installing the Subsystem service so it would be nice if the remaining services were available as Feature Subsystems (or Karaf Features I guess but the former seems like a more neutral solution).
Scott
Re: Aries
Posted by David Jencks <da...@gmail.com>.
I’m somewhat curious how you decided on this karaf list for a Dev request for Aries.
I’m more curious how a feature subsystem would help deploying an aries osgi service implementation. I haven’t looked for several years at how Aries sub projects divide up their artifact functionality, but I’d hope that all the spec functionality, and api, would be from a single bundle, with, possibly additional bundles for extensions. If this is how a project is structured, how does a feature subsystem make deployment easier? If not, would it make more sense to adopt such a structure than to imitate it with a feature subsystem?
Thanks
David Jencks
Sent from my iPhone
> On Nov 27, 2018, at 11:27 AM, Leschke, Scott <SL...@medline.com> wrote:
>
> I was wondering if there is a possibility that the Aries project would provide OSGi Feature Subsystems for each of the OSGi services they’ve implemented (with the exception of the subsystem spec of course). There is a Karaf Feature for installing the Subsystem service so it would be nice if the remaining services were available as Feature Subsystems (or Karaf Features I guess but the former seems like a more neutral solution).
>
> Scott
Re: Aries
Posted by Jeongpil An <je...@gmail.com>.
Hi, Schneider, JB, Scot.
I'm using Karaf very well.
And I'm a people who wish to use subsystem on karaf well.
I think the Feature function is very good and useful.
But It's also a fact that I need Subsystem spec functionalities for my
projects and my dev direction.
Because I am highly using Business Component(BC) and Subsystem(or
System-Level) Component(SLC) concept.
I think The Bundle and Subsystem OSGi Spec is very fit for those.
A year ago I'm not good experience about subsystem functionalitiesm on
karaf.
Maybe needs more work of Aries Subsystem Bundle.
So again, please your interest about Subsystem.
Thanks, All of you..
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html