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 Karen Koch <km...@sbcglobal.net> on 2005/03/31 20:29:40 UTC

iBATIS DAO question

Up until now, I have been keeping my dao.xml file in the classpath of my web
application, which, as the doc says, is nice for location transparency reasons.
 However, once the app is deployed, if I want to add a data source or three
(common with our "hosted" app which serves multiple clients, each with their
own database), I need to edit that file to add a new context, which requires a
rebuild and redeployment.  It would be nice if I could edit the file without
redeploying the app, as I can with context.xml to actually add the JNDI
resource.

Is my best bet to use the FileReader() constructor with a hard-coded path? 
(Bad for a different reason, obviously, but it solves the above problem...) 
Any other ideas for achieving this kind of maintainability after deployment?

Thanks in advance!
Karen Koch
IDC, Chicago, IL

Re: iBATIS DAO question

Posted by Clinton Begin <cl...@gmail.com>.
Sure, why not.  If that's what you need to do, go for it.  I don't see
any harm other than the loss of transparency (which in this case is a
requirement, not a flaw).

Cheers,
Clinton

On Mar 31, 2005 10:29 AM, Karen Koch <km...@sbcglobal.net> wrote:
> Up until now, I have been keeping my dao.xml file in the classpath of my web
> application, which, as the doc says, is nice for location transparency reasons.
>  However, once the app is deployed, if I want to add a data source or three
> (common with our "hosted" app which serves multiple clients, each with their
> own database), I need to edit that file to add a new context, which requires a
> rebuild and redeployment.  It would be nice if I could edit the file without
> redeploying the app, as I can with context.xml to actually add the JNDI
> resource.
> 
> Is my best bet to use the FileReader() constructor with a hard-coded path?
> (Bad for a different reason, obviously, but it solves the above problem...)
> Any other ideas for achieving this kind of maintainability after deployment?
> 
> Thanks in advance!
> Karen Koch
> IDC, Chicago, IL
>