| Home >> All >> org >> jboss >> mx |
| • | org.jboss.mx.capability.* (4) | • | org.jboss.mx.interceptor.* (12) | • | org.jboss.mx.loading.* (32) |
| • | org.jboss.mx.logging.* (19) | • | org.jboss.mx.metadata.* (13) | • | org.jboss.mx.modelmbean.* (4) |
| • | org.jboss.mx.persistence.* (3) | • | org.jboss.mx.server.* (10) | • | org.jboss.mx.service.* (1) |
| • | org.jboss.mx.util.* (22) |
Package Samples:
• org.jboss.mx.util.propertyeditor: Utilities for the Java Management Extentions API.
• org.jboss.mx.logging.log4j: The JBossMX logging framework .
• org.jboss.mx.capability
• org.jboss.mx.interceptor
• org.jboss.mx.loading
• org.jboss.mx.logging
• org.jboss.mx.logging.file
• org.jboss.mx.metadata
• org.jboss.mx.modelmbean
• org.jboss.mx.persistence
• org.jboss.mx.server
• org.jboss.mx.server.registry
• org.jboss.mx.service
• org.jboss.mx.util
Classes:
• MBeanServerImpl: MBean server implementation. This is the default server implementation returned by the MBeanServerFactory class ( DEFAULT_MBEAN_SERVER_CLASS 55 ). The MBean server behaviour can be further configured by setting the following system properties: jbossmx.loader.repository.class ( LOADER_REPOSITORY_CLASS_PROPERTY 55 ) jbossmx.mbean.registry.class ( MBEAN_REGISTRY_CLASS_PROPERTY 55 ) jbossmx.required.modelmbean.class ( REQUIRED_MODELMBEAN_CLASS_PROPERTY 55 ) The loader repository is used for managing class loaders in the MBean server. The default repository uses the BasicLoaderRepository implementation ...
• MBeanInstaller: MBean installer utility This installer allows MLet to install or upgrade a mbean based on the version specified in the MLet conf file. If the mbean version is newer than the registered in the server, the installer unregisters the old mbean and then registers the new one. This management needs to store the mbean version into the MBeanRegistry in the server. When we register mbeans, however, we can't pass the metadata to MBeanServer through the standard JMX api because Both of createMBean() and registerMBean() have no extra arguments to attach the metadata. Thus we call MBeanServer#invoke() directly ...
• MetaDataBuilder: The MetaDataBuilder interface defines the contract between the Model MBean and a metadata builder implementation. The metadata builder implementations can extract the MBean management interface definition from a given data source and construct the corresponding JMX MBeanInfo object instances that define the Model MBean. This interface also defines accessor methods for setting properties which can be used to configure the builder implementations. See setProperty(java.lang.String, java.lang.Object) 55 and getProperty(java.lang.String) 55 methods for more information.
• StandardMetaData: This metadata builder implementation builds a MBean info based on the naming rules of the Standard MBeans. The MBean server uses this builder to generate the metadata for Standard MBeans. In cooperation with the MBeanInfoConversion 55 class you can use this builder as a migration tool from Standard to Model MBeans, or for cases where you want the management interface be based on a compile-time type safe interface. It is also possible to subclass this builder implementation to extend it to support more sophisticated introspection rules such as adding descriptors to management interface elements ...
• UnifiedClassLoader2: An extension of UnifiedClassLoader that only allows a single thread into its UnifiedLoaderRepository2 by seperating the threads attempting class loading through it and the single thread active in the UnifiedLoaderRepository2 by registering a delegate UnifiedClassLoader with the UnifiedLoaderRepository2 rather than itself. Thus it does not matter how locked up this instance may be by the VM since the calling thread has to acquire a singleton lock to get into the UnifiedLoaderRepository2, and once in, that thread can never interact with any UnifiedClassLoader2, including the instance originating ...
• UnifiedClassLoader: A ClassLoader which loads classes from a single URL in conjunction with the LoaderRepository . Notice that this classloader does not work independently of the repository. A repository reference must be provided via the constructor or the classloader must be explicitly registered to the repository before any attempt to load a class. At this poin this is little more than an abstract class maintained as the interface for class loaders as the algorithm of the UnifiedLoaderRepository fails with deadlocks, and several other class loading exceptions in multi- threaded environments.
• ObjectNameConverter: Converts forbidden characters in the key and value of an object name to valid characters and back. Character Conversion Table: (based on RFC 1738 style escapes '%' => '%25' '*' => '%2a' ',' => '%2c' ':' => '%3a' '?' => '%3f' '=' => '%3d' Thanx to William Hoyle for mention this Attention: When you have a comma in one of your property value then you have to use a Hashtable to provide the properties otherwise the property parsing will fail.
• LoggerManager: The log manager. Ideally, there should be only one of these. In practice there can be one per classloader provided they are diffent scopes. This manager is mainly responsible for controlling logging contexts. This involves using a LoggerContextSelector to determine a LoggerContext. All requests are then delegated to that context. These are main management areas. Creating loggers. Specifying configuration. Querying. A pluggable LoggerContextSelector.
• DefaultLoggerContextSelector: The default context selector. This has singleton context configured initially configured with the default logger adapter implementation. Extra contexts can be registered keyed by classloader. When new loggers are requested, the thread's context classloader is checked to discover if there is a special context. If that fails the parent is checked and that its parent, etc. If none of the classloaders has a special logging context, the default logging context is used.
• LoggerContext: A logger context. The logger context holds the state for loggers in within its context. It delegates most implementation to the registered LoggerAdapterFactory, this allows different logging implementations in different contexts. It allows the logging implementation to vary configuration according to context. The processing performed within this class is the "hot-swapping" of implementations and the querying of the state.
• MBeanRegistry: Implementations of this interface can be plugged into the MBeanServer, to control the registration and deregistration of MBeans The registry can expose itself for management under the object name defined the name defined in org.jboss.mx.server.ServerConstants When this is the case, the MBeanServer will perform the register/unregister operations dynamically.
• OptimizedMBeanDispatcher: Byte code optimized dispatcher for Standard MBeans. This dispatcher generates an invoke implementation that handles the operation dispatching without Java reflection. The use of this dispatcher may be controlled by setting a OPTIMIZE_REFLECTED_DISPATCHER 55 property to either "true" or "false" string value.
• AttributeOperationResolver: AttributeOperationResolver is a modified TST for mapping an Integer code against attribute and operation keys. Note that this implementation was chosen to allow fast resolution of compound keys - namely the operationName and signature[] passed to an MBean's invoke() method. For consistency it also keeps track of attribute names (which are a single key), although for those a hashmap would have done just as well.
• MethodMapper: Helper class for resolving JMX *Info objects against Method objects. It's typically used during the construction of dispatchers during MBean registration/creation. If you're looking for a fast resolver of JMX operation signatures see AttributeOperationResolver. FIXME - this class is not aware of multiple target objects (as in modelmbeans) however I'm half expecting that feature to disappear in JMX 1.1 anyhow.
• ObjectStreamPersistenceManager: Object Stream Persistence Manager. Persists the MBean to the file system using an Object Stream. Includes code based on examples in Juha's JMX Book. Object Streams written to disk are admittedly lacking in the area of "long-term", "portable", or "human-readable" persistence. They are fairly straightforward, however. Primarily, this class is useful for demonstration and "quick & dirty" persistence.
• BasicLoaderRepository: Implements a simple classloader repository for the MBean server. The basic loader repository uses an unordered list of classloaders to try and load the required class. There is no attempt made to resolve conflicts between classes loaded by different classloaders. A thread's context class loader is always searched first. Context class loader is not required to be registered to the repository.
• MBeanProxyExt: A factory for producing MBean proxies. Created proxies will also implement MBeanProxyInstance allowing access to the proxies configuration. Revisions: 20020321 Adrian Brock: Don't process attributes using invoke.
• ObjectInputStreamWithClassLoader: This replaces the EjbossInputStream in the storage package. The input stream will take a class loader in its constructor and look into it to retrieve the class definitions. It is used throughout the server to deserialize parameters and objects whose definition are in a jar and not the global classpath It also has better comments than the previous version.
• ThreadPool: A simple thread pool. Idle threads are cached for future use. The cache grows until it reaches a maximum size (default 10). When there is nothing in the cache, a new thread is created. By default the threads are daemon threads. Rickard Öberg Adrian Brock
• UnifiedLoaderRepository3: A repository of class loaders that form a flat namespace of classes and resources. This version uses UnifiedClassLoader3 instances. Class and resource loading is synchronized by the acquiring the monitor to the associated repository structure monitor. See the variable javadoc comments for what monitor is used to access a given structure.
• UnifiedLoaderRepository4: A repository of class loaders that form a flat namespace of classes and resources. This version uses UnifiedClassLoader4 instances. Class and resource loading is synchronized by the acquiring the monitor to the associated repository structure monitor. See the variable javadoc comments for what monitor is used to access a given structure.
• ObjectNameFactory: A simple factory for creating safe object names. This factory will not throw MalformedObjectNameException. Any such exceptions will be translated into Errors. This should only be used where it is not possible to catch a MalformedObjectNameException, such as when defining a static final in an interface.
• HeirarchicalLoaderRepository3ConfigParser: The LoaderRepositoryConfigParser implementation for the HeirarchicalLoaderRepository3. This implementation supports the single java2ParentDelegation property which indicates whether the HeirarchicalLoaderRepository3 should load classes from its scope first followed by its parent repository (java2ParentDelegation=true).
• SchedulableRunnable: A schedulable runnable. Subclasses should implement doRun() to do some real work. setScheduler(RunnableScheduler) has to be invoked with a RunnableScheduler that has been started for the work to be performed. If the doRun() does not invoke setNextRun(), the link to the scheduler is removed.
• Logger: The logger. It provides a standard interface based on log4j or java.util.logging package. This does no work itself, instead it delegates to the real implementation via a LoggerAdapter. The LoggerAdapter is initially set at creation, however it can be hot-swapped at any time.
| Home | Contact Us | Privacy Policy | Terms of Service |