karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Ideas about karaf and gogo commands
Date Wed, 05 Mar 2014 10:39:51 GMT
2014-03-05 8:51 GMT+01:00 Christian Schneider <chris@die-schneider.net>:

> On 04.03.2014 17:59, Guillaume Nodet wrote:
>> Btw, i pushed some commits to my branch.  Karaf seems fully functional and
>> a compatibility layer has been extracted as a fragment to the console, so
>> that the shell.console bundle only contains the api and implementation of
>> the new stuff.
>> 2014-03-04 9:11 GMT+01:00 Christian Schneider <chris@die-schneider.net>:
>>  Hi Guillaume,
>>> I like the abstraction from console and jline in your proposal.
>>> The extender pattern in fact solves the classloading problem. So you can
>>> now hide the impl classes. As the extender is independent of the user
>>> framework
>>> it is of course also "compatible" to other frameworks.
>>> The problem with this aproach is that you force people to use the
>>> extender
>>> and our quite unusual DI implementation
>>> As the impls are hidden now there is no way to use the API without also
>>> using the extender. For karaf itself this should not pose a big problem.
>>> For external implementations I am not sure if it is a good fit. Some
>>> limitation I see in the extender is that it has a very limited set of
>>> injection possibilities.
>>> You can only inject OSGi services. In camparison in the gogo API case you
>>> could use your user framework to inject configuration and also private
>>> beans when using it with blueprint.
>>> Btw. I do not propose to extend the DI support in the extender. I am fine
>>> with this limitation but we have to be aware of it.
>>>  So OSGi services are not the only kind of services that can be injected.
>>   Actually, any service registered in the Registry object can be injected.
>> I've added a programmatic way to register services and actions which is
>> used for SSH:
>> https://github.com/gnodet/karaf/blob/console-api/shell/
>> ssh/src/main/java/org/apache/karaf/shell/ssh/Activator.java#L120
>> The existence of the extender does not necessarily prevent other
>> implementations such as ones based on blueprint or SCR, but they haven't
>> been ported yet.
>> For ssh, it could make sense for example, as the wiring is a bit more
>> complicated, but in most cases, the injection is very simple and the
>> extender makes things quite simple, as the only real thing to do is to add
>> the Karaf-Commands header to the manifest.
>> One of the benefit of the new model with the extender is that the
>> dependencies are quite minimal and with no interactions with the DI used,
>> so we could even think about merging back the commands and the services
>> with the packages imported for the commands being optional.  The bundle
>> could still be used even if the console is not available without any
>> problems.
> As the extender allows to be kind of framework agnostic I like the idea to
> only have the extender for actions and leave it limited in features.
> I think for ssh it should be possible to put all complicated injections
> into an ssh OSGi service that the command then gets injected.
> So we avoid adding more complexity to the extender. Would that work?
Definitely, that's actually what I did.  This simple injection also allowed
the use of the ssh:ssh command from bin/shell (i.e. no OSGi at all).

>>  If we additionally include support for gogo style commands with the
>>> parameter style like discussed then we should have a good solution. So
>>> internally we can use the
>>> API you propose and externally people can decide if they want to code
>>> against the extended gogo API (with completion) based on services or
>>> against the karaf API based on the extender.
>> That's not really the way I see it.   The usage of the API and the DI /
>> extender used are not related.  You could use an extender for gogo
>> commands
>> or blueprint for actions.
> What I wanted to express it that the Action model does not work with
> simple service exporting. So it is inherently more complex to implement.
> That is why I think the gogo model is more suitable when you want to not
> use extenders or framework extensions like blueprint namespaces.
>  Support for gogo commands is currently not available, but it's very easy
>> to
>> implement.   The following does implement the support for the previous
>> action/model :
>> https://github.com/gnodet/karaf/blob/console-api/shell/
>> compatibility/src/main/java/org/apache/karaf/shell/compat/
>> CommandTracker.java
>> So, supporting plain gogo commands is just a matter of writing a Command
>> implementation as above which supports "--help" and a completer, that's
>> all.
> I will look into this as soon as I get some free time. Currently I am
> still more engaged in cxf.
> Christian
> --
> Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> http://www.talend.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message