Home >> All >> org >> apache >> bsf >> [ debug Javadoc ]

•	org.apache.bsf.debug.clientImpl.* (3)	•	org.apache.bsf.debug.jsdi.* (8)
•	org.apache.bsf.debug.meta.* (13)	•	org.apache.bsf.debug.serverImpl.* (3)
•	org.apache.bsf.debug.util.* (13)

• org.apache.bsf.debug: Javadoc index of package org.apache.bsf.debug.


Package Samples:

• org.apache.bsf.debug.serverImpl
• org.apache.bsf.debug.meta
• org.apache.bsf.debug.jsdi
• org.apache.bsf.debug.util
• org.apache.bsf.debug.clientImpl

Classes:

• BSFDebugManager: Debug Manager. This is a service for remote debuggers to gain access to remote debugging services on language engines. Currently, there is only one debugger supported per engine. However, multiple debuggers may register for different engines. There may be more than one engine per language given than more than one BSFManager can be instanciated within a Java virtual machine. Each debugger (instance of BSFDebugger) should first register itself to a debug manager running in the Java virtual machine in which debugging is intended. A debugger registers for a specific language, such as JavaScript. As ...
• ClientStubTable: This class provides the resident object table for the mirrors. A mirror represents a remote JavaScript object or any remote concept that needs to be identified such engines or contexts which are not JavaScript objects. A mirror has a unique identifier allocated on the server. This is called its oid, for object identifier. The oid is not only carrying the identity but also the type of the remote object. Knowing the type is essential when a mirror has to be created. For instance, it is important to know if a remote object is just an object or a reified code as a script or a function. The oid is a ...
• ServerStubTable: This class provides the resident object table for the mirrors. A Stub represents a remote JavaScript object or any remote concept that needs to be identified such engines or contexts which are not JavaScript objects. A Stub has a unique identifier allocated on the server. This is called its oid, for object identifier. The oid is not only carrying the identity but also the type of the remote object. Knowing the type is essential when a Stub has to be created. For instance, it is important to know if a remote object is just an object or a reified code as a script or a function. The oid is a long, ...
• StubTable: This class provides the resident object table for the mirrors. A Stub represents a remote JavaScript object or any remote concept that needs to be identified such engines or contexts which are not JavaScript objects. A Stub has a unique identifier allocated on the server. This is called its oid, for object identifier. The oid is not only carrying the identity but also the type of the remote object. Knowing the type is essential when a Stub has to be created. For instance, it is important to know if a remote object is just an object or a reified code as a script or a function. The oid is a long, ...
• BSFDebugger: This is the interface a client debugger has to implement in order to be able to register itself to the BSF debug manager. It is basically an event sink, allowing the debug manager to notify the debugger of relevant events. A debugger register itself for a specific language to the debug manager, but it may register itself several times. In an JSP/Eclipse situation where multiple languages may be debugged, there could be only one BSDFDebugger object registered for all relevant languages. Then for each engine, a language-specific debugger would be registered.
• JsEngine: Represents a remote engine as seen from the debugger. It matches the notion of global object in JavaScript specification. In other words, a JsEngine is an execution context rather than an explicit engine. This also means that a JsEngine is not multi-threaded, there is only one execution being carried. Hence, there is only one stack of JsContext for a JsEngine. The stack is only accesible if the engine is in a callback mode to the debugger, that is, the execution is stopped at a breakpoint or after a stepping order has completed.
• JsObject: This is interface that all objects in JavaScript must implement. The interface provides for the management of properties and for performing conversions. Host system implementors may find it easier to extend the ScriptableObject class rather than implementing Scriptable when writing host objects. There are many static methods defined in ScriptableObject that perform the multiple calls to the Scriptable interface needed in order to manipulate properties in prototype chains.
• IntHashtable: Hashtable associates keys with values. Keys and values cannot be null. The size of the Hashtable is the number of key/value pairs it contains. The capacity is the number of key/value pairs the Hashtable can hold. The load factor is a float value which determines how full the Hashtable gets before expanding the capacity. If the load factor of the Hashtable is exceeded, the capacity is doubled.
• JsCallbacks: This interface is the callback for the JavaScript debugger. IMPORTANT: JASON: it is likely to be modified when moving to the JDI-like event listening framework. IMPORTANT TWO: Missing support for watching objects.
• JsCode: This interface exposes debugging information from executable code (either functions or top-level scripts).
• JsFunction: Represents a function in the engine since JavaScript has code as first-class objects.
• IntHashMapEntry: HashMapEntry is an internal class which is used to hold the entries of a Hashtable.
• JsScript: Represents a script in the engine since JavaScript has code as first-class objects.
• JsdiException: Insert the type's description here. Creation date: (8/24/2001 8:52:25 AM)
• BSFConnect
• CircularBuffer
• ClientConnection
• JsContext
• JsEngineDispatcher
• JsCallbacksDispatcher
• JsCallbacksStub
• JsContextDispatcher
• DebugManagerStub
• JsObjectDispatcher
• DebuggerDispatcher

Home | Contact Us | Privacy Policy | Terms of Service