geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: feature? ContainerGroup
Date Sun, 07 Dec 2008 00:58:17 GMT
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
>>
>


Mime
View raw message