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<[email protected]<mailto:[email protected]>>
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>
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<[email protected]<mailto:[email protected]>
<mailto:[email protected]<mailto:[email protected]>>>
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>>
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>>">
<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://virtualhost1.com>
appBase=
workDir=work</attribute>
<reference name="Engine">
<name>TomcatEngine</name>
</reference>
</gbean>
</module>
-
--
Ivan
--
Ivan
