站内搜索: 请输入搜索关键词
当前页面: 在线文档首页 > NetBeans API Javadoc (Current Development Version)

org.netbeans.api.debugger (Debugger Core API) - NetBeans API Javadoc (Current Development Version)

Overview   Package  Class  Use  Tree  Deprecated  Index  Help 
org.netbeans.api.debugger/1 1.11
 PREV PACKAGE   NEXT PACKAGE FRAMES    NO FRAMES    

Package org.netbeans.api.debugger

The NetBeans Debugger Core API definition.

See:
          Description

Interface Summary
ActionsManagerListener This listener notifies about changes in the DebuggerEngine.
DebuggerManagerListener This listener notifies about changes in the DebuggerManager - breakpoints, watches and sessions.
LazyDebuggerManagerListener This DebuggerManagerListener modification is designed to be registered in "META-INF/debugger/org.netbeans.api.debugger.LazyDebuggerManagerListener".
Properties.Reader This class helps to store and read custom types using Properties.setObject(java.lang.String, java.lang.Object) and Properties.getObject(java.lang.String, java.lang.Object) methods.
 

Class Summary
ActionsManager Manages some set of actions.
ActionsManagerAdapter Empty implementation of ActionsManagerListener.
Breakpoint Abstract definition of breakpoint.
DebuggerEngine Debugger Engine represents implementation of one debugger (Java Debugger, CPP Debugger).
DebuggerInfo Contains information needed to start new debugging.
DebuggerManager The root class of Debugger APIs.
DebuggerManagerAdapter Empty implementation of DebuggerManagerListener.
LazyActionsManagerListener This ActionsManagerListener modification is designed to be registerred in "META-INF/debugger/".
Properties Utility class hepls store properties.
Session Session visually represents one process or application.
Watch Abstract definition of watch.
 

Enum Summary
Breakpoint.HIT_COUNT_FILTERING_STYLE The style of filtering of hit counts.
Breakpoint.VALIDITY Validity values
 

Package org.netbeans.api.debugger Description

The NetBeans Debugger Core API definition. Debugger Core API interfaces allows to install differrent debugger inlementations to one IDE, and share some UI components among them.

Basic debugger model

Debugger Core API represents debugger as some tree structure. DebuggerManager represents root of this tree. It manages list of Breakpoints, Watches and running Sessions. All watches and breakpoints registerred here are shared for all running sessions.

Session represents one process or application running in debug mode. Each Session manages list of supported programming languages. Support for each programming language is represented by some instance of DebuggerEngine. DebuggerEngine is a main intergation point for all Debugger Plug-ins. Most of Service Providers (like ActionsProvider or different Models) should be registered for some concrete type of DebuggerEngine.

DebuggerManager
  |
  |- Breakpoint(s)
  |
  |- Watch(es)
  |
  |- Session(s)   <programming language 1 -> DebuggerEngine 1>
                  <programming language 2 -> DebuggerEngine 2>
                   ...


One DebuggerEngine can manage more than one language. And it can be used for more than one Session. In extreme example, there may be one DebuggerManager only for several different sessions and for many different languages.

The only way how to add some language, session or engine to this tree is method DebuggerManager.startDebugging(DebuggerInfo). The only method how to remove something is DebuggerEngine.Destructor.

Exension of basic model - lookups, Meta-inf/debugger

Basic debugger model is very simple, and it should be extended by some additional services (see Debugger SPI documentation for default set of additional services). As the Debugger API interfaces should be (and are) final, we use lookup pattern for this purpose.

List of 'extensible' interfaces:
There are two ways how to registrer services. The first possibility is to put 'live' instance of some service to the interface when a new instance is created. This solution is supported by methods: DebuggerInfo.create(String,Object[]), getServices() and DebuggerEngineProvider.getServices(). Second possibility (and preferred one) is to register service to Meta-inf/debugger folder. The way how to do it is described in Debugger SPI documentation.

Debugger Start Process

The process which implements starting of debugger in Debugger Core module is very simple. There is one instance of DebuggerInfo and DebuggerManager.startDebugging(DebuggerInfo) method on the begining of this process. DebuggerInfo determines a set of debugger Sessions to be started:

List sessionProviders = debuggerInfo.lookup (null, SessionsProvider.class);

A new instance of Session is created for every SessionProvider after that. A set of DebuggerEngines is created for each Session in the second step:

List engineProviders = session.lookup (null, DebuggerEngineProvider.class);

Each DebuggerEngineProvider drives creation of one new instance of DebuggerEngine. So, the debugger start process creates a tree of new Sessions and new DebuggerEngines and registers them to the DebuggerManager. Thats all.

Debugger Start Process - advanced version

Debugger API supports two enhancements to the standard debugger start process:
  1. Start new DebuggerEngine for already existing Session
  2. Create a new Session for already existing DebuggerEngine.
DelegatingSessionProvider interface is designed to support first usecase. You should implement and register this interface in Meta-inf/debugger, to delegate on some existing Session.
Second usecase is supported by interface DelegatingDebuggerEngineProvider.

Debugger Actions - how does it work

debuggercore-ui module installs some basic set of standard debugger actions to NetBeans toolbar and menu. Debugger actions (javax.swing.Action) are private. Each action is represented by some constant in ActionsManager (like ActionsManager.ACTION_STEP_INTO).
ActionsManager manages list of registered org.netbeans.spi.debugger.ActionProviders. It contains mapping between action constant and ActionProvider registerred for this constant. For example:

instance of DebuggerEngine which represents JPDA debugger contains mapping:
ActionsManager.ACTION_STEP_INTO --> JPDAStepIntoActionProvider

How to implement and register some debugger action:
public class JPDAStepIntoAction extends ActionsProviderSupport {

    JPDAStepIntoAction () {
        jpdaDebugger.add...Listener (
            new Listener () {
                public ...event () {
                    // set state of action here
                    setEnabled ( state );
                }
            }
        );
    }
    public boolean doAction (Object action) {
        // put implementation of action here
        return true; // action successful
    }
}
And JPDAStepIntoAction should be registerred in file:
META-INF/debugger/{DebuggerEngineTypeID}/org.netbeans.spi.debugger.ActionsProvider

Following two diagrams will show how the action system works:

Diagram 1 - what happens when user press Step Into Action:
  1. StepIntoAction calls ActionsManager.doAction(Object) for ActionsManager.ACTION_STEP_INTO, when its invoked by the user.
  2. ActionsManager finds proper ActionsProvider registered for given action. Than it calls ActionsProvider.doAction(Object).
  3. ActionsManager notifies all ActionsManagerListeners about it, when the action is done.
 user            StepIntoAction                                 DebuggerEngine                       StepIntoActionProvider                   DebuggerEngineListener
              (javax.swing.Action)                                    |                                 (ActionsProvider)                                |
                       |                                              |                                         |                                        | 
  o  press  ->  actionPerformed (...)                                 |                                         |                                        |
 _|_ action          calls                                            |                                         |                                        |
  |  button     currentDebuggerEngine.         -->       doAction (ACTION_STEP_INTO)                            |                                        |
 / \                doAction                                          |                                         |                                        |
                (ACTION_STEP_INTO)                           finds ActionsProviders                             |                                        |
                       |                                   registerred for given action        -->   doAction (ACTION_STEP_INTO)                         |
                       |                                    and calls doAction on them                  implementation of                                |
                       |                                              |                               Step Into Action is here                           |
                       |                                              |                        <--              |                                        |
                       |                                  fires PROP_ACTION_PERFORMED                           |                                        |
                       |                                              |                        -->             -|->                              actionPerformed (..)
                       |                                              |                                         |                                  listener impl.
                       | <--                                        <-|-                                      <-|-                                    <--|
                       |                                              |                                         |                                        |

Diagram 2 - what happens when the state of Step Into Action is changed:
  1. Debugger implementation should recognize that the state of Step Into action should be changed, and it should notify StepIntoActionProvider about it.
  2. StepIntoActionProvider should fire ActionsProviderListener.actionStateChange(Object,boolean) for ActionsManager.ACTION_STEP_INTO.
  3. DebuggerEngine is listenning on all installed ActionsProviders and fires all action state changes using org.netbeans.api.debugger.DebuggerEngineListener#actionStateChanged(Object,boolean).
  4. StepIntoAction listens on DebuggerEngine, and it updates its state when some actionStateChanged is fired.
      debugger    StepIntoActionProvider          DebuggerEngine.ActionsProviderListener                StepIntoAction.DebuggerEngineListener
                     (ActionsProvider)                            |                                           (javax.swing.Action)                 
                            |                                     |                                                    |
   _  state of   ->  fire action state                            |                                                    |
  |?|  action            change           -->   actionStateChange (ACTION_STEP_INTO, enabled)                          |
   ¯  should be             |                                     |                                                    |
      changed               |                         fire DebuggerEngineListener                                      |
                            |                            actionStateChanged                   -->             actionStateChanged
                            |                                     |                                             updates a state
                            |                                     |                                                of action
                            |<--                                <-|-                          <--                      |

Overview   Package  Class  Use  Tree  Deprecated  Index  Help 
org.netbeans.api.debugger/1 1.11
 PREV PACKAGE   NEXT PACKAGE FRAMES    NO FRAMES    
Built on May 28 2007.  |  Portions Copyright 1997-2007 Sun Microsystems, Inc. All rights reserved.