You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Giovanni Meo <gm...@cisco.com> on 2014/05/19 14:57:45 UTC
Question regarding defining Karaf CLIs using the GOGO shell way
Hi Karaf-users,
I have a newbie karaf CLI question. I have learned that karaf CLIs can be
defined in two ways:
1) By extending the class OsgiCommandSupport and publishing in the OSGi service
registry
2) By using a POJO and registering it in the OSGi service registry with
osgi.command and osgi.scope properties attached (GOGO shell way)
now in the project i work on we already have some CLI using #2 and many older
CLI using the Equinox way (implementing CommandProvider). We want to migrate
those old CLIs to be compatible with Karaf, but given still we are not yet fully
on Karaf but we do have GOGO shell, i have been thinking to use the GOGO shell
way (approach #2).
Now i have been asking around and folks suggest to go via #1 directly, but given
we are not yet fully on Karaf #1 would break our current containers, unless we
create a level of indirection.
Now the question i ask is, what do we loose in Karaf if we go the approach #2
and what makes (technically) approach #1 the preferred one?
Thanks in advance for any help you can provide,
Giovanni
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
Re: Question regarding defining Karaf CLIs using the GOGO shell way
Posted by Giovanni Meo <gm...@cisco.com>.
Hi JB,
thanks a lot for your time and explanation, definitively more clear now.
Thanks,
Giovanni
On 20-May-14 16:10, Jean-Baptiste Onofré wrote:
> Basically, OsgiCommandSupport is "just" a wrapper on top of the Gogo action.
> But, it brings convenience for loading/unloading the related OSGi services.
>
> However, in "previous" version, we ship our own version of Gogo, with some
> modification. That's why using the OsgiCommandSupport, you are sure to use the
> version of Gogo that we embed in Karaf.
>
> In new Karaf version (especially in the future Karaf 4), it's largely cleaner.
>
> Regards
> JB
>
> On 05/20/2014 03:58 PM, Giovanni Meo wrote:
>> Hi JB,
>>
>> thanks for the answer, but i'm just curious to understand what we loose with
>> gogo way. We are in an environment where karaf is being rolled in, but already
>> have gogo shell.
>>
>> Thanks,
>> Giovanni
>>
>> On 20-May-14 15:23, Jean-Baptiste Onofré wrote:
>>> Hi Giovanni,
>>>
>>> my advice is to still extend OsgiCommandSupport up to Karaf 3.
>>> Like this, you are sure that it works fine (with all the related like
>>> completion, help, etc).
>>>
>>> In Karaf 4, we introduced a new API.
>>>
>>> Regards
>>> JB
>>>
>>> On 05/19/2014 02:57 PM, Giovanni Meo wrote:
>>>> Hi Karaf-users,
>>>>
>>>> I have a newbie karaf CLI question. I have learned that karaf CLIs can be
>>>> defined in two ways:
>>>>
>>>> 1) By extending the class OsgiCommandSupport and publishing in the OSGi service
>>>> registry
>>>> 2) By using a POJO and registering it in the OSGi service registry with
>>>> osgi.command and osgi.scope properties attached (GOGO shell way)
>>>>
>>>> now in the project i work on we already have some CLI using #2 and many older
>>>> CLI using the Equinox way (implementing CommandProvider). We want to migrate
>>>> those old CLIs to be compatible with Karaf, but given still we are not yet
>>>> fully
>>>> on Karaf but we do have GOGO shell, i have been thinking to use the GOGO shell
>>>> way (approach #2).
>>>> Now i have been asking around and folks suggest to go via #1 directly, but
>>>> given
>>>> we are not yet fully on Karaf #1 would break our current containers, unless we
>>>> create a level of indirection.
>>>> Now the question i ask is, what do we loose in Karaf if we go the approach #2
>>>> and what makes (technically) approach #1 the preferred one?
>>>>
>>>> Thanks in advance for any help you can provide,
>>>> Giovanni
>>>>
>>>
>>
>
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
Re: Question regarding defining Karaf CLIs using the GOGO shell way
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Basically, OsgiCommandSupport is "just" a wrapper on top of the Gogo
action. But, it brings convenience for loading/unloading the related
OSGi services.
However, in "previous" version, we ship our own version of Gogo, with
some modification. That's why using the OsgiCommandSupport, you are sure
to use the version of Gogo that we embed in Karaf.
In new Karaf version (especially in the future Karaf 4), it's largely
cleaner.
Regards
JB
On 05/20/2014 03:58 PM, Giovanni Meo wrote:
> Hi JB,
>
> thanks for the answer, but i'm just curious to understand what we loose with
> gogo way. We are in an environment where karaf is being rolled in, but already
> have gogo shell.
>
> Thanks,
> Giovanni
>
> On 20-May-14 15:23, Jean-Baptiste Onofré wrote:
>> Hi Giovanni,
>>
>> my advice is to still extend OsgiCommandSupport up to Karaf 3.
>> Like this, you are sure that it works fine (with all the related like
>> completion, help, etc).
>>
>> In Karaf 4, we introduced a new API.
>>
>> Regards
>> JB
>>
>> On 05/19/2014 02:57 PM, Giovanni Meo wrote:
>>> Hi Karaf-users,
>>>
>>> I have a newbie karaf CLI question. I have learned that karaf CLIs can be
>>> defined in two ways:
>>>
>>> 1) By extending the class OsgiCommandSupport and publishing in the OSGi service
>>> registry
>>> 2) By using a POJO and registering it in the OSGi service registry with
>>> osgi.command and osgi.scope properties attached (GOGO shell way)
>>>
>>> now in the project i work on we already have some CLI using #2 and many older
>>> CLI using the Equinox way (implementing CommandProvider). We want to migrate
>>> those old CLIs to be compatible with Karaf, but given still we are not yet fully
>>> on Karaf but we do have GOGO shell, i have been thinking to use the GOGO shell
>>> way (approach #2).
>>> Now i have been asking around and folks suggest to go via #1 directly, but given
>>> we are not yet fully on Karaf #1 would break our current containers, unless we
>>> create a level of indirection.
>>> Now the question i ask is, what do we loose in Karaf if we go the approach #2
>>> and what makes (technically) approach #1 the preferred one?
>>>
>>> Thanks in advance for any help you can provide,
>>> Giovanni
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Question regarding defining Karaf CLIs using the GOGO shell way
Posted by Giovanni Meo <gm...@cisco.com>.
Hi JB,
thanks for the answer, but i'm just curious to understand what we loose with
gogo way. We are in an environment where karaf is being rolled in, but already
have gogo shell.
Thanks,
Giovanni
On 20-May-14 15:23, Jean-Baptiste Onofré wrote:
> Hi Giovanni,
>
> my advice is to still extend OsgiCommandSupport up to Karaf 3.
> Like this, you are sure that it works fine (with all the related like
> completion, help, etc).
>
> In Karaf 4, we introduced a new API.
>
> Regards
> JB
>
> On 05/19/2014 02:57 PM, Giovanni Meo wrote:
>> Hi Karaf-users,
>>
>> I have a newbie karaf CLI question. I have learned that karaf CLIs can be
>> defined in two ways:
>>
>> 1) By extending the class OsgiCommandSupport and publishing in the OSGi service
>> registry
>> 2) By using a POJO and registering it in the OSGi service registry with
>> osgi.command and osgi.scope properties attached (GOGO shell way)
>>
>> now in the project i work on we already have some CLI using #2 and many older
>> CLI using the Equinox way (implementing CommandProvider). We want to migrate
>> those old CLIs to be compatible with Karaf, but given still we are not yet fully
>> on Karaf but we do have GOGO shell, i have been thinking to use the GOGO shell
>> way (approach #2).
>> Now i have been asking around and folks suggest to go via #1 directly, but given
>> we are not yet fully on Karaf #1 would break our current containers, unless we
>> create a level of indirection.
>> Now the question i ask is, what do we loose in Karaf if we go the approach #2
>> and what makes (technically) approach #1 the preferred one?
>>
>> Thanks in advance for any help you can provide,
>> Giovanni
>>
>
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
Re: Question regarding defining Karaf CLIs using the GOGO shell way
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Giovanni,
my advice is to still extend OsgiCommandSupport up to Karaf 3.
Like this, you are sure that it works fine (with all the related like
completion, help, etc).
In Karaf 4, we introduced a new API.
Regards
JB
On 05/19/2014 02:57 PM, Giovanni Meo wrote:
> Hi Karaf-users,
>
> I have a newbie karaf CLI question. I have learned that karaf CLIs can be
> defined in two ways:
>
> 1) By extending the class OsgiCommandSupport and publishing in the OSGi service
> registry
> 2) By using a POJO and registering it in the OSGi service registry with
> osgi.command and osgi.scope properties attached (GOGO shell way)
>
> now in the project i work on we already have some CLI using #2 and many older
> CLI using the Equinox way (implementing CommandProvider). We want to migrate
> those old CLIs to be compatible with Karaf, but given still we are not yet fully
> on Karaf but we do have GOGO shell, i have been thinking to use the GOGO shell
> way (approach #2).
> Now i have been asking around and folks suggest to go via #1 directly, but given
> we are not yet fully on Karaf #1 would break our current containers, unless we
> create a level of indirection.
> Now the question i ask is, what do we loose in Karaf if we go the approach #2
> and what makes (technically) approach #1 the preferred one?
>
> Thanks in advance for any help you can provide,
> Giovanni
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com