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. > > 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. 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. > > Christian > > > On 26.02.2014 10:50, Guillaume Nodet wrote: > >> >> The classloader problem is mostly because we don't use an extender. >> Blueprint should be able to hide the internal classes used, and that's >> actually the case because no bundle sees the BlueprintCommand which is >> used. DS is slightly different as it can not contribute its own classes, >> where blueprint namespace handlers can. >> >> So I really think using an extender would solve the whole problem I think. >> I've just spent a bit of time drafting a cleaner API for commands. The >> main problem with the current state is that there was no clean API written >> at the very beginning and things have evolved quite a bit. In addition, >> gogo and jline leak into our API which is not really good. >> >> So I'd like to discuss the following small API which I think would be very >> easy to use (it's mostly a different package). >> >> https://github.com/gnodet/karaf/tree/console-api/shell/ >> console/src/main/java/org/apache/karaf/shell/api >> >> The annotations are basically what we have, the main changes are: >> * Action main method has been changed to avoid referencing gogo >> * the gogo CommandSession and jline Terminal / ConsoleReder are hidden >> by >> a minimal api (.api.console.Session and Terminal) >> * Terminal, Session and BundleContext would be injected with @Reference >> along any OSGi service >> * bundles containing commands need a Karaf-Command manifest header >> >> The benefits would be the following: >> * clean API, so complete separation of command implementors from the >> implementation >> * also abstract gogo and jline >> * no need for blueprint / DS at all >> * complete support for what we have >> * we could start using semantic versioning on those 3 packages (it >> doesn't have to be tied to the release cycle) >> * easy enough switch (just a few package changes usually, slightly more >> for commands that were using gogo or jline) >> * way easier to support a degraded mode on top of pure gogo >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
