You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2009/07/14 02:50:01 UTC
Finishing up tomcat server.xml configuration work...
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
Re: Finishing up tomcat server.xml configuration work...
Posted by David Jencks <da...@yahoo.com>.
On Jul 14, 2009, at 12:08 AM, Ivan wrote:
>
>
> 2009/7/14 David Jencks <da...@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.
I think I confused two possible meanings of "connector'. I (now)
imagine you and Jeff are thinking of the web listener coyote
connectors which should definitely configured in server.xml. For some
reason -- it no longer makes any sense to me -- I was thinking of j2ca
connectors, in particular database pools.
sorry for the confusion
david jencks
> 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
>> <da...@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
Re: Finishing up tomcat server.xml configuration work...
Posted by Ivan <xh...@gmail.com>.
2009/7/14 David Jencks <da...@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 <da...@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
Re: Finishing up tomcat server.xml configuration work...
Posted by David Jencks <da...@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.
> 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
> <da...@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
>
Re: Finishing up tomcat server.xml configuration work...
Posted by chi runhua <ch...@gmail.com>.
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, 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;
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.
In either scenario, users' apps will be untouched and cann't be used as
geronimo plugin because they are still tomcat-specific.
Anything incorrect, please hop in.
thanks
Jeff C
On Tue, Jul 14, 2009 at 8:50 AM, David Jencks <da...@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
>