Having received no negative comments on this design I am in the process
of implementing this design. I'm first just going to get Jetty log
code updated under this new architecture. Then I'll deliver another
JIRA to add in the tomcat support.
The changes will include:
- Introduction of a new interface called WebAccessLogHelper in
org.apache.geronimo.management.geronimo. This is a container agnostic
helper interface to interact with web logs.
- Addition of a new method to the WebManager to return a reference to a
WebAccesslogHelper for the appropriate container.
- Introduction of a new class which is an implementation of
WebAccessLogHelper called WebAccessLogHelperJettyImpl (I know ... kinda
long) in org.apache.geronimo.management.geronimo
- Introduction of a new class WebAccessLogCriteria which will be used
to quality the content requested.
- Update of the WebAccessLogViewerPortlet to utilize the new structure
which will include instantiation of a WebAccessLogCriteria prior to
queries.
- Removal of console-standard classes for WebAccessLogHelper and
WebAccessLogCriteria
Joe Bohn wrote:
Aaron Mulder wrote:
In order to do this right, I think we should define an interface
for web server request log access. That interface should have a method
that searches the logs, like the server log GBean does, so rather than the
console code asking the web server for log files and then opening files
and scanning them, the console should pass a bunch of search parameters to
the web server, and the web server should identify and search its own logs
and just return the results to the console. If the web server has
multiple logs, I guess it should have a method that gets a list of log
file names, so the portlet can let you select the log to query, and the
search method can take the log file name as a parameter.
I have an outstanding task to rearrange the management interface
works for the web containers and connectors, so part of that can be
exposing the log manager or whatever we call the interface mentioned
above. So after those changes, the code should look something like this:
J2EEServer server = ...
WebManager[] managers = ... server.getWebManagers();
(select Tomcat or Jetty WebManager to work with)
RequestLogManager log = ... managers[i].getRequestLog();
(do log stuff such as:
String[] logFiles = log.getLogFiles();
LogLine[] hits = log.searchLogs(logFile, start, end, maxRows, ...);
)
To resurrect this item I would propose the following:
- We continue to assume that there will be only 1 container and hence 1
Web Manager in an image (see my earlier question on this point).
- As you suggest we add a mechanism to the WebManager to get access to
logs.
- Create an Interface (WebAccessLogHelper) with methods similar to the
class methods on the current WebAccessLogHelper class. There will be
some additions for handling multiple logs and some other changes (see
below).
- Create implementations of the WebAccessLogHelper for each supported
container type.
- Add a method to the WebManager to return a reference to the
appropriate WebAccessLogHelper implementation for the container.
- Have the portlet interact with the WebAccessLogHelper and in
particular make queries via an enhanced WebAcessLogCriteria object
(enhanced to include the log selection, max# of records to return,
etc...).
So the WebAccessLogViewerPortlet pseudo-code would look something
like this:
J2EEServer server = ....
WebManager[] managerArray = .... server.getWebManagers();
WebManager manager = WebManagers[0]; // select the first manager in
the set for now. If we support multiple managers we can enhance this
for some user selection.
WebAccessLogHelper logHelper = manager.getLogHelper();
// No need to query the container type .. that's hidden behind the
implementation of the log helper interface.
ArrayList logs = logHelper.getLogs() // to return a list of logs for
display/selection (initially select the first log in the list)
File[] files = logHelper.getFiles() // to return a list of files for
display only (for those who would like to see the actual files and the
locations).
WebAccessLogCriteria = new WebAccessLogCriteria( criteria defaults ..
including the selected log).
ArrayList searchResults = WebAccessLogHelp.searchLogs( criteria);
Criteria would include most of what there is is today with some minor
changes:
- selected Log (user can select from list if more than one).
- Start date/time
- End data/time
- Host
- authUser
- method
- URI
- message
- max # of messages to return
- Starting record # (for displaying subsequent pages).
To get started, perhaps you could propose an interface for the
RequestLogManager or whatever we call it, and look at how we could
implement that for Tomcat and Jetty.
Thanks,
Aaron
On Wed, 31 Aug 2005, Joe Bohn wrote:
I was investigating what is necessary to get the log management portlet
in the console working for tomcat. It currently only works to display
the jetty web log.
As I was digging into this it is starting to get a little deeper than I
anticipated and would like some recommendations.
- The log portlet references a GBean object for the JettyRequestLog.
- I don't see an equivalent GBean in tomcat. Should I attempt to create
one and wrap the Tomcat web log in a GBean too?
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
|
