tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allistair Crossley" <Allistair.Cross...@QAS.com>
Subject [OT] A question on webapp building with ant with respect to changing property values in context.xml for non-local deployments only
Date Thu, 20 Apr 2006 09:29:16 GMT
Hi All,

Apologies for the OT, but I hoped I could source some expertise :) Our
development environment looks a bit like this:

VSS | Eclipse | LOCAL | STAGING | PRE-LIVE | LIVE1/LIVE2 |
==========================================================
    |         | DEV1  |         |          |             |
    |         | DEV2  |         |          |             |
    |         | DEV3  |         |          |             |
    |         | DEV4  |         |          |             |
    |         | DEV5  |         |          |             |
    |         | DEV6  |         |          |             |

Each developer has their own local Tomcat instance, and can develop
independently of others. All developers use Eclipse, which uses the VSS
plugin to talk to the VSS source repository. We configure the web
application using META-INF/context.xml. This context.xml contains
several named data sources that on a local machine point to the same
(test) database server and database name, i.e

<Resource 
  name="jdbc/cms" 
  jdbcUrl="jdbc:jtds:sqlserver://dbsvr0:1433/dbName" 
  .. snip ..
/>

<Resource 
  name="jdbc/web" 
  jdbcUrl="jdbc:jtds:sqlserver://dbsvr0:1433/dbName" 
  .. snip ..
/>

But which, when deployed out to the staging, pre-live and live servers
branch to different database servers, e.g dbsvr1 and dbsvr2
respectively.

When developing locally, developers keep their web app source up to date
with latest versions, including the context.xml, and when they compile
in Eclipse, via MyEclipse, this is deployed to their local Tomcat, i.e
Ant is not needed at this stage.

However, to do the database branching and other property replacements
when deploying to other servers, we necessarily use Ant.

I setup a build.xml that uses named properties files and string
replacements to search for substrings within the context.xml in order to
replace db server names, e.g

ant -Dserver=staging deploy

And a typical replace might look like this

<replace 
  file="${webapp.build.path}/META-INF/context.xml" 
  token="dbsvr0" 
  value="${db.server.0}" />

This has worked until today, where I (as illustrated by the Resource
declarations earlier) need to have 2 data sources which are identical in
the context.xml in all but JNDI name. 

So that when I now deploy to staging, both the dbsvr0 strings get
replaced with the value of db.server.0 in the properties file. What I
actually need is to replace one with db.server.0 and one with
db.server.1 but substring matching is not going to cut it.

This is kind of an open-ended email to find out if anyone has a
different strategy where they do not use ant to build locally from
central config files, but do modify them outbound to other servers, and
also branch in this way. I can't see a way around this if I continue
using the replace task :(

Cheers for your time, Allistair.


<FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE> 
-------------------------------------------------------
QAS Ltd.
Registered in England: No 2582055
Registered in Australia: No 082 851 474
-------------------------------------------------------
</FONT> <FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLACK> 
Disclaimer:  The information contained within this e-mail is confidential and may be privileged.
This email is intended solely for the named recipient only; if you are not authorised you
must not disclose, copy, distribute, or retain this message or any part of it. If you have
received this message in error please contact the sender at once so that we may take the appropriate
action and avoid troubling you further.  Any views expressed in this message are those of
the individual sender.  QAS Limited has the right lawfully to record, monitor and inspect
messages between its employees and any third party.  Your messages shall be subject to such
lawful supervision as QAS Limited deems to be necessary in order to protect its information,
its interests and its reputation.  

Whilst all efforts are made to safeguard Inbound and Outbound emails, QAS Limited cannot guarantee
that attachments are virus free or compatible with your systems and does not accept any liability
in respect of viruses or computer problems experienced.
</FONT>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message