Costin Manolache wrote:
For the first part: aren't you using a stylesheet ? That will be downloaded
as well when you refresh ?
I think that's the right explanation.
For the second: that's weird. I haven't seen it. Note that maxTime is R/W -
a monitoring app can periodically reset it ( for exam
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>
>>
>>
No, just return HTML in the first place.
>>>
>>>Feel free to revert to the previous version.
>>>
>>>-1 from me for server side XSL (we're doing a monitor servlet, not a
>>>bring-ther-server-to-its-knees monito
Costin Manolache wrote:
Remy Maucherat wrote:
No, just return HTML in the first place.
Feel free to revert to the previous version.
-1 from me for server side XSL (we're doing a monitor servlet, not a
bring-ther-server-to-its-knees monitor servlet).
I just don't understand - when you can just
Remy Maucherat wrote:
>> No, just return HTML in the first place.
>
> Feel free to revert to the previous version.
>
> -1 from me for server side XSL (we're doing a monitor servlet, not a
> bring-ther-server-to-its-knees monitor servlet).
>
>> I just don't understand - when you can just displa
Costin Manolache wrote:
Tim Funk wrote:
Do you mean take the XML doc and perform an xslt transformation on the
server before it gets sent to the client? (I thought original patch did
that.)
No, just return HTML in the first place.
Feel free to revert to the previous version.
-1 from me for ser
Tim Funk wrote:
> Do you mean take the XML doc and perform an xslt transformation on the
> server before it gets sent to the client? (I thought original patch did
> that.)
No, just return HTML in the first place.
I just don't understand - when you can just display HTML, why do you
want to go th
Do you mean take the XML doc and perform an xslt transformation on the
server before it gets sent to the client? (I thought original patch did
that.)
The dtd was really just an easy explanation of what the fields meant.
The only reason I suggested this was if an xml doc is published (which
it
Tim Funk wrote:
> I am in the process of reworking the style sheet to make it "prettier".
>(I do my testing in mozilla)
>
> I will also try to:
> - create a DTD which will explain the xml output
> - add an option to allow the user to change the style sheet
> - incorporate more information int
I am in the process of reworking the style sheet to make it "prettier".
(I do my testing in mozilla)
I will also try to:
- create a DTD which will explain the xml output
- add an option to allow the user to change the style sheet
- incorporate more information into the XML doc output
- wish to
Remy Maucherat wrote:
> Remy Maucherat wrote:
>> Costin Manolache wrote:
>>
>>> Remy,
>>> Could you move the manager servlets to webapps/manager ? As you can
>>> see, I can't touch build.xml without breaking something :-).
>>>
>>>
>>> I would also like to move the coyote/tomcat5 code in catalina
Remy Maucherat wrote:
> I've committed a rough version of the monitoring servlet. It will
> display status information for all Coyote connectors, using JMX
> exclusively. I don't think there's any statistic missing (the amount of
> meaningful status information available to a Java program is defin
Remy Maucherat wrote:
Costin Manolache wrote:
Remy,
Could you move the manager servlets to webapps/manager ? As you can
see, I can't touch build.xml without breaking something :-).
I would also like to move the coyote/tomcat5 code in catalina - and
eventually coyote/tomcat4 to jakarta-tomcat-4 a
Costin Manolache wrote:
Remy,
Could you move the manager servlets to webapps/manager ?
As you can see, I can't touch build.xml without breaking something :-).
I would also like to move the coyote/tomcat5 code in catalina - and
eventually coyote/tomcat4 to jakarta-tomcat-4 and same for 3.3
( pre
Remy,
Could you move the manager servlets to webapps/manager ?
As you can see, I can't touch build.xml without breaking something :-).
I would also like to move the coyote/tomcat5 code in catalina - and
eventually coyote/tomcat4 to jakarta-tomcat-4 and same for 3.3
( preserving the same packag
Here's a patch to JdkCompat, and JdkCompat1.4
The method is called getMaxMemory() and returns -1 for jdk1.3 or less.
Why -1? I had to pick a number. Feel free to change.
I do not have a patch yet for StatusManagerServlet. With luck, I'll have
a patch for that(with additional functionality) in t
- Original Message -
From: "Jean-Francois Arcand" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, March 24, 2003 8:21 AM
Subject: Re: [5.0] Monitor servlet
>
>
> Remy Maucherat wrote:
>
> > Jean-Fran
Remy Maucherat wrote:
Jean-Francois Arcand wrote:
Hi Remy,
the servlet doesn't compile with JDK 1.3.x :
StatusManagerServlet.java:274: cannot resolve symbol
[javac] symbol : method maxMemory ()
[javac] location: class java.lang.Runtime
[javac] writer.print(Runtime.getRuntim
Jean-Francois Arcand wrote:
Hi Remy,
the servlet doesn't compile with JDK 1.3.x :
StatusManagerServlet.java:274: cannot resolve symbol
[javac] symbol : method maxMemory ()
[javac] location: class java.lang.Runtime
[javac] writer.print(Runtime.getRuntime().maxMemory());
[java
Tim Funk wrote:
Looks good. Can I propose an (close) alternative?
Can the status servlet produce an XML document? Then the XML document
can either parsed by some third party app or it can be transformed in
place to anyone's liking via XSLT.
It has been decided earlier that it would produce XHTML
Looks good. Can I propose an (close) alternative?
Can the status servlet produce an XML document? Then the XML document
can either parsed by some third party app or it can be transformed in
place to anyone's liking via XSLT.
Attached are examples of a (very) quick example of what I mean. There
Hi Remy,
the servlet doesn't compile with JDK 1.3.x :
StatusManagerServlet.java:274: cannot resolve symbol
[javac] symbol : method maxMemory ()
[javac] location: class java.lang.Runtime
[javac] writer.print(Runtime.getRuntime().maxMemory());
[javac]
Remy Maucherat wrote:
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp. It
would generate data similar to http://www.apache.org/server-status. It
would mostly (exclusively ?) use JMX to retri
Remy Maucherat wrote:
> Well, I indeed have a few things on my task list, including:
> - new static resource cache (the current one is inefficient both in
> terms of syncing and memory management)
Any chance you'll make this a bit more independent of the internals -
I tried to do a bit of refacto
Costin Manolache wrote:
Remy Maucherat wrote:
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp. It
would generate data similar to http://www.apache.org/server-status. It
would mostly (exclusiv
+0 (I have little time to help those day)
-- Jeanfrancois
Remy Maucherat wrote:
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp.
It would generate data similar to http://www.apache.org/ser
Remy Maucherat wrote:
> Hi,
>
> I proposed that to Costin a few days ago, but got not so enthusiastic
> comments.
> The idea would be to add a new monitor servlet to the manager webapp. It
> would generate data similar to http://www.apache.org/server-status. It
> would mostly (exclusively ?) use
+1 (Nonbinding, and I have not programmed anything using JMX yet)
-Tim
Remy Maucherat wrote:
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp. It
would generate data similar to http://www.ap
Remy Maucherat wrote:
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp. It
would generate data similar to http://www.apache.org/server-status. It
would mostly (exclusively ?) use JMX to retri
Howdy,
I'd be interested and willing to help implement this.
Yoav Shapira
Millennium ChemInformatics
>-Original Message-
>From: Remy Maucherat [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, March 05, 2003 9:19 AM
>To: Tomcat Developers List
>Subject: [5.0] Monitor
Hi,
I proposed that to Costin a few days ago, but got not so enthusiastic
comments.
The idea would be to add a new monitor servlet to the manager webapp. It
would generate data similar to http://www.apache.org/server-status. It
would mostly (exclusively ?) use JMX to retrieve the components sta
30 matches
Mail list logo
