Of course you are correct David. Your hard work has made it possible so
that we can support multiple containers concurrently. My statement
below was not directly related to this design. I was only trying to
keep things consistent in the console for now (which always assumes just
1 active web container at a time). Since the console is still being
considered a "tech preview" for M5 I don't think this will present a
problem for that delivery.
However, since you brought it up ... did we ever gain consensus on our
packaging plans and typical environment? I wasn't aware that this
issue was settled (not that I want to start the discussion here :-) ).
IIRC there were questions about this being a scenario that most users
would understand and I don't believe that we have yet identified a
practical scenario where a user would require this. There were also
questions about supporting multiple containers of the same or different
versions and any problems that might arise as a result (such as class
loader issues).
I'm referring to the discussion that you started in this thread so
perhaps we should take the discussion up again on that thread.
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200509.mbox/[EMAIL
PROTECTED]
If has been decided that we will give the user the option of configuring
the system with numerous web containers then we need to expose this fact
in the console and possibly in other places for management capabilities
(do we currently have a command line that would need to change?). From
the web console perspective we will also need to evaluate how we can
manage this complexity without confusing the typical user (who I suspect
will probably be running just 1 web container).
-Joe
.
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
thanks
david jencks
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
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose."
-- Jim Elliot
