So which way would be best/better to proceed? Since mladen has his apr-java stuff, would it make sense to do this?
1. write native windows dll 2. write apr component 3. use apr-java to wrap apr 4. wrap apr-java with mbeans or 1. write apr component to call system level API 2. use apr-java to wrap apr 3. wrap apr-java with mbeans or something completely different? peter On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache <[EMAIL PROTECTED]> wrote: > Benson Margulies wrote: > > For systems with a /proc file system with these statistics, this doesn't > > require any JNI ... > > Yes, there are a lot of ways to workaround java limitations. /proc is > one. But even on linux, a lot is not exposed via /proc, but ioctl. > I guess the goal is not to implement sysinfo, but have a way to get more > platform-specific information and access platform-specific features. > > Costin > > > > > > -----Original Message----- > > From: Peter Lin [mailto:[EMAIL PROTECTED] > > Sent: Monday, January 03, 2005 10:04 AM > > To: Tomcat Developers List > > Subject: Re: adding features to Status servlet > > > > sysinfo on unix/linux should be pretty easy. I've used windows > > performance stats before when i tried to write the equivalent of the > > status servlet for IIS. I will try to write an exe named sysinfo that > > spits out similar performance stats. > > > > how can I help mladen? > > > > peter > > > > > > > > On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk <[EMAIL PROTECTED]> > > wrote: > > > >>Peter Lin wrote: > >> > >>>that sounds great. does it have support for sysinfo? if it does, > >>>I'll try using your apr-java package. > >>> > >> > >>No, but it's up to us to decide what will go inside. > >>APR is included, but I wish to leave that as open as it could be. > >>It already have win32.c,unix.c and netware.c files for platform > >>specific stuff that APR doesn't offer. > >>Having sysinfo sounds good to me. WIN32 has also good performance data > > > > > >>gathering, and I'm sure that Netware has them too. > >>I also wish to include the OS specific things from httpd like setting > >>group, user, sending data to child process, etc... > >> > >>What matters is that we'll have a generic native component, with well > >>defined build and distribution specification. > >> > >>Mladen. > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
