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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Marc Farrow
