Bugzilla – Full Text Bug Listing
| Summary: | Changes to FrameworkCommnadProvider and Framework Console to allow an OSGi console to be launched for a currently running framework | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | R Keelan <RKeelan> | ||||||||||||||
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> | ||||||||||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||||||||||
| Severity: | enhancement | ||||||||||||||||
| Priority: | P3 | CC: | fcuadrado, pascal, RKeelan, simon_kaegi, tjwatson | ||||||||||||||
| Version: | 3.3 | ||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows XP | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Bug Depends on: | |||||||||||||||||
| Bug Blocks: | 162420 | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
R Keelan
Created attachment 52758 [details]
Proposed patch that implements the changes described in the bug report
Created attachment 52854 [details]
New version of propsed patch
Should not be released yet, I will look into using a service factory.
(In reply to comment #2) > Created an attachment (id=52854) [edit] > New version of propsed patch > Should not be released yet, I will look into using a service factory. I have not had time to look at the patch yet. I'm not sure what you mean by service factory in this context. I chatted with Pascal about this a little bit. I think there is a better way to do this. Instead of exposing internals of the FrameworkCommandProvider and FrameworkConsole and having the ui part construct the FrameworkConsole themselves, it may be better to have a new Console Service interface (org.eclipse.osgi.framework.console.Console). To start with this Console interface would one simple method. public String runCommand(String command) The underlying FrameworkConsole implementation would implement this interface and it would be registered as a service. The ui part would then just use this service to run commands on the console and get output from the console. Now here is where a service factory would be good. The framework would register a Console service factory and would not construct the FrameworkConsole instance until a client got the Console Service from the service registry. Thoughts? Sounds good to me. runCommand could delegate to doCommand, I think. The only trouble is that doCommand uses a CommandInterpreter to execute the command, which then prints the results directly to the FrameworkConsole's printWriter. Off the top of my head, I can't think of a way to get the results back from the PrintWriter so it can be returned in the String. we should also consider these APIs and usecases as candidates for standardization. The OSGi CPEG is currently looking at adding a console service to the spec. Tom, Richard and I talked after we talked and he is set to do what you describe in the comment #3. The only difference is the API which will need to take a writer and a reader of some sort to allow the output to be directed appropriately (see what Richard says in comment #4). Jeff, what is the scope of the console spec work? Is it a way to interact with a console, or is it the definition of some wellknown commands, or both, or none of the above. roughly what is a command, how does on supply a command, how does it run etc. The intent is to allow people to write commands once and use them in any console. Created attachment 52985 [details]
Console service patch (proposal)
Either way I think the FrameworkCommandInterpreter implementation is going to need to be restructured a bit. If we are going to do this I think it is possible to have a simple Console service interface that does not need a PrintWriter PrintReader set to it.
This patch splits the common parts of FrameworkCommandInterpreter out into a BaseCommandInterpreter. This implementation can be used by a ConsoleImpl class to implement the Console.runCommand method.
Note that this patch is a quick hack to give you an idea of what I was thinking. It needs polishing.
Created attachment 52987 [details]
Console service patch (proposal)
Disregard the last patch, it included some other things from my workspace not related to the console.
Created attachment 53111 [details]
Updated patch
New patch that incorporates Tom's changes, and provides the console as a service.
Created attachment 53195 [details] patch Updated patch from attachment 53111 [details]. - Moved console service registration from EclipseStarter to an AdaptorHook - Moved -console (osgi.console) property processing from EclispeStarter to an AdaptorHook. This is what actually starts the "real" osgi> console prompt. Standarization of a Console API for OSGi would be something really useful, and I think the extensibility of Equinox Console is a very valuable feature. However, it can only be used in Equinox, as it is embedded in it. I am developing an extension for adding support to Felix in the new PDE OSGi frameworks extension point, and currently each framework implementation has to supply its own set of bundles for a basic console functionality. Would it be possible to extract the console from the system bundle so that it can be used in any framework? That would also probably increase the popularity of defining and offering FrameworkCommands, as they would be OSGi generic instead of Equinox specific. What a fine idea. Felix, are you able to sketch that out in a patch? Perhaps if we had a new bundle, something like org.eclipse.equinox.console then people could contribute command handlers. Presumable then the framework could contribute its command handlers simply by registering services. there is an interesting chicken and egg problem in as much as some command implementations must be in the framework (at least I suspect so). Those impls need to reference the command interface which, at least in theory, would be supplied by this other bundle. The console could come as a framework fragment I suppose. Felix, if you are going to do some work in this area perhaps a separate bug report would be best. (In reply to comment #13) > What a fine idea. Felix, are you able to sketch that out in a patch? Perhaps > if we had a new bundle, something like org.eclipse.equinox.console then people > could contribute command handlers. Presumable then the framework could > contribute its command handlers simply by registering services. > > there is an interesting chicken and egg problem in as much as some command > implementations must be in the framework (at least I suspect so). Those impls > need to reference the command interface which, at least in theory, would be > supplied by this other bundle. The console could come as a framework fragment > I suppose. > > Felix, if you are going to do some work in this area perhaps a separate bug > report would be best. I don't think I am the best suited person for working on this refactoring, as I only have experience with Equinox and the console by using them as "black box" bundles, and this type of refactoring requires a thorough knowledge of them. About possible solutions, I think it should be feasible to separate completely the console as a bundle. In Apache Felix they have followed this approach with the org.apache.felix.shell service, which is delivered as two bundles (generic service and text ui impl) and works with Felix, Knopfler and Equinox. Marking as dup of bug 279562 where we did some work to allow ConsoleSession to be registered as a service in order to start a new console session. *** This bug has been marked as a duplicate of bug 279562 *** |