| Home >> All >> org >> apache >> geronimo |
Page 1 2 3 4
Package Samples:
org.apache.geronimo.tools.xmlbeans
org.apache.geronimo.tomcat
org.apache.geronimo.tomcat.connector
org.apache.geronimo.tomcat.realm
org.apache.geronimo.tomcat.valve
org.apache.geronimo.tomcat.util
org.apache.geronimo.validator
org.apache.geronimo.timer.jdbc
org.apache.geronimo.timer
org.apache.geronimo.timer.vm
org.apache.geronimo.webservices
org.apache.geronimo.webservices.jaxr
org.apache.geronimo.transaction.log
org.apache.geronimo.transaction.context
org.apache.geronimo.transaction.manager
org.apache.geronimo.transaction
org.apache.geronimo.tomcat.app
org.apache.geronimo.tomcat.deployment
Classes:
Configuration: A Configuration represents a collection of runnable services that can be loaded into a Geronimo Kernel and brought online. The primary components in a Configuration are a codebase, represented by a collection of URLs that is used to locate classes, and a collection of GBean instances that define its state. The persistent attributes of the Configuration are: its unique configId used to identify this specific config the configId of a parent Configuration on which this one is dependent a List of code locations (which may be absolute or relative to a baseURL) a byte[] holding the state of the GBeans ...
GenericSecurityRealm: A security realm that can be configured for one or more login modules. It can handle a combination of client-side and server-side login modules for the case of remote clients, and it can auto-role-mapping for its login modules (though you must configure it for that). To configure the list of LoginModules, set the loginModuleConfiguration to a Properties object with syntax like this: LoginModule.1.REQUIRED=ObjectName1 LoginModule.2.SUFFICIENT=ObjectName2 ... Each ObjectName should identify a LoginModuleGBean in the server configuration. Each LoginModuleGBean has the configuration options for its ...
Data: An object capable of holding the state of multiple applications and tiers. This will be a Map of tiers (web, ejb, ...). Each tier may choose how to organise it's own Map. e.g. Web tier will use a Map of webapps. Each webapp being represented by a Map of HttpSessionID:HttpSession. Assuming that all IDs where GUIDs, it would be posible to collapse all webapps together (and maybe all tiers), thus avoiding dehashing overhead with each lookup coming over the Cluster. I've considered this and decided that the extra partitioning of the data that I am doing, will result in much less contention on the Map ...
JettyEJBWebServiceContext: Delegates requests to a WebServiceContainer which is presumably for an EJB WebService. WebServiceContainer delegates to an EJBContainer that will ultimately provide the JNDI, TX, and Security services for this web service. Nothing stopping us from using this for POJOs or other types of webservices if shared Context (JNDI, tx, security) wasn't required to be supplied by the web context. From a 10,000 foot view the Jetty architecture has: Container -> Context -> Holder -> Servlet A Container has multiple Contexts, typically webapps A Context provides the JNDI, TX, and Security for the webapp and ...
BasicKernel: The core of a Geronimo instance. A Kernel is responsible for managing the Configurations that comprise a Geronimo system and exposing them using JMX. Each Kernel is associated with an MBeanServer that is used to register the Configurations themselves and the MBeans they define. Dependencies between MBeans are handled by a dedicated DependencyManager that is responsible for tracking those dependencies and ensuring that the dependent objects follow the appropriate lifecycle and receive appropriate notifications. The Kernel also provides a ConfigurationStore which is used to stage installed Configurations ...
InvocationResult: The result of an Invocation. There are two types of result: normal - indicating the operation completed normally (e.g. the method returned) exception - indicating the operation completed abnormally (e.g. the method threw a checked exception) Note that these should both be considered a normal completion of the operation by the container. Abnormal completions, such as a RuntimeException or Error from the invocation, or any problem in the interceptor chain itself, should result in a Throwable being thrown up the chain rather than being contained in this result. This distinction mirrors the semantics ...
ReadOnlyContext: A read-only Context in the java: namespace. This version assumes it and all its subcontext are read-only and any attempt to modify (e.g. through bind) will result in an OperationNotSupportedException. Each Context in the tree builds a cache of the entries in all sub-contexts to optimise the performance of lookup. This implementation is intended to optimise the performance of lookup(String) to about the level of a HashMap get. It has been observed that the scheme resolution phase performed by the JVM takes considerably longer, so for optimum performance lookups should be coded like: Context componentContext ...
POJOWebServiceServlet: Delegates requests to a WebServiceContainer which is presumably for a POJO WebService Nothing stopping us from using this for EJBs or other types of webservices other than it is more than we need. EJB webservices use the JettyEJBWebServiceContext. From a 10,000 foot view the Jetty architecture has: Container -> Context -> Holder -> Servlet A Container has multiple Contexts, typically webapps A Context provides the JNDI, TX, and Security for the webapp and has many Holders A Holder simply wraps each Servlet The POJO Web Service architecture on Jetty looks like this: Container -> WebApp Context -> ...
TransactionCachingInterceptor: TransactionCachingInterceptor.java TODO: This implementation does not take account of unshareable resources TODO: This implementation does not take account of application security where several connections with different security info are obtained. TODO: This implementation does not take account of container managed security where, within one transaction, a security domain boundary is crossed and connections are obtained with two (or more) different subjects. I suggest a state pattern, with the state set in a threadlocal upon entering a component, will be a usable implementation. The afterCompletion ...
ConnectionTrackingCoordinator: ConnectionTrackingCoordinator tracks connections that are in use by components such as EJB's. The component must notify the ccm when a method enters and exits. On entrance, the ccm will notify ConnectionManager stacks so the stack can make sure all connection handles left open from previous method calls are attached to ManagedConnections of the correct security context, and the ManagedConnections are enrolled in any current transaction. On exit, the ccm will notify ConnectionManager stacks of the handles left open, so they may be disassociated if appropriate. In addition, when a UserTransaction ...
LocalEntityResolver: Implementation of EntityResolver that looks to the local filesystem. The implementation tries to resolve an entity via the following steps: using a catalog file using a local repository using JAR files in Classpath The catalog resolving is based on the OASIS XML Catalog Standard. OASIS seems to move it around. Try http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=entity and the list of documents currently at http://www.oasis-open.org/committees/documents.php?wg_abbrev=entity An older version may be at http://www.oasis-open.org/committees/entity/archives/spec-2001-08-01.html and see http://www ...
BasicDependencyManager: DependencyManager is the record keeper of the dependencies in Geronimo. The DependencyManager does not enforce any dependencies, it is simply a place where components can register their intent to be dependent on another component. Since a JMX Component can pretty much do whatever it wants a component must watch the components it depends on to assure that they are following the J2EE-Management state machine. The DependencyManager uses the nomenclature of parent-child where a child is dependent on a parent. The names parent and child have no other meaning are just a convience to make the code readable ...
JaasLoginCoordinator: A LoginModule implementation which connects to a Geronimo server under the covers, and uses Geronimo realms to resolve the login. It handles a mix of client-side and server-side login modules. It treats any client side module as something it should manage and execute, while a server side login module would be managed and executed by the Geronimo server. Note that this can actually be run from within a Geronimo server, in which case the client/server distinction is somewhat less important, and the communication is optimized by avoiding network traffic.
SinglePoolConnectionInterceptor: SinglePoolConnectionInterceptor chooses a single connection from the pool. If selectOneAssumeMatch is true, it simply returns the selected connection. THIS SHOULD BE USED ONLY IF MAXIMUM SPEED IS ESSENTIAL AND YOU HAVE THOROUGLY CHECKED THAT MATCHING WOULD SUCCEED ON THE SELECTED CONNECTION. (i.e., read the docs on your connector to find out how matching works) If selectOneAssumeMatch is false, it checks with the ManagedConnectionFactory that the selected connection does match before returning it: if not it throws an exception.
GBeanName: Class that represents the name for a GBean. A name is comprised of a domain combined with one or more properties. The domain is a fixed base name, properties qualify that as necessary. Two names are equal if they have the same name and the same properties. The String representation of a name can be written as domain:key1=value1,key2=value2,... Values are case sensitive, spaces are significant and there is no escaping mechanism; this is intended to be fast rather than allow lax syntax.
FileAuditLoginModule: Writes audit records to a file for all authentication activity. Currently doesn't perform too well; perhaps the file management should be centralized and the IO objects kept open across many requests. It would also be nice to write in a more convenient XML format. This module does not write any Principals into the Subject. To enable this login module, set your primary login module to REQUIRED or OPTIONAL, and list this module after it (with any setting).
WebServices: A dtd version of the J2EE webservices.xml file would look like this: webservices (webservice-description+) webservice-description (webservice-description-name, wsdl-file, jaxrpc-mapping-file, port-component+) port-component (port-component-name, wsdl-port, service-endpoint-interface, service-impl-bean, handler*) service-impl-bean (ejb-link|servlet-link) handler (handler-name, handler-class, init-param*, soap-header*, soap-role*)
DependencyManager: DependencyManager is the record keeper of the dependencies in Geronimo. The DependencyManager does not enforce any dependencies, it is simply a place where components can register their intent to be dependent on another component. The DependencyManager uses the nomenclature of parent-child where a child is dependent on a parent. The names parent and child have no other meaning are just a convience to make the code readable.
DeployTool: The main class for the CLI deployer. Handles chunking the input arguments and formatting help text and maintaining the list of individual commands. Uses a ServerConnection to handle the server connection and arguments, and a list of DeployCommands to manage the details of the various available commands. Returns 0 normally, or 1 of any exceptions or error messages were generated (whether for syntax or other failure).
DecouplingCallbackHandler: This callback handler separates the process of obtaining callbacks from the user from the process of providing the user's values to the login module. This means the JaasLoginService can figure out what callbacks the module wants and prompt the user in advance, and then turn around and pass those values to the login module, instead of actually prompting the user at the mercy of the login module.
SinglePoolMatchAllConnectionInterceptor: This pool is the most spec-compliant pool. It can be used by itself with no partitioning. It is apt to be the slowest pool. For each connection request, it synchronizes access to the pool and asks the ManagedConnectionFactory for a match from among all managed connections. If none is found, it may discard a random existing connection, and creates a new connection.
URLType: The URLType class assigns type to resources, i.e. files or URLs. The following types are available: UNPACKED_ARCHIVE - directory with META-INF/MANIFEST.MF PACKED_ARCHIVE - file with META-INF/MANIFEST.MF COLLECTION - directory with no META-INF/MANIFEST.MF RESOURCE - none of the above
SMTPTransportGBean: A GBean that provides for the configuration of a JavaMail SMTP transport protocol. SMTP transport properties that are common to all SMTP transports are provided via member variables of this class. Values that are set in the individual member variables will override any of the corresponding values that have been set in the properties set.
RawInvoker: The raw invoker provides a raw (fast) access invoke operations, get attribute values, and set attribute values on a GBean. This class should only be use by GBean proxy generators or carefully crafted container code, because this class maintains a hard reference to a gbeanInstance which has a huge potential for memory leaks. USE WITH CAUTION
IMAPStoreGBean: A GBean that provides for the configuration of a JavaMail IMAP message store protocol. IMAP store properties that are common to all IMAP stores are provided via member variables of this class. Values that are set in the individual member variables will override any of the corresponding values that have been set in the properties set.
| Home | Contact Us | Privacy Policy | Terms of Service |