Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of jak-tomcat-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: tomcat-dev@jakarta.apache.org
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: adding features to Status servlet
Date: Mon, 03 Jan 2005 18:44:15 -0800
Lines: 116
Message-ID: <crcvu0$ssv$1@sea.gmane.org>
References: <E95FD77F0171D14DA1EEE0A785E92B43290D1C@mail3.basistech.net>
	 <crc60l$vrk$1@sea.gmane.org> <27e674a9050103113655a33753@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.5) Gecko/20041201 Thunderbird/1.0RC1 Mnenhy/0.7
In-Reply-To: <27e674a9050103113655a33753@mail.gmail.com>
Sender: news <news@sea.gmane.org>

Or:

1. Wait for Mladen to check in the code
2. figure out how to build it and how to install it easily in tomcat ( 
and other java applications ).
3. probably add one native method. I don't think "wrapping it as apr 
component" makes sense ( apr is not a component system like xpcom ).
4. write the java mbean - using the native method and making all 
conversions between the native signature and java style ( if SWT-style
of jni is used - i.e. using byte[], int pointers, etc - and doing java 
adaptation in java ).

I'm as curious as you are to see the code and figure out how it can be 
used, I love jni :-)

Costin

Peter Lin wrote:
> 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
> <cmanolache@yahoo.com> 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:woolfel@gmail.com]
>>>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 <mturk@apache.org>
>>>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: tomcat-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org