It is a status page to allow people to quickly see the status. If you want to programmatically process it - the right solution is to get the informations into the JMX engine on tomcat side. I believe there is already code to do some of this and expose some of the mod_jk components as MBeans.
Yes, some people may want to just get info from mod_jk side and won't care about tomcat monitoring. But developing a proprietary solution, specificially for mod_jk is IMO bad.
It would be much better if we find what other info from mod_jk is needed and pass it to tomcat JMX, then use JMX tools to do all monitoring on a common basis.
( I won't get into the evil of inventing random XML formats and replacing a simple html with a complex solution involving XSL and templates ).
Costin
NormW wrote:
Hello again. It looks like a one-sided discussion at the moment. I must admit being a +0 myself, although, from a technical standpoint, I don't get or need a vote. I've finally got the HTML version worked out, and the 'comfort' that knowledge brings is not readily given up. But a few years ago I didn't even know about Apache, so change seems both inevitable and sneaky. And your suggestion bypasses a decision as to what format to include in the JTC source!
At this point, (due to lack of response so far) some questions of likely interest are:
1. What development effort the implementation would need, 2. What timeframe it could take, and 3. Is there a document outlining the development of a 'template'.
If this went ahead, it seems all questions would need to be answered by you. However, it might be considered 'early days' yet.
Norm
----- Original Message ----- From: "Mladen Turk" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, April 14, 2004 5:15 PM
Subject: RE: Discussion - /jkstatus and xml
-----Original Message----- From: NormW
Hmmm.... It seems your proposal has left everyone speechless.... which could mean either +1 or +0 perhaps... Norm
It's probably +0 thought :)
Really, I think it's a good solution, that doesn't change the overall appearance of the current implementation. The current one can be embedded as const char * string parsed, but you may have an external file for what ever format you like. The two directives to the [status] should be added and those are
'template'
and 'contentType'. Without it's presence the default one will get
displayed.
I'm using the code for a custom mod_dir that generates the xml directory listings, and it works good enough. It is useful in any situation where you have mixture of key-value pares combined with the collection of key-value pairs generated using loops.
MT.
If the appropriate solution is to have a template file that
can generate
what ever content then I have a solution. http://jakarta.apache.org/~mturk/strproc.zip is a simple
state template
engine with only 13k of code. You can define loop callbacks and have a content what ever
you like html,
txt or xml.
If the template file is the acceptable solution then I can help you integrate that. The gain is to have a single codebase that can generate any
type of a
content.
--------------------------------------------------------------------- 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]
