You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Nilesh Bhattad <ni...@outlinesys.com> on 2004/12/06 15:50:59 UTC
Common practice to maintain sql maps and properties file
Folks,
This is how I keep all the mapping files, SqlMapConfig.xml(each per application) and 1 common SqlMapConfig.properties which has the database connection parameters for all the applications.
src
|
|
|___ XML.app1.ibatis.maps
| |
| |___ all mapping files, SqlMapConfig.xml
|
|
|___ XML.app2.ibatis.maps
| |
| |___ all mapping files, SqlMapConfig.xml
|
|
|___ SqlMapConfig.properties
With this approach, all these files become part of the WAR. And I think this is not a workable solution if I have to deploy the project onto QA and further environments.
Just wondering, how do you guys maintain these config files? Do you keep it in current working directory so that they are not part of WAR and each environment can configure database connection parameters seperately? Also, if I keep SqlMapConfig.properties inside current working directory, how do I access it inside SqlMapConfig.xml?
Help please!
Regards
Nilesh
Re: Common practice to maintain sql maps and properties file
Posted by Clinton Begin <cl...@gmail.com>.
You could use the URL syntax (i.e.
file:///usr/local/blah/my.properties) to point to your database
properties file. Although, I've always been a fan of building
separate WAR files for each environment. Same build, different
configuration. Ant populates environment properties and builds a war
for each one.
Cheers,
Clinton
On Mon, 6 Dec 2004 09:50:59 -0500, Nilesh Bhattad <ni...@outlinesys.com> wrote:
>
> Folks,
> This is how I keep all the mapping files, SqlMapConfig.xml(each per
> application) and 1 common SqlMapConfig.properties which has the database
> connection parameters for all the applications.
>
> src
> |
> |
> |___ XML.app1.ibatis.maps
> | |
> | |___ all mapping files, SqlMapConfig.xml
> |
> |
> |___ XML.app2.ibatis.maps
> | |
> | |___ all mapping files, SqlMapConfig.xml
> |
> |
> |___ SqlMapConfig.properties
>
>
> With this approach, all these files become part of the WAR. And I think this
> is not a workable solution if I have to deploy the project onto QA and
> further environments.
>
> Just wondering, how do you guys maintain these config files? Do you keep it
> in current working directory so that they are not part of WAR and each
> environment can configure database connection parameters seperately? Also,
> if I keep SqlMapConfig.properties inside current working directory, how do I
> access it inside SqlMapConfig.xml?
>
> Help please!
>
> Regards
> Nilesh
>
Re: Common practice to maintain sql maps and properties file
Posted by Brice Ruth <bd...@gmail.com>.
I get around this by using JNDI - I can then configure JNDI
independently in my deployment environments (Test/Stage/Production)
and the JNDI reference that iBatis uses never changes.
Just another idea.
Brice
On Mon, 6 Dec 2004 09:50:59 -0500, Nilesh Bhattad <ni...@outlinesys.com> wrote:
>
> Folks,
> This is how I keep all the mapping files, SqlMapConfig.xml(each per
> application) and 1 common SqlMapConfig.properties which has the database
> connection parameters for all the applications.
>
> src
> |
> |
> |___ XML.app1.ibatis.maps
> | |
> | |___ all mapping files, SqlMapConfig.xml
> |
> |
> |___ XML.app2.ibatis.maps
> | |
> | |___ all mapping files, SqlMapConfig.xml
> |
> |
> |___ SqlMapConfig.properties
>
>
> With this approach, all these files become part of the WAR. And I think this
> is not a workable solution if I have to deploy the project onto QA and
> further environments.
>
> Just wondering, how do you guys maintain these config files? Do you keep it
> in current working directory so that they are not part of WAR and each
> environment can configure database connection parameters seperately? Also,
> if I keep SqlMapConfig.properties inside current working directory, how do I
> access it inside SqlMapConfig.xml?
>
> Help please!
>
> Regards
> Nilesh
>
Re: Common practice to maintain sql maps and properties file
Posted by Brandon Goodin <br...@gmail.com>.
If you are using cvs you can place an ignore on
sqlmapconfig.properties to avoid it from being checked in and hence
distributred into any other environment when perfroming a build (via
ant). What we do is to keep a sample-sqlmapconfig.properties around.
Then whether you are in a development, test or production environment
you can rename and configure it to work in that environment. If you
are looking to keep around some preconfigured sql map configs for
different environments you can place them in a folder outside the src
directory and use ant to copy it in on a build depending on an
environment flag that is set manually.
Brandon
On Mon, 6 Dec 2004 09:50:59 -0500, Nilesh Bhattad <ni...@outlinesys.com> wrote:
>
> Folks,
> This is how I keep all the mapping files, SqlMapConfig.xml(each per
> application) and 1 common SqlMapConfig.properties which has the database
> connection parameters for all the applications.
>
> src
> |
> |
> |___ XML.app1.ibatis.maps
> | |
> | |___ all mapping files, SqlMapConfig.xml
> |
> |
> |___ XML.app2.ibatis.maps
> | |
> | |___ all mapping files, SqlMapConfig.xml
> |
> |
> |___ SqlMapConfig.properties
>
>
> With this approach, all these files become part of the WAR. And I think this
> is not a workable solution if I have to deploy the project onto QA and
> further environments.
>
> Just wondering, how do you guys maintain these config files? Do you keep it
> in current working directory so that they are not part of WAR and each
> environment can configure database connection parameters seperately? Also,
> if I keep SqlMapConfig.properties inside current working directory, how do I
> access it inside SqlMapConfig.xml?
>
> Help please!
>
> Regards
> Nilesh
>