Re: Tomcat, logging, admin portlet, and GBeans
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
Re: Tomcat, logging, admin portlet, and GBeans
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
Re: Tomcat, logging, admin portlet, and GBeans
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
Re: Tomcat, logging, admin portlet, and GBeans
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
Re: Tomcat, logging, admin portlet, and GBeans
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
Re: Tomcat, logging, admin portlet, and GBeans
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/ [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 . 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
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
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
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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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 [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
Re: Tomcat, logging, admin portlet, and GBeans
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 of org.apache.catalina.valves.AccessLogValve and then Query that object for its prefix and suffix properties. This will give you the log file name (they live in the $GERONIMO_HOME/var/catalina/log directory). You also could create a Tomcat logging GBean to make this process a little easier, but it *must* extend the ValveGBean because since its essentially a valve, it needs to be in the chain of valve interceptors. Would it not just be easier to query the $GERONIMO_HOME/var/catalina/log directory for files? Jeff 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?
Re: Tomcat, logging, admin portlet, and GBeans
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. Verify its an instance of org.apache.catalina.valves.AccessLogValve and then Query that object for its prefix and suffix properties. This will give you the log file name (they live in the $GERONIMO_HOME/var/catalina/log directory). You also could create a Tomcat logging GBean to make this process a little easier, but it *must* extend the ValveGBean because since its essentially a valve, it needs to be in the chain of valve interceptors. Thanks for the clarification. I need to educate myself on logging valves. That wasn't obvious to me when looking at the plan for the server (ie. I didn't notice a GBean for the logs). Would it not just be easier to query the $GERONIMO_HOME/var/catalina/log directory for files? Yes, I thought of that too. I was trying to stay within the general design of the portlet as it stands. I suppose the handling of the log content could be fundamentally different in the portlet between jetty and tomcat. Jeff 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
Re: Tomcat, logging, admin portlet, and GBeans
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 [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
