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
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
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:
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
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
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 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
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
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,
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
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
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
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
Tomcat uses a logging valve...so it's already GBeanized. It can have
multiple logs as there can be a valve set at the Engine, Host, and
Context levels.
To do this from a Gbean perspective, I would query for all of the
ValveGBeans and call getInternalObject() on it. Verify its an instance
Jeff Genender wrote:
Tomcat uses a logging valve...so it's already GBeanized. It can have
multiple logs as there can be a valve set at the Engine, Host, and
Context levels.
To do this from a Gbean perspective, I would query for all of the
ValveGBeans and call getInternalObject() on it.
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
16 matches
Mail list logo
