geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: Updating Configuring Virtual Host in Tomcat, for G3.0
Date Tue, 06 Mar 2012 07:50:15 GMT
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 <>

> 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<<mailto:r**<>
>>>> >>
>>>>    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.
>>>> deployment.html<>
>>>>    <**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<<mailto:r**
>>>> <>>
>>>>        <<**>>>
>>>>            I am going to start working on this document for G3.0
>>>> ____host-in-tomcat.html<>
>>>>        <**GMOxDOC30/configuring-virtual-**
>>>> __host-in-tomcat.html<>
>>>> >
>>>>        <**GMOxDOC30/configuring-virtual-**
>>>> __host-in-tomcat.html<>
>>>>        <**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
>>>>        <**xml/ns/deployment-1.2<>
>>>>        <**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**<>
>>>>        <>  <>
>>>>                                                 appBase=
>>>>                                                 workDir=work</attribute>
>>>>        <reference name="Engine">
>>>>        <name>TomcatEngine</name>
>>>>        </reference>
>>>>        </gbean>
>>>>        </module>
>>>>            -
>>>>        --
>>>>        Ivan
>>>> --
>>>> Ivan


View raw message