Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CBD839A16 for ; Wed, 29 Feb 2012 19:26:18 +0000 (UTC) Received: (qmail 28048 invoked by uid 500); 29 Feb 2012 19:26:18 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 27999 invoked by uid 500); 29 Feb 2012 19:26:18 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 27991 invoked by uid 99); 29 Feb 2012 19:26:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Feb 2012 19:26:18 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [209.174.123.75] (HELO samarium-v1.sys.ma.cait.org) (209.174.123.75) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Feb 2012 19:26:11 +0000 Received: from samarium-v2.sys.ma.cait.org ([209.174.123.67] helo=vanadium.sys.ma.cait.org) by samarium-v1.sys.ma.cait.org with esmtp (Exim 4.63) (envelope-from ) id 1S2p9p-0006cN-82 for dev@geronimo.apache.org; Wed, 29 Feb 2012 13:25:50 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by vanadium.sys.ma.cait.org (Postfix) with ESMTP id 38481A68C003 for ; Wed, 29 Feb 2012 13:25:49 -0600 (CST) X-Virus-Scanned: amavisd-new at vanadium.sys.ma.cait.org Received: from vanadium.sys.ma.cait.org ([127.0.0.1]) by localhost (vanadium.sys.ma.cait.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exFxvocsdNTh for ; Wed, 29 Feb 2012 13:25:49 -0600 (CST) Received: from russ-linux.cait.org (unknown [10.0.0.18]) by vanadium.sys.ma.cait.org (Postfix) with ESMTPSA id 19A53A68C002 for ; Wed, 29 Feb 2012 13:25:49 -0600 (CST) Message-ID: <4F4E7BBC.9010300@cait.org> Date: Wed, 29 Feb 2012 13:25:48 -0600 From: Russell E Glaue User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: Updating Configuring Virtual Host in Tomcat, for G3.0 References: <4F4D5AB4.4070005@cait.org> <4F4E3694.6070400@cait.org> <4F4E58F8.3000003@cait.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Virus-Checked: Checked by ClamAV on apache.org We are currently farming with Sun's Enterprise Web Server (v6 and v7), which utilizes an admin config host to push files around. A centralized admin host maintains the files and pushes out changes to the distributed admin hosts on each node. This is all file-based configurations. The central admin node replaces config files on the remote nodes. To create or remove an instance, a command is sent to the distributed admin nodes to tell it to deploy a new instance. (Thus my desire to see GERONIMO-5164 resolved) However, that software has quite a few issues/bugs and I had to write a lot of tooling to actually make it work in a way that regular admin guys need only push a local button on each web server to start up or restart an instance. - Not great for cycling web services remotely. So what you suggest has already been done, and I am familiar with. I can accept this approach. However, for Geronimo, it will get complicated when you are pushing partial tomcat configs around to various servers. Local configuration (like what IP to bind to) can vary server to server. This is because Geronimo would be relying on Tomcat completely for implementation. This is one reason why I _loved_ that Tomcat was abstracted into a GBean. Sun Web Server easily configures multiple web containers per instance. But Catalina has one default web container. (Remember our conversation back in 2008, http://markmail.org/thread/iil2vorcfwe3iiel) (Sun uses catalina under the hood, but abstracts its use) There are some other reasons why I was looking towards GBeans. I can easily push configuration around to multiple servers by deploying plans. This can include configuring multiple web containers and virtual hosts within those web containers and deploying them on various web servers. Those configurations/plans can be managed by replicated maven repositories. I can push these to a remote maven repository in a remote NOC, and then have all the web servers in that NOC feed from it. Right now, if we were to move toward pushing config files, it would be difficult to manage things like accounting for different IP addresses for each server, and setting up multiple Catalina web containers. Perhaps also having difficulty in naming log files with the local host name, or configuring some specifics in the local SYSLOG facilities. (I have issues with these items, and more, in Sun Web Server's centralized admin service today) The managed service factories would have to be capable of generating entire services, and multiple instances of elements with the services, in order to compensate for the advantage GBeans give us now. -RG On 02/29/2012 12:19 PM, David Jencks wrote: > Hi Russell, > > My current viewpoint on gbeans is that in an osgi framework they are a bad idea since their capabilities are better expressed using osgi services and config admin. I am not all that confident that there is enough interest in actually rewriting the code in this way, but architecturally I think it is the best alternative. > > For things like tomcat server.xml there's a big question of the best size of components. We originally tried to have a geronimo component (gbean) for the smallest size tomcat component, and this has caused a lot of problems including really bad impedance mismatch on component lifecycles and forcing tomcat users to learn a totally unfamiliar configuration interface. At the moment we have 2 competing configuration mechanisms, server.xml and gbeans, and I think this is too complicated and confusing. > > Another possibility might be to have a single tomcat service that accepts the server.xml from config admin and sets up the entire tomcat server from that. If you want to change something you edit server.xml in config admin. Farming could be handled by a distributed config admin service. > > I haven't looked into tomcat configuration much since I started learning about config admin and managed service factories so there might be another way to do this with less monolithic tomcat configuration but still through osgi mechanisms. > > What do you think? > > thanks > david jencks > > On Feb 29, 2012, at 8:57 AM, Russell E Glaue wrote: > >> Are you suggesting that at some future milestone, Tomcat would no longer be configurable with a GBean deployment? >> >> Is it being considered that in regards to newer versions of Tomcat, the GBean may not be updated to incorporate newly introduced tomcat parameters? >> >> That would suggest that GBean configuration for Geronimo's Tomcat will become deprecated. >> >> How would it be suggested that in this case Geronimo's Tomcat could be centrally managed? Do we go back to pushing configuration files? That would change how plugin based farms are managed. >> >> -RG >> >> >> On 02/29/2012 08:56 AM, Ivan wrote: >>> Yes, I agree that all the options should be documented, as you mentioned, we >>> need it in many places. >>> For the server.xml, I am thinking that it should be the main direction for the >>> tomcat container configuration in the future, IMHO. >>> As in the past versions, we find that those wrapper GBeans become more and more >>> complicated for. e.g. with the new Tomcat version,some new parameters are >>> introduced, and it is required to add those attributes for existing GBeans. From >>> another side, it is really not user-friendly to configure those things with >>> GBean. e.g. While configuring cluster, users may need to add a long GBean >>> configurations in the config.xml, which is error proven. >>> >>> 2012/2/29 Russell E Glaue> >>> >>> Do you think that var/catalina/server.xml should be the primary emphasis for >>> managing the default web container? >>> I think all options should be documented, but that one can be first. >>> >>> Geronimo can run multiple web containers, but those have to be configured >>> via a GBean. So the virtual hosts would be configured similarly in these >>> environments. >>> >>> And when Geronimo is in a Farming environment, GBean deployment will be the >>> requirement. >>> https://cwiki.apache.org/__GMOxDOC30/farming-using-__deployment.html >>> >>> >>> I believe a GBean option for all configurations should be documented when >>> possible. Then Geronimo can be configured remotely. >>> >>> -RG >>> >>> >>> >>> On 02/28/2012 07:28 PM, Ivan wrote: >>> >>> Thanks for updating this, I am wondering whether we would encourage the >>> users to >>> use the server.xml to configure virtual host, although the gbean way >>> still works >>> now. >>> >>> 2012/2/29 Russell E Glaue >>> >> >>> >>> >>> I am going to start working on this document for G3.0 >>> https://cwiki.apache.org/____GMOxDOC30/configuring-virtual-____host-in-tomcat.html >>> >>> >>> >> > >>> >>> In addition to updating what is there, I am going to add additional >>> information on how to deploy a plan with the deployer to configure >>> virtual >>> hosts. >>> >>> >>> Any comments/suggestions? >>> >>> >>> I will use this plan, which I have verified works. >>> - >>> >>> >>> >>> org.example.configs.____virtualhosts >>> virtualhost1 >>> >>> 1.0 >>> car >>> >>> >>> >>> org.apache.geronimo.____configs >>> tomcat7 >>> >>> car >>> >>> >>> >>> >>> >>> >> class="org.apache.geronimo.____tomcat.HostGBean"> >>> >> >>> name="className">org.apache.____catalina.core.StandardHost >>> name=virtual____host1.com >>> >>> >>> appBase= >>> workDir=work >>> >>> TomcatEngine >>> >>> >>> >>> - >>> >>> >>> >>> >>> -- >>> Ivan >>> >>> >>> >>> >>> -- >>> Ivan >