Re: [OT] A question on webapp building with ant with respect to changing property values in context.xml for non-local deployments only

[Marc Farrow <ma...@gmail.com>]

This is probably not the answer you are looking for, but we have a similar
situation here and this is how we have it managed.

Each programmer has his/her own instance of Tomcat5.5.9 (actually through
NetBeans).  We put all our Resources (Data Resources) in the Global area.
We then add all the resource links to the $tomcat_base/conf/context.xml
file.  If set up propertly, the resource links in this file will get
"copied" into the appname.xml for each application deployed under that
$tomcat_base.  Therefore, each programmer controls his/her resources, but
when we deploy the WAR file, the resource information is not deployed as it
is kept in the Tomcat files and not the context/application configuration
files.

hth.


On 4/20/06, Allistair Crossley <Al...@qas.com> wrote:
>
> 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
>
>


--
Marc Farrow