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 <ch...@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?
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
