With tracing enabled, it then produces it's own log file called "tracing.log", or whatever name you want to call it.
You could either have it configurable through an admin console or configurable through editing raw XML configuration documents, whichever the user prefers. You could also have some command line shell environment that enables you to switch on/off configuration variables on the fly. That way things configurations can be scripted.
-damon
On Friday, August 8, 2003, at 04:19 PM, Robert McIntosh wrote:
Now, if the J2EE container used this (or a similiar) system in a non-intrusive way, say via interceptors ala JBoss, that would be really nice. You could have the turn on/off feature and not have to implement or extend any classes/interfaces. Would make a nice addition to an admin console as well.
Robert
Berin Loritsch wrote:
Damon E. Sorrentino wrote:
One thing WebSphere 5.0 supports is a diagnostic tracing service that administrators and developers can enable or disable at the component level. For example, WebSphere has an HTTP_Transport component with several public classes:
com.ibm.ws.http.ChunkedInputStream com.ibm.ws.http.ContentLengthInputStream com.ibm.ws.http.HttpConnection com.ibm.ws.http.HttpRequest com.ibm.ws.http.HttpResponse . . .
I'm not sure if this is necessarily related, but Avalon has an API available
to instrument your code. It is quite configurable and works pretty well.
THe instrument APIs provide (1) a way to extend your code to expose runtime
values, (2) a way to publish those (inside the same VM, or even outside if
desired), and (3) a way to view the instrumentation. The client is a Java
Swing based app that provides some really nice meters.
Another benefit besides just seeing the runtime state of your server is
also being able to tell the VM to do a garbage collection cycle. The client
runs in its own JVM, and uses AltRMI to talk to the container code.
Best benefit of all:
Regardless of whether you choose to use Avalon for your container needs,
you can still use the instrumentation code. The Avalon containers make it
a little easier because they are already integrated, but it is still an
extension.
Its pretty cool stuff, and it is pretty useful. Leif Mortenson is the brainstormer behind it, and I have found him to be a rocket scientist in regards to Java memory management. Not even the GUI client leaks memory!
You can turn on and off the types of instruments you want to watch.
The administrator or developer can then enable certain types of tracing within each class, i.e. entry/exit, event, and debug traces, through their administration console web application. You can enable any combination of these trace types.
This type of functionality proves useful when trying to run different J2EE applications inside multiple application servers.
-damon
