On Fri, 9 Sep 2005, David Jencks wrote:
> I don't fully understand what this issue is about, but I would like to
> point out that the first assumption (that there is one web container
> per image) is currently wrong and IMO not likely to change for M5
I'm not sure I understand. I really oppose shipping a server with
both Tomcat and Jetty active. I thought it was going to be a Tomcat
download and a Jetty download. And if this was achieved by having both
present in the server but one was disabled and effectively invisible,
fine, that's effectively equivalent to only one being present.
Aaron
> On Sep 9, 2005, at 7:49 AM, 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,
> >> ...);
> >> )
> >>
> >>
> >
> > - 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
> >
>
>
