You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Garth Keesler <ga...@gdcjk.com> on 2007/01/22 12:50:22 UTC
[configure] - context.xml vs Tomcat Admin
In the Tomcat Admin page, it is possible to configure data sources for
various services, in particular Axis2. All of the same info is input
that appears in the <Resource> section of the context.xml file. Are
these both accomplishing the same thing? Are they both required to
configure a DBCP data source? Is one preferable over the other? They
seem to be doing the same thing.
Just curious,
Garth
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configure] - context.xml vs Tomcat Admin
Posted by James Carman <ja...@carmanconsulting.com>.
The paranoid point of view can be a good thing. So far, though, it
has worked for us. We just have different "flavors" of our
build.properties file for each of our environments.
On 1/22/07, Craig McClanahan <cr...@apache.org> wrote:
> On 1/22/07, James Carman <ja...@carmanconsulting.com> wrote:
> >
> > "Using the server admin lets you take the same web application
> > and deploy it *unmodified* in different environments where you really
> > want to connect to different services (such as a testing server, a
> > staging server, and a production server)."
> >
> > If you make your build system smart enough, you can have it generate
> > your context.xml file with the correct settings (Velocity comes in
> > handy here) depending upon your targeted environment (test vs. prod).
> > I usually do this using a build.properties file in Ant. In order to
> > change your targeted environment, all you have to do is change the
> > build.properties file and that's it.
>
>
> Sure, you can do a lot more work in your build script if you want to :-).
>
> But, I have also seen lots of big shops that are totally allergic to testing
> one version of an app but then needing to build it again before deployment.
> They want to be sure the bits they test are *exactly* the bits that are
> actually deployed. For this scenario, having an ability to configure
> resources externally is extremely valuable.
>
> Come to think of it, this is very similar to the attitude we have in Apache
> projects, where a proposed release needs to have the actual bits we are
> voting on (versus a promise to build from a particular SVN tag or revision
> number later on).
>
> Craig
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configure] - context.xml vs Tomcat Admin
Posted by Craig McClanahan <cr...@apache.org>.
On 1/22/07, James Carman <ja...@carmanconsulting.com> wrote:
>
> "Using the server admin lets you take the same web application
> and deploy it *unmodified* in different environments where you really
> want to connect to different services (such as a testing server, a
> staging server, and a production server)."
>
> If you make your build system smart enough, you can have it generate
> your context.xml file with the correct settings (Velocity comes in
> handy here) depending upon your targeted environment (test vs. prod).
> I usually do this using a build.properties file in Ant. In order to
> change your targeted environment, all you have to do is change the
> build.properties file and that's it.
Sure, you can do a lot more work in your build script if you want to :-).
But, I have also seen lots of big shops that are totally allergic to testing
one version of an app but then needing to build it again before deployment.
They want to be sure the bits they test are *exactly* the bits that are
actually deployed. For this scenario, having an ability to configure
resources externally is extremely valuable.
Come to think of it, this is very similar to the attitude we have in Apache
projects, where a proposed release needs to have the actual bits we are
voting on (versus a promise to build from a particular SVN tag or revision
number later on).
Craig
Re: [configure] - context.xml vs Tomcat Admin
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
We are using Turbine and the framework uses commons-configuration. The
how-to is documented here:
http://jakarta.apache.org/turbine/turbine/turbine-2.3.2/howto/configuration-howto.html
We followed this example and turbine provides a configuration instance
for us.
Here is our xml for configuring turbine/commons-config:
---
<?xml version="1.0" encoding="ISO-8859-1" ?>
<configuration>
<jndi prefix="java:comp/env"/>
<properties fileName="WEB-INF/conf/TurbineResources.properties"/>
<system/>
</configuration>
---
This uses ( in order from lowest to highest priority ) system
properties, properties from the TurbineResources.properties file, then
jndi settings. If the property is in the file and in jndi, the jndi
value is used.
We've also done a similar thing as turbine in one of our own servlets.
Here is how we built up a config in a plain old servlet:
Configuration buildConfiguration() throws NamingException
{
CompositeConfiguration configuration = new
CompositeConfiguration(new JNDIConfiguration("java:comp/env"));
configuration.addConfiguration( new
ServletConfiguration(getServletConfig()) );
configuration.addConfiguration( new SystemConfiguration() );
return configuration;
}
This would use ( from lowest to highest priority ) any system settings,
then servlet config settings, then whatever is defined in jndi.
So when we deploy in tomcat we just use wars and have either all
settings for all webapps defined in conf/context.xml or we hand code
conf/Catalina/localhost/[webappname].xml files. ( we need to remove
write privs on the localhost dir above, otherwise tomcat will delete the
xml's when the war is re-deployed.) Then each tomcat is configured with
the correct settings for that installation ( like beta vs. production ).
I hope this helps a little.
Thorbjørn Ravn Andersen wrote:
> Jeffrey D. Brekke skrev den 23-01-2007 03:04:
>> Using commons-configuration, we use property files in our war as
>> defaults, then any container may redefine or define any property
>> specific to the container we've deployed into ( like beta,test, or
>> production ). We've used this setup with just settings ( string,
>> ints, etc ) or jdbc connection pools/resources.
>
> I am currently looking into this issue for our application, and I would
> appreciate if you would share your configuration snippet.
> Best regards,
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
http://www.bloglines.com/blog/jbrekke ekkerbj@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configure] - context.xml vs Tomcat Admin
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Jeffrey D. Brekke skrev den 23-01-2007 03:04:
> Using commons-configuration, we use property files in our war as
> defaults, then any container may redefine or define any property
> specific to the container we've deployed into ( like beta,test, or
> production ). We've used this setup with just settings ( string,
> ints, etc ) or jdbc connection pools/resources.
I am currently looking into this issue for our application, and I would
appreciate if you would share your configuration snippet.
Best regards,
--
Thorbjørn
Re: [configure] - context.xml vs Tomcat Admin
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
My experience is that having one artifact that will work on any
deployment lets you focus on the project, not the configuration. We now
have a testing, beta, and production tomcat setup, each once setup with
the correct jndi properties for our application ( we use
commons-configuration ) at each level. This way, we produce one
artifact ( war ) that can be deployed to all environments.
If your build system uses ant or maven to generate configuration, then
if your configuration changes, you need to rebuild/deploy those changes.
In our case, that was too slow.
Using commons-configuration, we use property files in our war as
defaults, then any container may redefine or define any property
specific to the container we've deployed into ( like beta,test, or
production ). We've used this setup with just settings ( string, ints,
etc ) or jdbc connection pools/resources.
James Carman wrote:
> If you make your build system smart enough, you can have it generate
> your context.xml file with the correct settings (Velocity comes in
> handy here) depending upon your targeted environment (test vs. prod).
> I usually do this using a build.properties file in Ant. In order to
> change your targeted environment, all you have to do is change the
> build.properties file and that's it.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
http://www.bloglines.com/blog/jbrekke ekkerbj@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configure] - context.xml vs Tomcat Admin
Posted by James Carman <ja...@carmanconsulting.com>.
"Using the server admin lets you take the same web application
and deploy it *unmodified* in different environments where you really
want to connect to different services (such as a testing server, a
staging server, and a production server)."
If you make your build system smart enough, you can have it generate
your context.xml file with the correct settings (Velocity comes in
handy here) depending upon your targeted environment (test vs. prod).
I usually do this using a build.properties file in Ant. In order to
change your targeted environment, all you have to do is change the
build.properties file and that's it.
On 1/22/07, Craig McClanahan <cr...@apache.org> wrote:
> On 1/22/07, Garth Keesler <ga...@gdcjk.com> wrote:
> >
> > So, if I read you right, I need to do one or the other but not both and
> > either one does pretty much the same thing. It also appears that doing
> > it in the Admin page does it for all Axis web services, right?
>
>
> You are correct about "one or the other but not both." So why two
> approaches?
>
> * Using context.xml makes it easier to deploy a self contained
> webapp that configures its own resources.
>
> * Using the server admin lets you take the same web application
> and deploy it *unmodified* in different environments where you really
> want to connect to different services (such as a testing server, a
> staging server, and a production server).
>
> The same general principles apply to things like configuring JDBC data
> sources, EJBs, and pretty much anything else you can look up via JNDI.
>
> Craig
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configure] - context.xml vs Tomcat Admin
Posted by Craig McClanahan <cr...@apache.org>.
On 1/22/07, Garth Keesler <ga...@gdcjk.com> wrote:
>
> So, if I read you right, I need to do one or the other but not both and
> either one does pretty much the same thing. It also appears that doing
> it in the Admin page does it for all Axis web services, right?
You are correct about "one or the other but not both." So why two
approaches?
* Using context.xml makes it easier to deploy a self contained
webapp that configures its own resources.
* Using the server admin lets you take the same web application
and deploy it *unmodified* in different environments where you really
want to connect to different services (such as a testing server, a
staging server, and a production server).
The same general principles apply to things like configuring JDBC data
sources, EJBs, and pretty much anything else you can look up via JNDI.
Craig
Re: [configure] - context.xml vs Tomcat Admin
Posted by Garth Keesler <ga...@gdcjk.com>.
So, if I read you right, I need to do one or the other but not both and
either one does pretty much the same thing. It also appears that doing
it in the Admin page does it for all Axis web services, right?
Thanx,
Garth
James Carman wrote:
> If you want to be able to just "drop in" your war file, then it's nice
> to just use the context.xml file.
>
> On 1/22/07, Garth Keesler <ga...@gdcjk.com> wrote:
>> In the Tomcat Admin page, it is possible to configure data sources for
>> various services, in particular Axis2. All of the same info is input
>> that appears in the <Resource> section of the context.xml file. Are
>> these both accomplishing the same thing? Are they both required to
>> configure a DBCP data source? Is one preferable over the other? They
>> seem to be doing the same thing.
>>
>> Just curious,
>> Garth
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configure] - context.xml vs Tomcat Admin
Posted by James Carman <ja...@carmanconsulting.com>.
If you want to be able to just "drop in" your war file, then it's nice
to just use the context.xml file.
On 1/22/07, Garth Keesler <ga...@gdcjk.com> wrote:
> In the Tomcat Admin page, it is possible to configure data sources for
> various services, in particular Axis2. All of the same info is input
> that appears in the <Resource> section of the context.xml file. Are
> these both accomplishing the same thing? Are they both required to
> configure a DBCP data source? Is one preferable over the other? They
> seem to be doing the same thing.
>
> Just curious,
> Garth
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org