geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Finishing up tomcat server.xml configuration work...
Date Tue, 14 Jul 2009 07:08:11 GMT
2009/7/14 David Jencks <david_jencks@yahoo.com>

> Hi Jeff,
> I'm afraid our points of view are rather different.  I've added some
> comments inline to try to explain my point of view.
>
> On Jul 13, 2009, at 11:14 PM, chi runhua wrote:
>
> Before we start working on documentation, I'd like to confirm what I
> understood so far is correct.
>
> We have 2 different scenarios: (1) users are going to develop new
> applications but they are used to the tomcat way; (2) users have existing
> application running on Tomcat, we'd like to provide a seamless way migrating
> to Geronimo.
>
> For (1), We support server.xml now because we want users to use Geronimo in
> the same way they used to be as in Tomcat, such as connector configuration,
> security realm, log configuration, valve and deploy method as well; in this
> case,
>
>
> Connector configuration  and deployment in geronimo are still completely
> different from tomcat.  Tomcat security realms won't integrate with geronimo
> security.
>



    What is the difference for the connector configuration between Geronimo
and Tomcat? Currently, all the connector configurations are in the
server.xml file.
    Ivan

>
> Geronimo will take care of users' applications and provide run-time
> environment. Anyway, we will recommend users to adopt GBean usage for Web
> container configuration instead of using server.xml, which we can demostrate
> the up-sides of Geronimo architecture using app-per-port sample;
>
>
> The only reason I can see to configure a tomcat server using gbeans rather
> than server.xml is if you have a legacy server configuration that you don't
> want to convert.  In my view using a server.xml is a lot more convenient
> than the individual gbeans.
>
>
> As for (2), users can simply copy their server.xml into /var/catalina by
> overwriting the one in Geronimo,  and for example, user need to copy the
> applications to /var/catalina/web-apps/. There would be nothing different
> from the old days. Geronimo will provide run-time enviornment.
>
>
> I'd really prefer that we emphasize server assembly using geronimo plugins
> rather than manual file copying.  The two ways I've thought of so far for
> setting up a tomcat server is by replacing the tomcat plugin we ship or by
> unpacking a server.xml from a plugin to overwrite the server.xml we ship.
>  The second method seems unreliable to me, what happens if you deploy 2 such
> plugins?
>
> I haven't checked but I hope that tomcat hot deployment doesn't work.  IMO
> web apps should be deployed using a geronimo plan basically as they are
> today.  If copying an app into a tomcat hot deploy folder does work, the
> result won't relate to geronimo services in any way (for instance jndi,
> transactions, security).
>
>
>
> In either scenario, users' apps will be untouched and cann't be used as
> geronimo plugin because they are still tomcat-specific.
>
>
> Web apps should still be deployed as plugins using a geronimo plan.
>  Otherwise they will not get any benefit from running in geronimo rather
> than plain tomcat: they won't have access to geronimo jndi, transactions,
> security, ejbs, or any other services.
>
>
> At the moment we don't support context.xml files.  It would be great if we
> did but that would require quite a bit more work.
>
> thanks
> david jencks
>
>
> Anything incorrect, please hop in.
>
> thanks
>
> Jeff C
>
>
> On Tue, Jul 14, 2009 at 8:50 AM, David Jencks <david_jencks@yahoo.com>wrote:
>
>> IMO our way of configuring the tomcat server using server.xml is working
>> fine and the main remaining bits are really documentation.  Since I am
>> terrible at documentation I hope others will take it upon themselves to help
>> with it :-)
>>
>> I'd like to see
>>
>> -- a list of stuff that doesn't work in geronimo.  My recollection is that
>> the main things that don't work are configuring jndi (such as deploying
>> datasources) and realms (this might actually work, I'm not sure).
>>
>> -- at least one sample of how to use it.  I think a good starting point
>> would the the app-per-port sample that shows how to have 2 web apps each
>> exposed on a different port.  This requires setting up 2 entire tomcat
>> servers and I think would be a nice example of the simplicity of the
>> server.xml configuration compared with the gbeans we used up till now.  I
>> think I'd consider deploying the server.xml in a plugin that completely
>> replaces the existing tomcat plugin.
>>
>> thoughts?
>>
>> many thanks
>> david jencks
>>
>
>
>


-- 
Ivan

Mime
View raw message