2014-03-05 8:51 GMT+01:00 Christian Schneider <ch...@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 <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? > > 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 > >
