My problem is one of keeping the design clean. My view of Excalibur is that it sits in a domain higher than commons. I see Excalibur as being at an architcture level, and I see commons as being more at a foundation level. I hesitate to have a commons package "reach" up into a higher domain.
Having said that, I suspect there are packages in Excalibur that really ought to be at a foundation level, and there are packages in commons that ought to be at an architecture level. Perhaps pool should eventually be migrated to Excalibur. Perhaps better organization of Jakarta projects along domain lines would be appropriate. And perhaps I need to decide if a pooling package is really foundational (as I would label one in commons) or architectural (as I would label one in Excalibur) and have my application architecture based on the most appropriate domain. Perhaps the current reorg of Excalibur will make it easier for me to do this. However, for the present, I would like to make the pooler I'm better by adding statistics gathering. And for the present, the most expedient way I see to do that is the implementation I proposed. Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 9:51 AM > To: Jakarta Commons Developers List > Subject: Re: [pool] PROPOSAL: add collecting of statistics to > pool impleme ntations > > > Waldhoff, Rodney wrote: > >>I'd rather hear from the commons pool community as to whether my > >>proposal > > > > is > > > >>+1, and if not, what I can do to make it better from the community > >>standpoint. > > > > > > Can't speak for the "community", but I'm +1 on the idea. I > imagine a > > "wrapper" style implementation that allow one to collect stats on a > > arbitrary pool, right? > > > > Why not just *use* Excalibur Instrumentation? It does not > require using all of Avalon, it is light weight, and first > rate. Leif did a great job of balancing performance and > memory consumption. > > You don't have to use Excalibur pool impls, but the > instrumentation code would help in debugging any arbitrary > stat you want with graphs that you can view in real time. > There's nothing like being able to attach the GUI client to > an already *running* process, and then shutting down the > client without shutting down the server code. > > Talk about easing remote administration.... > > This is an area where I think that duplication might be a > wasteful activity. Sure, keep your pool implementation, but > provide a version that uses Excalibur Instrumentation if the > libs are included at compile time. > > There is *alot* that goes on behind the scenes, and to get to > where Instrumentation is, is going to take a while. We > started playing with the idea either early this year or late > last year--but didn't have anything working until about a > month or two ago. > > That is unless you *really* want to reinvent the wheel--which > I cannot stop. However, as the JMeter team can tell > you--memory leaks are a b*tch to track down in GUI apps. > > -- > > "They that give up essential liberty to obtain a little > temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > -- > To unsubscribe, e-mail: > <mailto:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
