Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

org.apache.bsf.dbline.* (7)org.apache.bsf.debug.* (43)org.apache.bsf.engines.* (25)
org.apache.bsf.util.* (45)

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


Package Samples:

org.apache.bsf.util.event.adapters
org.apache.bsf.util.event.generator
org.apache.bsf.util.event
org.apache.bsf.util.cf
org.apache.bsf.util.type
org.apache.bsf.util
org.apache.bsf.engines.activescript
org.apache.bsf.engines.jacl
org.apache.bsf.engines.javascript
org.apache.bsf.engines.xslt
org.apache.bsf.engines.jpython
org.apache.bsf.engines.netrexx
org.apache.bsf.engines.jython
org.apache.bsf.engines.javaclass
org.apache.bsf.engines.java
org.apache.bsf.debug.serverImpl
org.apache.bsf.dbline
org.apache.bsf.debug.meta
org.apache.bsf.debug.jsdi
org.apache.bsf.debug.util

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 ...
JavaEngine: This is the interface to Java from the Bean Scripting Framework. The Java code must be written script-style -- that is, just the body of the function, without class or method headers or footers. The JavaEngine will generate those via a "boilerplate" wrapper: import java.lang.*; import java.util.*; public class $$CLASSNAME$$ { static public Object BSFJavaEngineEntry(org.apache.bsf.BSFManager bsf) { // Your code will be placed here } } $$CLASSNAME$$ will be replaced by a generated classname of the form BSFJava*, and the bsf parameter can be used to retrieve application objects registered with the ...
NetRexxEngine: This is the interface to NetRexx from the Bean Scripting Framework. The NetRexx code must be written script-style, without a "class" or "properties" section preceeding the executable code. The NetRexxEngine will generate a prefix for this code: class $$CLASSNAME$$; method BSFNetRexxEngineEntry(bsf=org.apache.bsf.BSFManager) public static; $$CLASSNAME$$ will be replaced by a generated classname of the form BSFNetRexx*, and the bsf parameter can be used to retrieve application objects registered with the Bean Scripting Framework. If you use the placeholder string $$CLASSNAME$$ elsewhere in your script ...
BreakPoint: Materializes a breakpoint. A breakpoint can be defined at a line number or an offset character in its document. For JavaScript, we only support lineno for the underlying Rhino engine does support only the line numbers. Note: this is unfortunate for this prevents setting a breakpoint on different statements on the same line... A breakpoint is remembered at either the document level (DocumentCell) or the function/script level (FnOrScript). It is remembered at the document level when a FnOrScript is not yet known for the breakpoint line number. When a matching FnOrScrip will become known (compiled ...
BSFManager: This class is the entry point to the bean scripting framework. An application wishing to integrate scripting to a Java app would place an instance of a BSFManager in their code and use its services to register the beans they want to make available for scripting, load scripting engines, and run scripts. BSFManager serves as the registry of available scripting engines as well. Loading and unloading of scripting engines is supported as well. Each BSFManager loads one engine per language. Several BSFManagers can be created per JVM. Each BSFManager and engine participate in the debugger framework. Per ...
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 ...
DocumentCell: A document cell materializes a known document. A document is a container for scripts or functions in JavaScript. The document is known as soon as a function or script is compiled in the engine. Compilation occurs as a side-effect of evaluating or executing a function or a script. Upon the first loading of a function or script of a document, the document becomes known and the debug manager is notified of the load. The debug manager will in turn notify the engine of all the known breakpoints for that document. When a breakpoint is propagated from the debug manager to an engine, the document will ...
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, ...
FnOrScript: This class represents a function or script, that is, a piece of a document that is provided to the JavaScript engine for evaluation, execution, or simply compilation. A FnOrScript represents a range of lines or characters in its document. For now, Rhino only supports ranges of lines, really, but the code for offsets is there anyway. Warning: Offsets have never been quite tested yet... A FnOrScript has compilation units. When Rhino compiles a function or a script, even in interpreted mode where the compilation is done to JavaScript bytecode, it calls back its debugger with different compilation ...
BreakPoint: This is a class for the debug manager to remember a breakpoint. Breakpoints are set globally to a JVM, that is, globally to all BSFManager/BSFEngine created in the JVM. A breakpoint is either at a line (defined by '\n') or an (char) offset in a document. NOTE: There is no correspondance so far... so for instance, if a breakpoint is defined at an offset, it cannot be manipulated later as defined with a line, although conceptually there is an equivalence between lines and offsets. A document is for instance a JSP in Tomcat/Jasper framework. Its name is given when evaluating/executing a function or ...
CompilationUnit: A compilation unit is a Rhino concept. When a piece of script is provided for eval or execute to a Rhino engine, it is compiled down to either JavaScript or Java bytecode. In debug mode, only the compilation down to JavaScript bytecode is supported. During the compilation process, the original piece of script is sliced into compilation units. For instance, the script text may contain a function declaration and an expression to eval. The compilation will result in two compilation units: the function and the expression. Each compilation unit will correspond to a range of the lines of the original ...
EventAdapterRegistry: The EventAdapterRegistry is the registry of event adapters. If a desired adapter is not found, the adapter will be dynamically generated when lookup is attempted. Set the dynamic property to false to disable this feature. This implementation first looks for an adapter in its lookup table and if it doesn't find one looks for a standard implementation of that adapter in the org.apache.bsf.util.event.adapters package with a standard naming convention. The naming convention it assumes is the following: for event listener type a.b.c.FooListener , it loads an adapter of type org.apache.bsf.util.event.adapters.a_b_c_FooAdapter ...
BSFEngine: This is the view of a scripting engine assumed by the bean scripting framework. This interface is used when an application decides to run some script under application control. (This is the reverse of the more common situation, which is that of the scripting language calling into the application.) When a scripting engine is first fired up, the initialize() method is called right after construction. A scripting engine must provide two access points for applications to call into them: via function calls and via expression evaluation. It must also support loading scripts. A scripting engine is a property ...
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.
EventAdapter: EventAdapter is the interface that all event adapters must implement in order to work with the automatic event adapter generation model. This interface requires that the adapter implement a method that allows setting the event processor delegated to process the event after the adapter has received the event from the event source. The task of any event adapter is to receive the event and then delegate it to the event processor assigned to it, using either eventProcessor.processEvent or eventProcessor.processExceptionableEvent.
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.
Buffer: A buffer represents a document such as a JSP. Note that lines start at zero, so the first line has a line number of zero. A document is described by its URI as known in the servlet engine. The URI includes the Web application prefix. For instance: /examples/jsp/cal/cal1.jsp with /examples being the application prefix. Note: the name is the shortname, that is, the last name of the URI. This allows easy manipulation from the command line in the debugger.
ActiveScriptEngine: This is the interface to active scripting engines from the Bean Scripting Framework. This code uses John Ponzo's IBM Active Scripting Toolkit to tie in active scripting engines to BSF. This class implements Runnable to create a thread. This thread is to exclusively access the scripting engine. All methods from this class to the engines is proxied over to the engine thread for execution. Why? Because, MS engines are implemented to only be accessed from ONE thread.
CFDriver: This is an example of how a CodeFormatter bean can be used. The CFDriver is a stand-alone tool that will instantiate a CodeFormatter bean, configure it according to your command-line arguments, and invoke the formatting. Since the default source of input is stdin , and the default target for output is stdout , a CFDriver can also be used as a filter.
CodeFormatter: A CodeFormatter bean is used to format raw Java code. It indents, word-wraps, and replaces tab characters with an amount of space characters equal to the size of the indentationStep property. To create and use a CodeFormatter , you simply instantiate a new CodeFormatter bean, and invoke formatCode(Reader source, Writer target) with appropriate arguments.
DocumentCell: A DocumentCell allows the debug manager to keep track of known documents for which it has breakpoints. When a debugger sets a breakpoint, it specifies a document. This is when a DocumentCell is created for that document (identified through its URI). The debug manager will keep the document cells at least as long as there is breakpoints known and as long as there are engines known to currently execute the document.
BreakPoint: This class instances represent breakpoints as known by the client debugger. This is fairly straightforward code. Note the simple but efficient allocation scheme for breakpoint identifiers. Whatever scheme is used, these identifiers should remain unique throughout an entire debug session. Note also that these breakpoins are only supporting a definition based on line numbers, char offsets are not supported.

Home | Contact Us | Privacy Policy | Terms of Service