|
Copyright @ 2001 SAP. All Rights Reserved. | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||||||
Interface which has to be implemented by the component owner if component specific monitor properties should be handled via JARM. For a detailed description of the API see below. Here an overview about the control flow of the component specific property handling is given
Step 1: You have to provide an implementation of this interface
(ICompProperties) for each component for which you want to collect
specific information
Step 2: Collect specific data for a component (see IMonitor API)
- this is done when data is collected for a request
- provide an object of a class which implements this interface for
each component with specific properties (use method setCompProps()
of class ConfMonitor)
- provide component specific properties (equals to the parameter dataSingle;
see method condenseData() below) (use method endComponent() of the
IMonitor interface)
- JARM collects this data if the parameter jarm/comp/properties/set/switch
equals 'on'. This parameter is also used for condensing the data (step 3).
'on' is the default value.
Step 3: Accumulation of component specific data
- after a request has ended JARM automatically condenses the collected
data (-> parameter dataCondensed in method condenseData() below)
- for each component for which component specific data was provided
and for which an implementation of this interface exists the method
condenseData() is called
Step 4: get component specific data out of JARM
- the calls of OverviewMonitor which deliver a RequestOverview or
ComponentOverview uses the methods getDataCondensed() / getDataSingle()
of this interface to return the component specific data via a
properties object.
The property values are returned only if the parameter
jarm/comp/properties/get/switch = on (is default).
| Method Summary | |
java.lang.Object |
condenseData(java.lang.Object dataSingle,
java.lang.Object dataCondensed)
when a request is condensed this method is called for all components with individual properties implementing this method you have to fulfill following requirements - the method has to be thread safe -> synchronize it - dataCondensed could be null (normally if the first call is done) -> create new object in that case if you want to condense data - provide an efficient implementation because this method might be called very often: - avoid creating objects (exception: first creation of condensed data object) - modify dataCondensed directly and return this object - the data types of dataSingle and dataCondensed should be simple structures with basic data types wherever possible - dataSingle must not be manipulated guaranteed: dataSingle ! |
java.util.Properties |
getDataCondensed(java.lang.Object dataCondensed)
when a component overview has to be provided this method is called if there are component specific condensed properties in order to transform these properties into a component independant form implementing this method you have to fulfill following requirements - the method has to be stateless - dataCondensed must not be manipulated - if you want to have consistent data be aware that there could be condenseData() calls in parallel -> synchronize it - be aware that there could be parallel getDataCondensed() calls guaranteed: dataCondensed ! |
java.util.Properties |
getDataSingle(java.lang.Object dataSingle)
when a request overview has to be provided this method is called for all components with individual properties to transform the properties into a component independant form implementing this method you have to fulfill following requirements - dataSingle must not be manipulated - be aware that there could be parallel getDataSingle() calls no synchronization with other calls necessary because there can't be a conflict with setting dataSingle (is done in endComponent() of IMonitor) guaranteed: dataSingle ! |
| Method Detail |
public java.lang.Object condenseData(java.lang.Object dataSingle,
java.lang.Object dataCondensed)
implementing this method you have to fulfill following requirements
- the method has to be thread safe -> synchronize it
- dataCondensed could be null (normally if the first call is done)
-> create new object in that case if you want to condense data
- provide an efficient implementation because this method might be
called very often:
- avoid creating objects (exception: first creation of condensed data object)
- modify dataCondensed directly and return this object
- the data types of dataSingle and dataCondensed should be simple structures
with basic data types wherever possible
- dataSingle must not be manipulated
guaranteed: dataSingle != null
dataSingle - data collected for a single component calldataCondensed - data already consensed for the component; could be nullpublic java.util.Properties getDataSingle(java.lang.Object dataSingle)
implementing this method you have to fulfill following requirements - dataSingle must not be manipulated - be aware that there could be parallel getDataSingle() calls no synchronization with other calls necessary because there can't be a conflict with setting dataSingle (is done in endComponent() of IMonitor) guaranteed: dataSingle != null
dataSingle - data collected for a single component callpublic java.util.Properties getDataCondensed(java.lang.Object dataCondensed)
implementing this method you have to fulfill following requirements - the method has to be stateless - dataCondensed must not be manipulated - if you want to have consistent data be aware that there could be condenseData() calls in parallel -> synchronize it - be aware that there could be parallel getDataCondensed() calls guaranteed: dataCondensed != null
dataCondensed - data condensed for a component
|
Copyright @ 2001 SAP. All Rights Reserved. | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||||||