HI Russell,
This is getting interesting :-) Thanks for taking the time to explain
what you want in such detail.
Some comments inline and more at the end.
On Dec 5, 2008, at 12:03 PM, Russell E Glaue wrote:
David Jencks wrote:
On Dec 5, 2008, at 7:46 AM, Russell E Glaue wrote:
Being that Geronimo only allows one statically configured Jetty
instance,
configured as a GBean. And to get more instances, you have to
install
additional
Jetty gbeans under a new container name.
I'm wondering why you say jetty is statically configured. I look at
geronimo as a bunch of plugins and we happen to supply a server with
one particular jetty plugin installed. You are free to include a
different jetty plugin or additional jetty plugins or set up more
jetty servers in your web app plans. So I fear that we have really
failed to communicate the essence of geronimo :-(
Plus, being that there is only one NCSARequestLog gbean, which has
hard coded
the logfile name and location, and we are not able to change the
name and
location without recompiling.
Should Geronimo be modified to allow these to be dynamic?
You can change the files etc for the request log pretty easily in
config.xml by including something like this inside the module element
for jetty:
<gbean name="JettyRequestLog">
<attribute name="filename">---YOUR FILE NAME---</attribute>
<attribute name="logDateFormat">--YOUR DATE FORMAT---</
attribute>
<attribute name="logTimeZone">GMT</attribute>
</gbean>
There are a bunch more things you can configure... "filename",
"logDateFormat", "logTimeZone",
"retainDays", "extended", "append", "ignorePaths",
"preferProxiedForAddress"
but I'm not sure what all of them mean.
I think that being able to spawn multiple containers and reconfigure
log files
should be something dynamic, and configurable in the
var/config/config.xml file
without having to add additional gbeans/plugins.
Something like the following could result for configuration:
-
<module name="JettyWebContainer2"
gbean
="org.apache.geronimo.jetty6.connector.JettyWebContainerFactory">
...
</module>
<module name="NCSARequestLog2"
gbeanInfo
="org.apache.geronimo.jetty6.requestlog.NCSARequestLogFactory">
...
</module>
<module name="ContainerGroup"
gbean="org.apache.geronimo.jetty6.ContainerGroup">
<reference name="JettyContainer">
<name>JettyWebContainer2</name>
</reference>
<reference name="RequestLog">
<name>NCSARequestLog2</name>
</reference>
<reference name="ThreadPool">
<name>DefaultThreadPool</name>
</reference>
<reference name="ServerInfo">
<name>ServerInfo</name>
</reference>
</module>
-
Where JettyWebContainerFactory and NCSARequestLogFactory produce
separate
running instances of JettyWebContainer and NCSARequestLog
respectively.
Or with the Factory option, perhaps all that is needed is:
-
<module name="NCSARequestLog2"
gbeanInfo
="org.apache.geronimo.jetty6.requestlog.NCSARequestLogFactory">
...
</module>
<module name="JettyWebContainer2"
gbean
="org.apache.geronimo.jetty6.connector.JettyWebContainerFactory">
...
<reference name="RequestLog">
<name>NCSARequestLog2</name>
</reference>
</module>
-
But I think it would be a good idea to be able to group
configurations
together.
<class1>
<listen socket/>
<virtual server 1>
<hostname alias/>
<log configuration/>
<web application 1/>
</virtual server 1>
<virtual server 2>
<hostname alias/>
<log configuration/>
<web application 1/>
</virtual server 2>
<log configuration/>
</class1>
<class2>
<listen socket/>
<virtual server 1>
<hostname alias/>
<log configuration/>
<web application 1/>
<web application 2/>
<web application 3/>
</virtual server 1>
<log configuration/>
</class2>
Where each class is a separated Web Container.
What is the general opinion about this?
I'm not sure I understand how what you are proposing actually differs
from what we have now in any but cosmetic aspects. How does the
proposed WebContainerFactory differ from the existing WebContainer?
Right now, as I understand it, Geronimo only has one running
(default) instance
of Jetty inside of it.
And as I understand it, if I want multiple web applications
separated out among
two port numbers, I have to compile and add a gbean of the Jetty
Container, and
install it into Geronimo. This would allow me to have a second
instance of Jetty
inside of Geronimo, which appears to be necessary if I want to
deploy webapps to
two different ports.
I'm not sure what you mean by "compile". You need to write some kind
of geronimo plan for the new web server and deploy it. Options are,
in my order of preference (based on decreasing reusability):
1. write a geronimo plugin maven project, build the plugin in your
build system, and assemble a custom server including it. (I'd include
deploying your app as a plugin, with the jetty gbeans in the plan,
under this option -- this is similar to (3))
2. Use the same plan as from (1) but just deploy it into an existing
geronimo server
3. Include the gbeans from the same plan in the web app plan for the
app that will be using the server
4. include the gbean defs in config.xml in the existing jetty module.
(I think this requires a slightly different name for the gbeans.)
I really don't recommend (4) because there is no way to keep track of
what you've done or transfer the result to any other server.
Now say that I want to deploy 8 different ports, with lots of web
applications
distributed among those separate ports. As I continue to understand
it, I use
the default Jetty Container, and I must compile and add 7 more
gbeans of the
Jetty Container into Geronimo.
This is not dynamic, because if I want to add a new port, I have to
compile and
add in a JettyContainer gbean. If I want to delete a port, I ideally
will have
to remove a JettyContainer gbean.
By having a factory, like JettyContainerFactory, one can hopefully
be able to
eliminate ever having to compile and install a new JettyContainer
gbean.
So, instead of compiling and installing a JettyContainer gbean, as
has been
described in order to deploy onto another port, one would simple add
a few lines
of configuration to var/config/config.xml.
This configuration calls something like a JettyContainerFactory,
which creates,
initializes and starts a new JettyContainer that can be used to
serve webapps on
a different port as has been discussed.
As to my discussion, I am referring to my previous thread 2008-12-04
"How to
deploy web application to one port".
So how would WebContainerFactory differ from the existing
WebContainer?
"WebContainerFactory" creates, and initializes "WebContainer" as
called in the
var/config/config.xml file.
Without this type of feature, as I understand it, I have to compile,
and install
a new WebContainer (JettyWebContainer) gbean as a plugin to
Geronimo, and call
that container in my configuration (ref: "Structure.", "Tomcat
configuration."
http://cwiki.apache.org/GMOxDOC22/app-per-port-running-multiple-web-apps-on-different-ports.html)
.
So I would not have to install anything, but just add a
configuration to call
the factory to create a new instance dynamically instead.
We could come up with an xml schema for configuring jetty
containers --
this would map into the existing gbeans. This is pretty much a
cosmetic
change but would require a bunch of coding.
I am not quite sure what you are illustrating, but I think that is
what I am
trying to illustrate with the "factory". However, I do not see it as
a cosmetic
change, because in my proposal, I see this feature as eliminating
the need to
ever compile and install a new JettyWebContainer plugin in order to
be able to
serve through Geronimo on two different ports.
RIght now I'm suggesting you come up with a plugin modified from the
existing jetty plugin, build it with maven, and install it in your
server.... or, imitating the sample app, just add the gbeans for
the new
container to your app plan. I don't understand which of these
steps you
consider onerous or why.
If I only want to ever install one plugin modified from the existing
jetty
plugin, and never touch this again, then it is not onerous.
However, I want to be able to do this dynamically. I have a server
farm of 48
servers. I support about 30 projects and 70 to 80 web applications.
They are all
clustered, and load balanced behind a controller and accelerator. I
serve each
of the 30 projects on their own port. We are adding more projects
and more web
applications about every 3 months.
Having to compile and install this plugin on 48 servers everytime I
want to add
in support for another port becomes onerous. It is not onerous if
all I have to
do is add a few lines of configuration to do this for me.
I'd like you to look at two samples:
1. I added a couple of jetty samples to the app-per-port trunk
samples. Samples are set up so they work better if you check out all of
https://svn.apache.org/repos/asf/geronimo/samples/trunk
and build everything first. After that you can build the samples/app-
per-port separately if you want.
The two jetty samples are..
a. app-per-port-war1-jetty. This is a plugin that just includes one
sample war and a jetty server for it.
b. app-per-port-jetty. This is a plugin that includes an ear with two
web apps on different ports and is set up so the ports are not
available until after the apps start. This introduces a bit more
complexity but is how the tomcat sample works.
Anyway I think you'll see that it is pretty easy to include the
configuration of a jetty server in the web app plan (cf (a)).
This is set up to work against geronimo trunk (2.2-SNAPSHOT) but
should work just the same against earlier versions.
2. We've been working on clustering support recently and have some
things working. (this is only available in trunk). We'd certainly
appreciate your comments on it. There's some documentation here:
http://cwiki.apache.org/GMOxDOC22/plugin-based-farming.html
The sample I think is most useful is at
https://svn.apache.org/repos/asf/geronimo/sandbox/djencks/samples/admin/failover
This particular example is set up to use a nexus instance as the
geronimo plugin repository, so the idea is that your dev/qa processes
will end up deploying the plugin into a nexus instance. The cluster/
farm controller will then tell the servers in the cluster to install
the plugin from that nexus server. There are lots of other choices
for plugin repository: the failover sample in
https://svn.apache.org/repos/asf/geronimo/sandbox/failover
uses the cluster controller geronimo instance as the plugin
repository: this is set up so that you deploy the app to the
controller server (using an appropriate plan) and then distribute it
to the cluster members: thus it doesn't need a maven build for the
plugin.
These samples use an ejb app as the clustered app, and also
demonstrate ejb client failover. The cluster distirbution stuff works
just the same no matter what kind of plugin or app you are
distributing: we have some web clustering support (using wadi) but
don't have a web failover solution.
On that same line, I also need to be able to configure logging for
each
JettyContainer on each port (project), configuring the log name and
location. I
need separated log files, and I also need syslog facility.
What is the syslog facility? Do you know if it is available in plain
jetty?
I would like for us to migrate to Geronimo as our next platform. But
I would
need to have support in Geronimo like this.
We current use the Sun Java Web Server 6, which does something like
"container
grouping". It allows us to say, create this group, and in this group
start up a
JVM Web Container, listen on this socket (host, port), send your
logs to this
file, and serve these web applications. I can create as many groups
as I want.
And each group is separate from each other.
This sounds a lot like what you get in geronimo if you deploy
additional jetty servers as plugins and specify which jetty server
each app will use. There's a good chance the sun server makes it
easier to set up these additional containers, but can you see a
functional difference?
I'll try to look into the NCSA request log configuration soon....
Thanks.
I have tried to configure this without recompiling. I cannot
initialize a new
NCSARequestLog in the configuration, nor can I change the log file
name and
location, and so it appears my only option is to recompile.
And for multiple installed plugin WebContainers, as has been
proposed to me, it
would seem I have to also recompile and install a NCSARequestLog
plugin too.
So this will only add to the burden of compiling and installing
additional
plugins in order to get additional web containers so that Geronimo
can serve web
applications on different ports and log to different files for each
container.
The sample app hopefully convinced you that you can add a jetty server
for your web app by including something like this in the geronimo plan
for the app:
<gbean name="JettyWebConnector"
class="org.apache.geronimo.jetty6.connector.HTTPSelectChannelConnector">
<attribute name="host">localhost</attribute>
<attribute name="port">8082</attribute>
<attribute name="headerBufferSizeBytes">8192</attribute>
<reference name="JettyContainer">
<name>JettyWebContainer</name>
</reference>
<reference name="ThreadPool">
<name>DefaultThreadPool</name>
</reference>
<attribute name="maxThreads">50</attribute>
</gbean>
<gbean name="JettyWebContainer"
class="org.apache.geronimo.jetty6.JettyContainerImpl">
<attribute name="jettyHome">var/jetty1</attribute>
<!--<reference name="WebManager">-->
<!--<name>JettyWebManager</name>-->
<!--</reference>-->
<reference name="ServerInfo">
<name>ServerInfo</name>
</reference>
</gbean>
<gbean name="JettyRequestLog"
class="org.apache.geronimo.jetty6.requestlog.NCSARequestLog">
<reference name="JettyContainer">
<name>JettyWebContainer</name>
</reference>
<reference name="ServerInfo">
<name>ServerInfo</name>
</reference>
<attribute name="filename">var/log/jetty1_yyyy_mm_dd.log</
attribute>
<attribute name="logDateFormat">dd/MMM/yyyy:HH:mm:ss ZZZ</
attribute>
<attribute name="logTimeZone">GMT</attribute>
</gbean>
We could come up with some custom xml that would look something like
this for the same configuration:
<jetty-web-container name="JettyWebContainer1">
<jettyHome>var/jetty1</jettyHome >
<ServerInfo>
<name>ServerInfo</name>
</ServerInfo >
<HTTPSelectChannelConnector">
<host>localhost</host >
<port>8082</port >
<headerBufferSizeBytes>8192</headerBufferSizeBytes >
<ThreadPool>
<name>DefaultThreadPool</name>
</ThreadPool >
<maxThreads>50</maxThreads >
</HTTPSelectChannelConnector >
<NCSARequestLog>
<filename>var/log/jetty1_yyyy_mm_dd.log</filename >
<logDateFormat>dd/MMM/yyyy:HH:mm:ss ZZZ</logDateFormat >
<logTimeZone>GMT</logTimeZone >
</NCSARequestLog >
</jetty-web-containee>
(sorry about the indenting)
Does this seem a lot easier to understand than the "gbean" version?
thanks
david jencks
thanks
david jencks
-RG
