Pid wrote:
> On 14/12/2009 16:21, Mario Splivalo wrote:
>> Is there a way to 'parametrize' context.xml, for instance, in a manner
>> one can 'parametrize' build.xml?
>>
>> For some webapplication in context.xml one puts, for instance, JDBC
>> specific stuff. But, several developers can have different 'properties'
>> for the database (different user accounts, and so on).
>>
>> Is there a way to parametrize those somehow, or each developer need to
>> have separate context.xml?
>
> Despite the other helpful answers, I'm going to try a different tack.
>
> If each developer needs the web app to behave differently, then each
> developer will need their own version.
>
> In order to apply different settings, such as a DB user, one would need
> to restart the application - thus breaking it for other developers.
Actually, each developer has his own Tomcat installation as well as the
application we're all working on. It's just that some use different
Linux distros, some use Windows. I needed a way to include context.xml
in the SCM, but for each developer to have it's own personal version. I
have logger setup, database realm setup (among other thins) in
context.xml. Some developers use Debian with Postgres installed from
packages (so they use postgres system acount for database access on
their workstations), others use custom Postgres installation for Windows
(so they use different username/password for connection to the
database). Some have log files in /var/local/log/tomcatapps/app1/,
others have D:\Projects\WhereIPutMyStuff\ForToday.
Then, production server has Tomcat installed on Debian servers according
to the Debian Policy FSH.
I needed a way to have context.xml in scm, but with a way for each
developer to has his own 'settings'.
Using ant, as nice people described earlier, gives me just that (with a
little bit of overhead - one needs to know that context.xml definition
has changed, and issue 'ant reinitialize' (or whatever) task to build
proper context.xml.
So, I'm happy! :)
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
