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 <[email protected] <mailto:[email protected]>>
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<[email protected]
<mailto:[email protected]><mailto:[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>
<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]>>
<mailto:[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>>
<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
