geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell E Glaue <rgl...@cait.org>
Subject Re: Updating Configuring Virtual Host in Tomcat, for G3.0
Date Tue, 06 Mar 2012 15:31:09 GMT
Great.
Are you able to point me at discussions and examples of creating jars for 
TomcatServerGBean and TomcatContainerGBean?

I have been looking for this, and have not found any.
-RG


On 03/06/2012 01:50 AM, Ivan wrote:
> Hi, I think that the GBean way to construct the server will be still there,
> while there are two ways, one is as you did in the past, configure many GBean
> instances, including connector gbean, container gbean, and etc. Another type is
> to define a TomcatServerGBean, and provide a server.xml, which is the
> recommended one. For the first way, we are still maintaining that, you may see
> that there are some changes recently for adding some new Tomcat parameters.
>
> For your scenario, with the later one, I am thinking whether you could do it in
> the following way, create a plain jar file, including a geronimo-service.xml
> file, which configures a TomcatServerGBean and TomcatContainer GBean, and there
> may also some customized Tomcat implementations in that jar file, then deploy it
> to those remote server to have a new Tomcat server instance created.
>
> 2012/3/6 Russell E Glaue <rglaue@cait.org <mailto:rglaue@cait.org>>
>
>     I think Geronimo should go with a full OSGi implementation as a core, GBeans
>     can take a back seat to OSGi if we can put all service configurations into
>     the OSGi service registry.
>
>     I want to believe that as an industry, most projects will become compatible
>     as an OSGi service. Take for example Apache JAMES which has already been
>     proven can be implemented as a GBean-service in the Geronimo stack.
>             If a project wanted to take advantage of Geronimo as a framework, it
>     makes sense that there would be more support in any community to move
>     towards a general OSGi compatibility instead of specific customization for a
>     single proprietary project.
>             For the future of Geronimo, it will be easy to adopt other projects
>     as they move towards becoming compliant as a OSGi service.
>
>     OSGi should be the focus for the future of Geronimo.
>     If there is reluctance to move Geronimo into a full OSGi implementation,
>     then I feel the only alternative is to fully support GBeans for complete
>     Geronimo configuration.
>
>     To not embrace OSGi, and to move away from GBeans to file-based
>     configuration, is to degrade the ability of Geronimo to enter the
>     enterprise. We who must managed 100 web servers need remote management and
>     deployment.
>
>
>     Of course, like I already said, current commercial offering like Oracle
>     iPlanet Web Server (formally Sun Enterprise Web Server) use remote
>     configuration through file-based configuration. So this approach is not to
>     be frowned upon. But the future is moving towards OSGi. We are beginning to
>     have this in a lot of our daily-used devices like mobile. Better to start on
>     the path towards OSGi now than have to make up for the bigger gap later.
>
>
>
>     -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<rglaue@cait.org
>                 <mailto:rglaue@cait.org><mailto:r__glaue@cait.org
>                 <mailto:rglaue@cait.org>>>
>
>                     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
>                 <https://cwiki.apache.org/__GMOxDOC30/farming-using-__deployment.html>
>                 <https://cwiki.apache.org/__GMOxDOC30/farming-using-__deployment.html
>                 <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<rglaue@cait.org
>                 <mailto:rglaue@cait.org><mailto:r__glaue@cait.org
>                 <mailto:rglaue@cait.org>>
>                 <mailto:rglaue@cait.org
>                 <mailto:rglaue@cait.org><__mailto:rglaue@cait.org
>                 <mailto:rglaue@cait.org>>>>
>
>
>                             I am going to start working on this document for G3.0
>                 https://cwiki.apache.org/______GMOxDOC30/configuring-virtual-______host-in-tomcat.html
>                 <https://cwiki.apache.org/____GMOxDOC30/configuring-virtual-____host-in-tomcat.html>
>                 <https://cwiki.apache.org/____GMOxDOC30/configuring-virtual-____host-in-tomcat.html
>                 <https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html>>
>
>                 <https://cwiki.apache.org/____GMOxDOC30/configuring-virtual-____host-in-tomcat.html
>                 <https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html>
>                 <https://cwiki.apache.org/__GMOxDOC30/configuring-virtual-__host-in-tomcat.html
>                 <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.
>                             -
>                 <module
>                 xmlns="http://geronimo.apache.______org/xml/ns/deployment-1.2
>                 <http://geronimo.apache.org/____xml/ns/deployment-1.2
>                 <http://geronimo.apache.org/__xml/ns/deployment-1.2>
>                 <http://geronimo.apache.org/__xml/ns/deployment-1.2
>                 <http://geronimo.apache.org/xml/ns/deployment-1.2>>>">
>                 <environment>
>                 <moduleId>
>                 <groupId>org.example.configs.______virtualhosts</groupId>
>                 <artifactId>virtualhost1</______artifactId>
>
>                 <version>1.0</version>
>                 <type>car</type>
>                 </moduleId>
>                 <dependencies>
>                 <dependency>
>                 <groupId>org.apache.geronimo.______configs</groupId>
>                 <artifactId>tomcat7</______artifactId>
>
>                 <type>car</type>
>                 </dependency>
>                 </dependencies>
>                 <hidden-classes/>
>                 <non-overridable-classes/>
>                 </environment>
>                 <gbean name="TomcatVirtualHost_1"
>                             class="org.apache.geronimo.______tomcat.HostGBean">
>                 <attribute
>
>
>                   name="className">org.apache.______catalina.core.StandardHost</______attribute>
>                 <attribute name="initParams">name=virtual______host1.com
>                 <http://virtual____host1.com>
>                 <http://virtual__host1.com> <http://virtualhost1.com>
>
>                                                                  appBase=
>
>                 workDir=work</attribute>
>                 <reference name="Engine">
>                 <name>TomcatEngine</name>
>                 </reference>
>                 </gbean>
>                 </module>
>                             -
>
>
>
>
>                         --
>                         Ivan
>
>
>
>
>                 --
>                 Ivan
>
>
>
>
>
> --
> Ivan

Mime
View raw message