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 Wed, 10 Dec 2008 07:28:46 GMT

On Dec 9, 2008, at 10:01 PM, chi runhua wrote:

> Excellent discussion. Besides adding the WebContainer and relevant  
> log via plan.xml, I am wondering whether Geronimo would be more  
> accessible if Admin Console have a wizard about this great feature??
>

It might be plausible for jetty where the web container architecture  
is fairly straightforward but I'd hate to try to construct something  
for tomcat.

However for jetty it might be even better to get a virtual host like  
feature but for ports so you only need one web container to start with.

If we do go farther in encouraging people to set up more web  
containers I think coming up with a custom schema would be highly  
advisable.

Personally I think that until enough people show up who understand  
portlet design well enough to significantly clean up the existing  
console we might want to hold off on lots more complicated features.

thanks
david jencks

>
> Jeff
>
>
> On Tue, Dec 9, 2008 at 2:24 AM, Russell E Glaue <rglaue@cait.org>  
> wrote:
> David Jencks wrote:
> > HI Russell,
> >
> > This is getting interesting :-)  Thanks for taking the time to  
> explain
> > what you want in such detail.
>
> This is very good. This thread gives me more insight on geronimo  
> operations than
> described in the wiki and other documentation.
> And I hope it does the same for other readers of this thread trying  
> to deploy
> Geronimo on an enterprise level like I am.
>
> >
> > 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 :-(
>
> I saw it as "statically configured" because you could not add more  
> Jetty
> containers through simple configuration change in var/config/ 
> config.xml.
> However, Geronimo has also not technically statically configured a  
> Jetty Container.
>
> I now understand what was being described. I thought what was being  
> told to me
> was that I had to copy the entire Jetty gbean code into a new gbean,  
> and rename
> the actual class names.
> But this is not true.
> I understand now that one simple writes a new gbean plan (plan.xml)  
> file, and
> packages only that single file into a gbean, and then deploy it to  
> get the
> additional Jetty container.
>
> The examples you referenced below, particularly the app-per-port- 
> jetty sample,
> finally made everything very clear.
>
> https://svn.apache.org/repos/asf/geronimo/samples/trunk/samples/app-per-port/app-per-port-jetty/src/main/plan/plan.xml
>
> As the example is written, this single plan file is all that is  
> needed to deploy
> two separate Jetty containers with separate log files.
>
> Thank you for this example.
> All this time, I was looking to make these changes in the var/config/ 
> config.xml
> file. Now i understand that the config.xml file is only used to make  
> localized
> changes to already deployed gbeans. And I cannot create a new  
> instance of a
> gbean in this config.xml file. gbean instances must be deployed as  
> new gbeans.
>
> Since the Jetty Container code already exists in Geronimo, the code  
> does not
> need to be redeployed in a new gbean. All that is needed is to  
> deploy a new plan
> file to create a new Jetty Container instance based on the existing  
> Jetty
> Container code.
>
> >
> >>>>
> >>>>
> >>>> 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 understand what they all mean, and are documented on the Geronimo  
> wiki for
> anyone looking for this information.
>
> Yes, I have verified this has worked. Thank you.
> Because of my realization I described above, I understand I am only  
> changing the
> configuration of an existing "JettyRequestLog" gbean.
> All this time I was attempting to edit var/config/config.xml to  
> create a new
> instance of a JettyRequestLog, and put that reference in the  
> JettyWebContainer -
> which always failed.
> A new plan must be deployed that contains a new instance of the
> "JettyRequestLog" gbean. Then I can change that configuration.
>
> Again, the examples you referenced below, particularly the app-per- 
> port-jetty
> sample, finally made everything very clear.
>
> >
> >>>>
> >>>> 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.
>
> option #2 (and #1) is how the example sample app you provided,
> app-per-port-jetty, is accomplished.
> The app-per-port-jetty sample only has a single plan file.
> You build that in Maven as a gbean plugin, and deploy it to Geronimo.
>
> My error, as I said before, was because I thought I had to copy the  
> actual
> JettyContainer code into a new gbean, renaming the class names, and  
> recompiling.
> There is no code compilation needed, as no code is actually deployed  
> in the
> gbean, only a single plan file is what is deployed.
>
>
> Below, I descibed something like a "factory" because I was looking  
> at the
> perspective of creating the result of these gbeans in the config.xml  
> file
> dynamically.
> So instead of building the single plan file in a gbean and deploying  
> it in
> Geronimo to get the result, I was discussing that something like the
> configuration defined in the plan file was instead put in the
> var/config/config.xml file to get the same results.
>
> However the gbean plugin is the better approach. Putting this  
> information in the
> config.xml file would require a restart/reload of Geronimo.
> Instead as a gbean, we simply deploy and undeploy.
> Also, as a gbean, we can do something very wonderful in managing a  
> server farm,
> and you have illustrated that advantage below.
> By dynamically distributing the gbean to servers based on deployment  
> needs.
>
> >
> >>
> >>
> >> 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.
>
> Yes, this example sample explains how easy it is.
>
> >
> > 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
>
> I reviewed this, shortly, and one missing item that comes  
> immediately to mind is
> in the "Farming using Plugins" section.
> It is written:
> -
> When the administration server detects this as new it instructs the  
> new node to
> install all the plugin lists associated with that farm. If the  
> plugins are
> already installed, this is a no-op; otherwise the plugins are  
> downloaded and
> installed from the plugin repository specified in the plugin list.
> -
>
> It says, -If the plugin is already installed, it is not reinstalled.-
>
> What needs to be taken into account is if the plugin is already  
> previously
> installed, but the plugin has been updated since the last install.
>
> So example in case: if myFunPlugin, version 1.3, was installed in  
> July, and the
> server has been ordered to installed myFunPlugin in August, the  
> server should
> not simply say "I already have it installed, so I do not have to  
> install it again."
>
> The server should also not simply do "I already have it installed,  
> so I will
> uninstall it and install it again."
>
> The server should do "Hmmm. I already have the myFunPlugin plugin  
> installed.
> Well, let's see, the version I have installed is 1.3, and the  
> current version of
> this plugin is 1.4. Okay, I need to install the new version of this  
> plugin.
>
> On the next days' server restart, the server should analyze that the  
> current
> installed version is 1.4 and the current version is 1.4, and this in  
> this case
> this would be a "no-op" and do nothing.
>
> >
> >  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.
>
> I looked at the 5 sample projects in the first directory, and the 4  
> in the
> second directory.
> I can guess by their name what they might do, however there is  
> nothing contained
> in them to explain enough to me their purpose and usage.
>
> I do see The Grinder version 3 in the samples failover-tomcat-demo and
> failover-jetty-demo.
> We use The Grinder here to load-test our servers.
> I do not see how they are used to implement failover.
>
> >
> > 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.
>
> When you say "web failover" you mean a scenario where server A, B  
> and C are
> running, and server C and D are on standy. Server B is detected to  
> go down, and
> the apps on server B are redeployed to server C and/or D.
>
> Yes, we are researching this level of technology here in our center.
> We use virtual instances however, and a virt is paused and  
> transferred to
> another server once problems are experienced. Or if the user demand  
> goes beyond
> our deployed server capacity, new virt servers are brought online  
> and added to a
> cluster.
>
> We have Red Hat Satellite Server, and we can "kick-start" new virts  
> dynamically
> as needed.
>
> >
> >>
> >>
> >> 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?
>
> Plain jetty has it, only as built in to log4j.
> Here is the sample:
>
> file: Jetty/extra/resources/log4j.xml
> -
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";
> debug="false">
> ...
> <!-- Syslog events
> <appender name="SYSLOG" class="org.apache.log4j.net.SyslogAppender">
> <param name="Facility" value="LOCAL7"/>
> <param name="FacilityPrinting" value="true"/>
> <param name="SyslogHost" value="localhost"/>
> </appender>
> -->
> ...
> </log4j:configuration>
> -
>
> However, We use Syslog to send all our access logs to a centralized  
> server.
> Although geronimo.log, the "error" log, is log4j, configured in
> var/log/server-log4j.properties - It looks like NCSARequestLog, the  
> "access"
> log, is not Log4j
>
> Do you know any more about this?
>
> Syslog is an operating system level logging mechanism.
> OS application send their logs to the syslog daemon in addition to,  
> or instead
> of, to a file.
> The syslog manages the log information, sending it to disk or over  
> the network
> to a centralized logging server.
>
> http://en.wikipedia.org/wiki/Syslog
>
> The syslog facility is something like a group. The group is  
> configured to
> operate in some fashion, so you can do something like send this  
> facility to this
> log file, and send this facility to this centralized log server.
>
> >
> >>
> >>
> >> 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?
>
> Yes, I now see the functional similarities.
> Especially since I can configure in the plugin plan a particular web
> application, and what web container it is deployed to.
> -
> <application>
>    <module>
>        <web>war1.war</web>
>        <web-app>
>            <web-container>
>                <gbean-link>JettyWebContainer1</gbean-link>
>            </web-container>
>        </web-app>
>    </module>
>    ...
> </application>
> -
>
> The schema for this configuration is "schema/geronimo- 
> application-2.0.xsd".
> <web></web> attribute is the URI path to the web archive relative to  
> the
> enterprise application package main directory.
>
> So it would appear that this all has to be contained in a EAR or  
> plugin.
> I cannot set the web application as being on disk with this  
> configuration.
>
> However, it can be deployed from disk using the --inPlace option of  
> the deploy
> commamd, as log as we define the web container (i.e.  
> JettyWebContainer2) in the
> web application's geronimo-web.xml file.
>
>
> So, what is the functional difference?
>
> Sun Web Server allows this information, including expaned web  
> application on
> disk, to be defined in the main server configuration, and the web  
> application
> does not need to have something similar to "geronimo-web.xml"
>
> As a result, the developers can remain ignorant of the internal sun  
> web server
> configuration, and there is not a chance of them messing this up,  
> and/or
> accidentially deploying to the wrong web container.
> Also, the context-root is defined in this server configuration so  
> that cannot be
> messed up by the developers too.
>
> With Geronimo, we can still deploy the web applications to the web  
> container
> after the web container has been deployed in a plugin via the  
> plugin's plan.
> We just use the `deploy --inPlace ...` command.
> However the developer must have a geronimo-web.xml file that defines  
> the web
> container the web application is deployed to.
> Also the context-root must be defined in geronimo-web.xml by the  
> developer as well.
>
>
> In result, more server-type administration must be controlled by the  
> developer,
> and taken away from the web server farm administrators.
>
> This is not necessarily a bad idea. But will require more and  
> specific training
> to the developers. And more errors are prone to pop up as a result.
>
> With the sun web server, server configuration, since the server farm
> administrators defined the on-disk location of the extracted web app  
> war and the
> context-root of the web app, this configuration dictation was put  
> into a central
> configuration system and administration tasks which made it  
> impossible for
> anyone to mess up.
>
>
> Actually there is an argument for "best practices" in both methods.  
> So one
> method may not be better than the other.
>
>
> >>
> >>>
> >>> 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?
>
> I understand the gbean version better.
> Because in that version, I now see the two levels of configuration.
>
> In Sun Web Server, there is only one level of configuration.  
> Everything is
> configured in the server configuration file, and web application  
> specifics in
> the deployment plan, sun-web.xml.
>
> In Geronimo, there are two levels.
> At the first level, the underlying gbean plugin defines the instance  
> of a gbean,
> plus default configuration.
> At the second level, the server configuration file allows localized
> configuration of those instances.
>
>
> The difference is that for Sun, when you define a new localized  
> configuration
> for an instance, Sun Web Server dynamically spawns off a new  
> instance with your
> localized configuration - like dynamically installing a new plugin and
> configuring it.
> Geronimo requires the instance to be defined on the plugin level  
> first, before
> is can be configured in the server configuration.
>
> Also another difference is that Sun Web Server requires a restart  
> after doing
> this type of configuration. However, geronimo does not, resorting to  
> a simple
> deploy/undeploy of this configuration. But it would seem, however,  
> if you wanted
> to make localized configuration of the plugin, then that would  
> require a restart
> of Geronimo since you would be editing the main server configuration  
> file.
>
> >
> > thanks
> > david jencks
> >
> >
> >>
> >>
> >>>
> >>> thanks
> >>> david jencks
> >>>
> >>>>
> >>>>
> >>>>
> >>>> -RG
> >>>
>
>
> Over all, I think the information revealed in this thread is not  
> understood by
> the general users of Geronimo. And I think that it is information  
> that is sought
> after.
> The wiki presents a lot of information, however there is no simple  
> approach to
> geronimo terms and ideas.
>
> For example, I wrote a 3-part article for MySQL Dev Zone:
> http://dev.mysql.com/tech-resources/articles/failover-strategy-part1.html
>
> My approach was to provide a slow introduction to the topic of "fail- 
> over" and
> "load-balancing", providing as much written examples as I could,  
> starting from
> simple illustrations and building on them.
> I think information in the wiki could approach this subject we  
> discuss in the
> same manner.
> The example sample apps you linked in this thread really is what  
> cleared up any
> confusion I had.
>
> Additionally, I do not see any clear information in the wiki on how  
> to set up
> something like we are discussing in this thread.
> For example, nowhere in the wiki can I find how to change the  
> default name and
> location of the log files.
> There is no clear documentation for setting up multiple containers  
> and deploying
> web applications to them.
>
> I think there could be scenario-based documentation that illustrates  
> how to go
> from the packaged software to the resulting installation to satisfy  
> the scenario.
>
> For example, pointing at my previous thread "GERONIMO_HOME vs.  
> GERONIMO_BASE",
> which resulted in a bug fix, and eventual elimination of  
> GERONIMO_BASE for
> Geronimo 2.1.4.
> Documentation on how Geronimo is intended to be configured is not  
> complete. And
> documentation on how internals are to be used in deployment is not  
> complete.
> Although very good, what we have a lot of documentation on is: The  
> resulting
> changes the author has made to do achieve some desired function. Or  
> in other
> words, 'this is what to configure to achieve point B.'
>
> It is all very good. However, I think some additional documentation  
> with this
> approach I discuss would help people get from point A to point B.
> The users just need to understand where the starting point begins,  
> then, like
> me, it will unlock any confusion to the remaining written  
> documentation.
>
> If my organization can successfully move forward with deploying  
> Geronimo in the
> enterprise, I am able to contribute this to the community, and can  
> document my
> process as I move forward.
>
>
> Also, I am interested in working with the Geronimo farming  
> technology. It seems
> like something that would be really useful to my organization.
>
>
> Thank you very much.
> -RG
>


Mime
View raw message