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"
