Revision as of 11:27, 5 November 2012 by Phejl (Talk | contribs)

Execution API merge


Problem statement

  • There is a need of common public API for executing external processes - either on local host or remote host.
  • There are several flavors of related APIs:
    • dlight.nativeexecution - non public (friend) API used by C/C++ modules and many modules in Studio ( 119 friends in total); All the code that uses this API is under our control;
    • extexecution - PUBLIC API for executing remote processes. It is plug-able and allows to pass own ProcessBuilder. As API is public, there are users of the API that are not under our control... (54 modules in nb codebase use it)
    • richexecution (within lib.terminalemulator)

dlight.nativeexecution is intensively used in CND. This module provides functionality for runnig processes on different platforms (*nix, windows, macos), it deals with processes starting/terminating, I/O, different terminals, signals, and so on. So it provides good functionality coverage, but has several big problems:

  • nowadays it requires serious cleanup;
  • it's implementation has many places where call to some method initiates a connection, which is unexpected in most cases
  • it is ssh-oriented. It's fundamental API object, ExecutionEnvironment, doesn't provide a way for specifying a way of accessing remote host
  • it's error-handling/flow is not well structured and not always clear

cleaned-up dlight.nativeexecution can be used as an implementation module with extexecution API, but extexecution should be extended in this case to support features proposed by the dlight.nativeexecution.

Scope ot the review

  • I would like to review an API (cleaned-up) of nativeexecution (not binded anyhow to extexecution) with the main aim to demostrate
    • what functionality this module provides (all this functionality was needed for CND's remote support)
    • how the functionality affected some API design decisions
  • Then I would like to make conclusions on what is missing in the extexecution (mostly this is about ExternalProcessBuilder), how it could be extended in a compatible way to make it possible for users to use full range of functionality provided by nativeexecution.

From here by term 'nativeexecution' I mean a new rewrittent API/implementation which is a result of clean-up of existent dlight.nativeexecution module. The posible way of dealing with modules (as I see it) is to:

  1. Deprecate dlight.nativeexecution
  2. Introduce nativeexecution (API/SPI/impl)
  3. Extend extexecution and start using (2) as a implementation layer
  4. Move existent CND modules on the new APIs (extexecution/nativeexecution)
  5. Get rid of the 'old' nativeexecution.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo