avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: New Profiler hooks
Date Thu, 13 Dec 2001 21:54:12 GMT
Peter Donald wrote:

> On Fri, 14 Dec 2001 08:08, Berin Loritsch wrote:
> 
>>The problem arrizes with how do we determine what the parent ProfilePoint
>>is?
>>
> 
> Same way as Logger, ComponentManager, Context, etc does.


Yes, but think Profilable.
The problem arrizes when there is no artifact passed in.


>>It does not make sense to have a Pool's max active ProfilePoint be the
>>parent of an ObjectFactory's number of created instances ProfilePoint. 
>>They represent something completely unique.
>>
> 
> eh? Could you rephrase ? ;)


For instance, ProfilePoints are unique sample types that are used by the
Profiler.  It does not make sense for two dissasociated ProfilePoints to
be forced into a heirarchy when they are inherently flat.


>>If this is going to scale, we *have* to make it happen at the Profilable
>>level. Remember, this is IoC, so a child Profilable is not going to have
>>access to the Parent's ProfilePoints at all.
>>
> 
> and a child Profilable should not directly create its top ProfilePoint, IOC 
> and all


Think of it in this manner (it doesn't *have* to be this hard you know):

Any Profilable that wants to publish it's ProfilePoints may do so.  The
Profilable object assigns names to all of it's ProfilePoints.  In heirarchical
situations, the Parent Profilable not only publishes its ProfilePoints, but
also those of it's children.  It also propogates the startProfiling() and
stopProfiling() methods to its children when they are called.

Seeing how the parent Profilable does not directly set the ProfilePoints'
names unless it originated from the Profilable, there must be a different
mechanism to propogate hierarchical names to the child Profilables.


>>>and the name would be set via
>>>
>>>parent.getName() + myName
>>>
>>>however the method getName() would be protected, package or private
>>>access (depending on what we could get away with) and done in the case
>>>class.
>>>
>>I don't like this, as it is Subversion of Control.  A child should not have
>>a direct reference to it's parent.  The name has to come from being
>>assigned, or we trust the Component to use proper "divination" to generate
>>a meaningful name.
>>
> 
> why can't it operate like all our other hierarchial aspects?


Our other hierarchical aspects have artifacts that are passed down to the
children, as opposed to passed up to the Profiler.  We are in essence
exposing the inner workings of an object in a controlled manner.

The only other way I can think of providing this functionality would be
to have YAI (Yet Another Interface) to mark a ProfilableContainer.  In
this case, the ProfilableContainer can expose the Profilables directly.
The ProfilableContainer would have a getName(), the Profilable would have
a getName(), and the ProfilePoints() would have a getName().

The last possible way is to have a getChildProfilables() in the Profilable
interface with the Profilable having a getName().

The Profiler would then have to assemble the final names from the heirarchical
getNames().  Going back to the ECM example, the ECM would be Profilable,

Profilable[] group = ecm.getChildProfilables();

This can of course return an empty array.

This would produce a hierarchy of grouped names, and would require us to
rethink the actual ProfileReport's interface so as to maintain those groups
in the reports.




-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message