Oops! I accidentally replied directly to Arnaud rather than the list.
For completeness, here is the additional dialog with Arnaud. If
anybody has further input, please don't hesitate to provide it.

Thanks again Arnaud! By the way, what is SGBD?

>
> Thanks Arnaud! That appears to be right on topic, as far as I
> am concerned!

Hope this help ;-)

>
> My additional question may be off topic though, which is, how
> can I achieve the same thing using WebLogic and WebSphere? I
> imagine that these app servers must support something similar
> to the Tomcat context files. Can anybody point me in the
> right direction?

I didn't use weblogic or websphere since several months...
I remember that in weblogic it was possible to define external
resources (SGBD, ..) in the management console.
I think that there are some other solutions
(http://edocs.beasys.com/wls/docs61/ConsoleHelp/webservices_ddehelp.html)
but I never
tried them

>
> [As an aside, since your Tomcat context files are specific to
> each environment, do you maintain them under source control?
> If so, where do you keep them within your project structure?]

Personally we store them in src/deployment/tomcat
But we didn't yet create a mechanism to deliver them automatically to our team
It's on our todo list ..


Arnaud

>
> On 5/12/05, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > This is a little bit off topic but ...
> >
> > We often deploy my web applications on tomcat.
> > What we do is to define some deployment parameters on our
> web applications (web.xml) :
> > Some parameters
> > <context-param>
> >  <param-name>environment</param-name>
> >  <param-value>Development environment</param-value>
> </context-param>
> > <context-param>  <param-name>scriptInterpreter</param-name>
> >  <param-value>/bin/sh</param-value>
> > </context-param>
> > ...
> > A SGBD :
> > <resource-ref>
> >        <description>Oracle Datasource</description>
> >        <res-ref-name>jdbc/mySQBD</res-ref-name>
> >        <res-type>javax.sql.DataSource</res-type>
> >        <res-auth>Container</res-auth>
> > </resource-ref>
> >
> > We deliver the war to others team (tests, production, ...) and they
> > define the own deployment settings in tomcat with a context file
> > :
> > <Context path="/ourWebApp" docBase="ourWebApp.war" debug="0">
> > <Parameter name="environment" value="Integration environment"
> > override="false"/>  <Resource name="jdbc/mySGBD" auth="Container"
> > type="javax.sql.DataSource"/>  <ResourceParams name="jdbc/mySGBD">
> >    <parameter>
> >      <name>factory</name>
> >      <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
> >    </parameter>
> >    <parameter>
> >      <name>driverClassName</name>
> >      <value>oracle.jdbc.driver.OracleDriver</value>
> >    </parameter>
> >    <parameter>
> >      <name>url</name>
> >      <value>jdbc:oracle:thin:@localhost:1521:mySGBD</value>
> >    </parameter>
> >    <parameter>
> >      <name>username</name>
> >      <value>myUser</value>
> >    </parameter>
> >    <parameter>
> >      <name>password</name>
> >      <value>myPassword</value>
> >    </parameter>
> >    <parameter>
> >      <name>maxActive</name>
> >      <value>20</value>
> >    </parameter>
> >    <parameter>
> >      <name>maxIdle</name>
> >      <value>10</value>
> >    </parameter>
> >    <parameter>
> >      <name>maxWait</name>
> >      <value>-1</value>
> >    </parameter>
> >    <parameter>
> >      <name>removeAbandoned</name>
> >      <value>true</value>
> >    </parameter>
> >    <parameter>
> >      <name>removeAbandonedTimeout</name>
> >      <value>60</value>
> >    </parameter>
> >    <parameter>
> >      <name>logAbandoned</name>
> >      <value>true</value>
> >    </parameter>
> >    <parameter>
> >      <name>validationQuery</name>
> >      <value>SELECT 1 FROM DUAL</value>
> >    </parameter>
> >  </ResourceParams>
> > </Context>
> >
> > We filter resources only to copy pom informations in our
> web application (the current release for example).
> >
> > Arnaud
> >
> > > -----Message d'origine-----
> > > De : Charles Daniels [mailto:[EMAIL PROTECTED] Envoy�
> : vendredi
> > > 13 mai 2005 01:10 � : [email protected] Objet : Maven Best
> > > Practices
> > >
> > > Hi All,
> > >
> > > The Maven documentation is looking great! I have read the
> section on
> > > Best Practices
> > > (http://maven.apache.org/using/bestpractices.html) and have a
> > > question regarding generating deployments. One bullet
> point states
> > > the following:
> > >
> > > "Avoid the need to filter resources. While this can be
> useful in a
> > > development environment, it usually requires rebuilding of an
> > > artifact between different phases of deployment. The best
> > > alternative is to externalise the configuration - for example in
> > > J2EE (where this is a common occurrence), make sure all
> configurable
> > > information such as database connection properties are in the
> > > deployment descriptor, provided through JNDI outside of
> the webapp
> > > or other deployable item.
> > > This means the particular artifact can be deployed
> identically into
> > > different servers, with just the external configuration
> differing."
> > >
> > > Can somebody elaborate on how to achieve this? I certainly would
> > > love to be able to do this, as this is one of the pain
> points I have
> > > on my projects. Currently we have separate properties files
> > > containing settings for our separate deployment
> environments. When
> > > we build our webapps for deployment, we specify the target
> > > environment so that we filter resources with the corresponding
> > > properties file. This ensures that the configuration
> files deployed
> > > with the application contain the settings appropriate for
> the target
> > > environment.
> > >
> > > How can we use the best practice quoted above to avoid this?
> > > What do others do to address this issue?
> > >
> > > Thanks,
> > > Chuck
> > >
> > >
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to