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<rgl...@cait.org<mailto:rgl...@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>
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<rgl...@cait.org<mailto:rgl...@cait.org>
<mailto:rgl...@cait.org<mailto:rgl...@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>>
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
