> > 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?
Ooops, It's the french acronym (Syst�me de gestion de base de donn�es) used for DBMS (Database management system) Arnaud > > > > > 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_dd > ehelp.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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
