You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2005/09/01 01:25:27 UTC
Re: Tomcat, logging, admin portlet, and GBeans
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 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
> joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>
>
Re: Tomcat, logging, admin portlet, and GBeans
Posted by David Jencks <da...@yahoo.com>.
thanks!
Not that I know much about this, but your design looks fine to me. I
might suggest warning the user somehow if there is more than one
WebManager so they know they are missing half the picture and can take
steps to turn off the other container. I agree supporting multiple
simultaneous web managers is a very low priority (if indeed > 0).
thanks
david jencks
On Sep 9, 2005, at 12:27 PM, Joe Bohn wrote:
> Can I ask that we move this thread back to its intended purpose (the
> proposal of a design for the web console to display either Tomcat or
> Jetty web logs ... )?
> It looks like we're on the verge of branching off into more detailed
> discussion on how to build the Geronimo distributions. I think this
> is all very important and I'd like to continue the discussion but I
> really would also like some input on the design that I proposed.
> David Jencks wrote:
>
>> I've explained what is currently implemented. I'm willing to make it
>> so selecting jetty or tomcat does not start the other configuration,
>> but where both configurations are present. If anyone wants to build
>> separate jetty and tomcat distributions that are actually missing the
>> other container, for m5, I will not stand in their way so long as
>> they keep the tck running at least as smoothly as it is now, but I do
>> not have the time or interest to put into it. I have no expectations
>> that the console will do anything in particular in M5. I do wonder
>> how you determine which container is running.
>>
>> I will say that I think that the current assembly module approach to
>> building geronimo distributions is really bad and that something
>> based on the packaging and assembly plugins should be much more
>> maintainable. I am aware that this opinion is shall we say
>> controversial.
>>
>> Using the same module to build two unrelated versions of the geronimo
>> distribution definitely violates the maven philosophy, and I suggest
>> if anyone wants to build separate distributions that they do so in
>> two separate modules.
>>
>> On Sep 9, 2005, at 10:11 AM, Bill Stoddard wrote:
>>
>>> Aaron Mulder wrote:
>>>
>>>> I really believe that choice is a bad thing.
>>>
>>
>> umm, really? why aren't we using jboss? or jonas?
>>
>>>> I don't believe we should offer 2 options to a user. How are
>>>> they supposed to decide? How are we supposed to guide them?
>>>
>>
>> So we should just drop support for jetty or tomcat completely? Which
>> one?
>>
>>>> I'll grant you that there may (*may*) be some possible reason
>>>> for
>>>> a very advanced user to want to run 2 different web containers. I
>>>> really
>>>> believe this should be an advanced manual process (e.g. download
>>>> Tomcat
>>>> build, then deploy Jetty plan). I really really really don't want
>>>> to
>>>> encumber every user with both Jetty and Tomcat in order to support
>>>> this
>>>> dual-container feature.
>>>
>>
>> We have been including all the jar files for both jetty and tomcat
>> for some time. Adding the configurations to run them is a tiny step
>> compared to this. I think if we remove one of the configurations we
>> need to remove the jar files that are only used with it.
>>
>>>
>>> +1
>>>
>>> Gratuitous feature creep is evil and this particular feature
>>> violates the "principle of least astonishment".
>>
>>
>> From my point of view, we are finally seeing some partial benefits
>> from being able to use some of the fundamental architectural features
>> of geronimo. I don't really care how we present the choice of
>> container to the user in M5 so long as it doesn't complicate the
>> build or running the tck. I've taken the approach that seems to me
>> to most clearly express geronimo principles and provides (in my
>> opinion) the simplest build and test path. I don't think that the
>> possible benefits of providing two builds that each include only one
>> container outweigh the additional project management complexity
>> involved.
>>
>> thanks
>> david jencks
>>
>>
>>
>
> --
> Joe Bohn joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he cannot
> lose." -- Jim Elliot
>
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Joe Bohn <jo...@earthlink.net>.
Can I ask that we move this thread back to its intended purpose (the
proposal of a design for the web console to display either Tomcat or
Jetty web logs ... )?
It looks like we're on the verge of branching off into more detailed
discussion on how to build the Geronimo distributions. I think this is
all very important and I'd like to continue the discussion but I really
would also like some input on the design that I proposed.
David Jencks wrote:
> I've explained what is currently implemented. I'm willing to make it
> so selecting jetty or tomcat does not start the other configuration,
> but where both configurations are present. If anyone wants to build
> separate jetty and tomcat distributions that are actually missing the
> other container, for m5, I will not stand in their way so long as they
> keep the tck running at least as smoothly as it is now, but I do not
> have the time or interest to put into it. I have no expectations that
> the console will do anything in particular in M5. I do wonder how you
> determine which container is running.
>
> I will say that I think that the current assembly module approach to
> building geronimo distributions is really bad and that something based
> on the packaging and assembly plugins should be much more
> maintainable. I am aware that this opinion is shall we say
> controversial.
>
> Using the same module to build two unrelated versions of the geronimo
> distribution definitely violates the maven philosophy, and I suggest
> if anyone wants to build separate distributions that they do so in two
> separate modules.
>
> On Sep 9, 2005, at 10:11 AM, Bill Stoddard wrote:
>
>> Aaron Mulder wrote:
>>
>>> I really believe that choice is a bad thing.
>>
>
> umm, really? why aren't we using jboss? or jonas?
>
>>> I don't believe we should offer 2 options to a user. How are they
>>> supposed to decide? How are we supposed to guide them?
>>
>
> So we should just drop support for jetty or tomcat completely? Which
> one?
>
>>> I'll grant you that there may (*may*) be some possible reason for
>>> a very advanced user to want to run 2 different web containers. I
>>> really
>>> believe this should be an advanced manual process (e.g. download Tomcat
>>> build, then deploy Jetty plan). I really really really don't want to
>>> encumber every user with both Jetty and Tomcat in order to support this
>>> dual-container feature.
>>
>
> We have been including all the jar files for both jetty and tomcat for
> some time. Adding the configurations to run them is a tiny step
> compared to this. I think if we remove one of the configurations we
> need to remove the jar files that are only used with it.
>
>>
>> +1
>>
>> Gratuitous feature creep is evil and this particular feature violates
>> the "principle of least astonishment".
>
>
> From my point of view, we are finally seeing some partial benefits
> from being able to use some of the fundamental architectural features
> of geronimo. I don't really care how we present the choice of
> container to the user in M5 so long as it doesn't complicate the build
> or running the tck. I've taken the approach that seems to me to most
> clearly express geronimo principles and provides (in my opinion) the
> simplest build and test path. I don't think that the possible
> benefits of providing two builds that each include only one container
> outweigh the additional project management complexity involved.
>
> thanks
> david jencks
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
Posted by David Jencks <da...@yahoo.com>.
I've explained what is currently implemented. I'm willing to make it
so selecting jetty or tomcat does not start the other configuration,
but where both configurations are present. If anyone wants to build
separate jetty and tomcat distributions that are actually missing the
other container, for m5, I will not stand in their way so long as they
keep the tck running at least as smoothly as it is now, but I do not
have the time or interest to put into it. I have no expectations that
the console will do anything in particular in M5. I do wonder how you
determine which container is running.
I will say that I think that the current assembly module approach to
building geronimo distributions is really bad and that something based
on the packaging and assembly plugins should be much more maintainable.
I am aware that this opinion is shall we say controversial.
Using the same module to build two unrelated versions of the geronimo
distribution definitely violates the maven philosophy, and I suggest if
anyone wants to build separate distributions that they do so in two
separate modules.
On Sep 9, 2005, at 10:11 AM, Bill Stoddard wrote:
> Aaron Mulder wrote:
>> I really believe that choice is a bad thing.
umm, really? why aren't we using jboss? or jonas?
>> I don't believe we should offer 2 options to a user. How are they
>> supposed to decide? How are we supposed to guide them?
So we should just drop support for jetty or tomcat completely? Which
one?
>> I'll grant you that there may (*may*) be some possible reason for
>> a very advanced user to want to run 2 different web containers. I
>> really
>> believe this should be an advanced manual process (e.g. download
>> Tomcat
>> build, then deploy Jetty plan). I really really really don't want to
>> encumber every user with both Jetty and Tomcat in order to support
>> this
>> dual-container feature.
We have been including all the jar files for both jetty and tomcat for
some time. Adding the configurations to run them is a tiny step
compared to this. I think if we remove one of the configurations we
need to remove the jar files that are only used with it.
>
> +1
>
> Gratuitous feature creep is evil and this particular feature violates
> the "principle of least astonishment".
From my point of view, we are finally seeing some partial benefits from
being able to use some of the fundamental architectural features of
geronimo. I don't really care how we present the choice of container
to the user in M5 so long as it doesn't complicate the build or running
the tck. I've taken the approach that seems to me to most clearly
express geronimo principles and provides (in my opinion) the simplest
build and test path. I don't think that the possible benefits of
providing two builds that each include only one container outweigh the
additional project management complexity involved.
thanks
david jencks
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Bill Stoddard <bi...@wstoddard.com>.
Aaron Mulder wrote:
> I really believe that choice is a bad thing. I don't believe we
> should offer 2 options to a user. How are they supposed to decide? How
> are we supposed to guide them?
>
> I'll grant you that there may (*may*) be some possible reason for
> a very advanced user to want to run 2 different web containers. I really
> believe this should be an advanced manual process (e.g. download Tomcat
> build, then deploy Jetty plan). I really really really don't want to
> encumber every user with both Jetty and Tomcat in order to support this
> dual-container feature.
+1
Gratuitous feature creep is evil and this particular feature violates the "principle of least astonishment".
Bill
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I really believe that choice is a bad thing. I don't believe we
should offer 2 options to a user. How are they supposed to decide? How
are we supposed to guide them?
I'll grant you that there may (*may*) be some possible reason for
a very advanced user to want to run 2 different web containers. I really
believe this should be an advanced manual process (e.g. download Tomcat
build, then deploy Jetty plan). I really really really don't want to
encumber every user with both Jetty and Tomcat in order to support this
dual-container feature. I really really really don't want to make it easy
for a user to inadvertently or on a whim run both containers, such that
every web-related question or bug report will require us to get the user
to figure out what's actually running and what they deployed to and so on.
Anyway, all that said, I agree that the console should support
runing more than one web container, but I don't feel that's a priority for
M5. The same is true for EJB, JMS, etc. It will require some thought on
how we want to present things and a fair bit of work to revise the JSPs.
Not a huge deal, but not something I feel the urge to spent time in in the
short term. Do you think it's necessary for M5?
Aaron
On Fri, 9 Sep 2005, David Jencks wrote:
> Right now, both jetty and tomcat are running in the standard server.
> We can make it so only one starts by default fairly easily by changing
> the config.list. The "tomcat" goal or setting the web container to
> tomcat changes the ports each container uses by default, but both start
> at the moment.
>
> However, if we ship both configurations, it is going to be very easy to
> get 2 web containers running at once, whether on purpose or not, by
> starting a configuration that is deployed to the "other" web container.
>
> I don't see a great deal of utility for running multiple web containers
> in one geronimo server, but I'm not an end user. I certainly hesitate
> to tell our end users that they will never want to do it. Since we
> have the technical ability to do it I would prefer that the management
> console support it in some way or at least not prevent it.
>
>
> thanks
> david jencks
>
>
Re: Tomcat, logging, admin portlet, and GBeans
Posted by David Jencks <da...@yahoo.com>.
On Sep 9, 2005, at 9:47 AM, Aaron Mulder wrote:
> 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 9:30 AM, Joe Bohn wrote:
> 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/
> %3c626faa41ca68555dc5f8aebeeebbe16a@yahoo.com%3e
>
> 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
> .
Right now, both jetty and tomcat are running in the standard server.
We can make it so only one starts by default fairly easily by changing
the config.list. The "tomcat" goal or setting the web container to
tomcat changes the ports each container uses by default, but both start
at the moment.
However, if we ship both configurations, it is going to be very easy to
get 2 web containers running at once, whether on purpose or not, by
starting a configuration that is deployed to the "other" web container.
I don't see a great deal of utility for running multiple web containers
in one geronimo server, but I'm not an end user. I certainly hesitate
to tell our end users that they will never want to do it. Since we
have the technical ability to do it I would prefer that the management
console support it in some way or at least not prevent it.
thanks
david jencks
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Joe Bohn <jo...@earthlink.net>.
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/%3c626faa41ca68555dc5f8aebeeebbe16a@yahoo.com%3e
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
>>>> joe.bohn@earthlink.net
>>>>
>>>> "He is no fool who gives what he cannot keep, to gain what he
>>>> cannot lose." -- Jim Elliot
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Joe Bohn
>> joe.bohn@earthlink.net
>>
>> "He is no fool who gives what he cannot keep, to gain what he cannot
>> lose." -- Jim Elliot
>>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
> >>> joe.bohn@earthlink.net
> >>>
> >>> "He is no fool who gives what he cannot keep, to gain what he cannot
> >>> lose." -- Jim Elliot
> >>>
> >>>
> >>>
> >>
> >>
> >
> > --
> > Joe Bohn
> > joe.bohn@earthlink.net
> >
> > "He is no fool who gives what he cannot keep, to gain what he cannot
> > lose." -- Jim Elliot
> >
>
>
Re: Tomcat, logging, admin portlet, and GBeans
Posted by David Jencks <da...@yahoo.com>.
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
>>> joe.bohn@earthlink.net
>>>
>>> "He is no fool who gives what he cannot keep, to gain what he cannot
>>> lose." -- Jim Elliot
>>>
>>>
>>>
>>
>>
>
> --
> Joe Bohn
> joe.bohn@earthlink.net
>
> "He is no fool who gives what he cannot keep, to gain what he cannot
> lose." -- Jim Elliot
>
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Joe Bohn <jo...@earthlink.net>.
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
>>>joe.bohn@earthlink.net
>>>
>>>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>--
>Joe Bohn
>joe.bohn@earthlink.net
>
>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Joe Bohn <jo...@earthlink.net>.
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
>>joe.bohn@earthlink.net
>>
>>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>>
>>
>>
>>
>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Joe Bohn <jo...@earthlink.net>.
I'll dig into this deeper and come back with a proposal.
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 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
>>joe.bohn@earthlink.net
>>
>>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>>
>>
>>
>>
>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Tomcat, logging, admin portlet, and GBeans
Posted by Joe Bohn <jo...@earthlink.net>.
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();
>
>
Why would there be multiple WebManagers for a single server? A
J2EEServer only includes a single Web Container today (although I did
see discussion on dev list about the ability to support multiple
containers concurrently ... not sure how that is done). Do you intend
for the WebManagers to manage more than just the Web Container or is
this to support the multiple container scenario in which case I suppose
the J2EEServer will need to change as well when working directly with
the containers.
>(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 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
>>joe.bohn@earthlink.net
>>
>>"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
>>
>>
>>
>>
>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot