avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@fztig938.bank.dresdner.net>
Subject Re: Profiler interfaces in scratchpad
Date Tue, 12 Feb 2002 17:32:40 GMT
On Tue, Feb 12, 2002 at 11:47:38AM -0500, Berin Loritsch wrote:
> Marcus Crafter wrote:
> >>
> >
> >	I would find it better in the interface - at least then it's a
> >	defined entry point into the profiler, and all implementations will
> >	use the same terminology.
> 
> We can make the Profiler extend the Startable interface to get it.

	ok. Sounds good to me.

> >	Might getName() conflict with other classes that could contain such a
> >	generic method name ? How about getProfilableName() or something
> >	else indicating it's use in profiling and that won't conflict
> >	another interface, eg. Router.getName() or Customer.getName(), or
> >	OperatingSystem.getName(), etc ?
> 
> It is considered bad practice for a Component to have a getName(), but I do
> see your point.  Can I ask you this:  Would it be reasonable to record the
> Customer name/Router name as the name in the ProfileReport?  I think so.
> That saves the implementor from writing a new method.

	I don't know. I'm not so convinced :) It could be that we're not
	actually in charge of what string getName() returns, and whether it's
	appropriate as the name for the profile report.
	
	And what if some poor class has a getName() method that doesn't even
	return a String but a char[], or a Name object or something even
	more esoteric ? Then it won't even compile :(

> >	Ok, I understand so far (I think :) ), but how do the profilable 
> >	point
> >	names get listed. addGroup() can't read them, and there
> >	doesn't seem to be any other method in ProfileReport to be able
> >	to specify them (or access from within the report
> >	via ProfilePoint.getName() ) ?
> 
> The Profiler sets the names in the addGroup() stage.  Remember, the groups 
> are set up in advance, and the ProfileReport remembers those values when 
> rendering the report.

	Ok, this is the part I found confusing. So addGroup() is used to
	set both the children profilable names, *and* the profile point
	names. The diagram:

     "Cocoon Container"            Is the group name
             |
  +----------+-----------+
  |          |           |
Cache"     "ECM"     "Sitemap"     Are the sub groups names
  |          |           |
misses"  "requests"  "500 Errors"  Are the profilable point names

	Would then actually be:

	report.addGroup("Cocoon Container", { "Cache", "ECM", "Sitemap" });
	report.addGroup("Cache", { "misses" });
	report.addGroup("ECM", { "requests" });
	report.addGroup("Sitemap", { "500 Errors" });

	Following an in-order traversal.

	And it's up to the reporting engine to differentiate between subgroup
	names and profilepoint names when organising and printing sample data.

	Ok. If what I've said above is right, I reckon I get it now. :)

	Cheers,

	Marcus

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:

--
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