Peter Donald wrote:
On Thu, 13 Dec 2001 13:47, Peter Royal wrote:
It looks like you read over it before Berin incorporated changes from our
exchange... might want to go back and look again :)
* kinda related to above but is there a way for the container to
associate "context" information with a point. ie a Point may say it is
measuring variable X but the container may prepend this with
"myContainer.myComponentName."
Each ProfilePoint has a string name associated with it.
Right - but can the parent add to that name to give it context. So just say
we have two pools with identical properties except for their name (which is
managed by container). Is there a way for container to inject name into
profile point name.
Ok. Pete Royal (man, two Peters :) had a proposal that the Profilable
would also have a name. In essence, this would allow a grouping to happen.
Let's take the ExcaliburComponentManager as an example. It is a Container
that has several Components, that can also be containers. If the Profilable
had a getName() parameter, that name would apply to all of it's ProfilePoints
as a grouping. So for instance, going to the PoolableComponentHolder
implementation,
it would have all the ProfilePoints for the ObjectFactory and the Pool.
It would supply a name for that particular group of ProfilePoints.
The problem with this (other than the fact that ProfilePoints already have
a name associated with them), is that when a Profilable object has a group
of Profilable objects. In this case, the profiling tool is opaque. You cannot
go beyond one level.
The question comes then should all Components have a name set by the Container?
If so, then the Component interface should have a setName() interface.
If not, then the Profilable interface should be able to have a setName() method.
I lean toward the second, although you are at the mercy of the Component/Object
being profiled to respect that name and use it in it's ProfilePoints. This is
also important to track instance specific data. For instance, if we discovered
that the ECM was generating more than one JdbcConnection object for a connection
name, then we would have to track all the activities of each of the instances.
So if the "Profilable" interface was changed to add the setName(), we could
implement something like this:
interface Profilable {
void setName( String name );
// ..... skip other already declared methods .....
}
The ComponentManager when created will be given a name (setName):
ecm.setName("Root");
It would then go through all of it's ComponentHolders (if they implement
Profilable),
and call setName() for them:
Iterator i = m_components.keySet().iterator();
while (i.hasNext())
{
String name = (String) i.next();
Profilable holder = (Profilable) m_components.get( name );
holder.setName( m_name + "." + name);
}
And in turn, the ComponentHolders (assuming they are made Profilable) will
create the
actual ProfilePoints like this:
point = new CurrentValueProfilePoint( m_name + ".Pool: Current number of active
components" );
It is easy to enforce this on the small scale, but what if the setName()
method is never called?
It is not an official lifecycle service, and is likely to be missed. Another
option is to allow
Components to be instantiated with a single argument constructor (a String for
the name). This
does make the ObjectFactory more complicated, but it allows the process to
happen wether there
is a name provided or not.
Of course we could also specify that the semantics of the setName() method *if*
called serves
only to override the name attributed to a Profilable object.
What are your feelings on the subject?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
