> Original Message from Wed, 12 Dec 2001 17:32:37 -0500:>
> On Wednesday 12 December 2001 05:11 pm, you wrote:
> > I really want to keep the Profiler as isolated from the
Profilable class as
> > possible. In order for it to be effective, the Profilable class
must be
> > able to function without the existance of the Profiler, but
expose the
> > profiling information when needed.
>
> Agree. How about also providing a getName() on Profilable, thus
eliminating
> the need to make ProfilePoint.getName() be something like "Pool:
Max Size".
Each ProfilePoint is a unique sample type. By placing the name at
the Profilable interface level, it becomes almost impossible to
distinguish which sample is significant.
The Profilable object instantiates the ProfilePoint's names to be
more meaningful than "Pool: Max Size" because ther can be more than
one Pool in a system. For instance, if the Pool is managing
FileGenerator instances, a good name would be "{classname} Pool: Max
Size".
It is easy for a pool to implement such a naming scheme without it
being hardcoded.
> > BTW, what is the thought on the "serialize(File)" method?
> >
> > The more I look at that, the less I like it. The question is,
should this
> > be a method directly set by a container, or should this be a
configurable
> > item?
>
> It doesn't give me a warm fuzzy. I think your comment helped on
that, as why
> make a Profiler subclass just for a different output format? Also
I'm not
> sure if Configuration objects are the right output for this either.
>
> My gut feeling is to expose two methods,
>
> String[] getProfilePoints()
> int[][] getProfileData()
>
> but I know that's not optimal either.
Probably not.
> Perhaps another class such as a ProfileSerializer, so you have
>
> Profiler.serialize( ProfileSerializer serializer );
>
> and
>
> interface ProfileSerializer
> {
> void setColumns( String[] columns );
>
> void setPoints ( int timestamp, int[] values );
> }
This is more in line with the SEDA profiler. It moved in the
opposite direction though (i.e. getProfilerGraph()). I didn't
like that approach to much.
The ProfileSerializer idea does resonate with me. Maybe I can
play with it tomorrow. The design constraints I see as optimal
on this is that Header information is serialized first, and
that each sample is serialized as it is received. The methods
you presented should be sufficient.
> And we can have concrete implementations of ProfileSerializer such
as
> CSVProfileSerializer, SAXProfileSerializer, JdbcProfileSerializer,
etc.
>
> Just thinking outloud. I may have had too much ioc/soc punch
today :)
Seriously though, I think this approach is best. The
ProfileSerializer does need a location to send it's information
though.
Oh, and regarding the question about AspectJ for this purpose:
AspectJ does not specify the architectural concerns that the profile
package creates. AspectJ is a great tool for retrofitting objects
that where not Profilable by design, but it would be a terrible hack
to rely on AspectJ for the entire Profile subsystem.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
