Okay. A few things here.
First and formost, I recommend that you don't use a DAO framework. Use the DAO pattern, but you don't need a framework. Since you're using session beans, you are likely using transactions demarcated by your EJB container. The biggest advantage of the iBATIS DAO framework is how it simplifies transaction management. So because you're using both EJB and DAO, the DAO framework is really doing nothing for you. Sure it keeps a nice interface/implementation separation, but I'd argue that that's possibly unecessary but at the very least it's easily acheived without a framework.
So to summarize my first recommendation: Ditch the iBATIS DAO framework. It's likely not needed in your situation. If you decide to keep running with it...keep reading.
>> but for ibatis this would mean a different daomanager for each service which would make it very error prone,
>> although it uses a 'pre-agreed' jndi datasource.
I disagree somewhat. It won't be any more error prone than any other part of your code. In my opinion you should have a separate DAO manager for each module, otherwise you're only partially separating the concerns of your EJB modules -- which may be missing the point. If you want to keep central configuration to avoid inconsistencies in things like the JNDI datasource name, then you can do so by using a shared property file. Something as simple as using a common source repository for configuration would resolve this.
The iBATIS DAO framework is a logical abstraction layer used to hopefully improve the quality of your code. It's not huge infrastructure that you need to worry about running in multiple places.
Second recommendation: Let each EJB module use its own DaoManager, but use a shared configuration (properties) file.
>> But practically, this would mean multiple daomanager for single datebase app and jndi name could very well change right?
And if it changes....change the one shared property file and everything will work fine.
I think you're doing all the right things. Don't over-think it. Use a simple solution.
>> RE: Deprecation...
As larry said, the DAO framework has been deprecated. This means that while the DAO framework will still be available, we're not doing any more work on it, and we're recommending a different solution (Spring DAO) from now on.
However, if you do like the framework and intend to keep on using it, you should feel comfortable doing so. The source is available and it's really not that much code. So you could easily integrate the iBATIS DAO source into your application and make whatever changes you need to implement your multiple EJB needs.
NOTE: Please don't confuse iBATIS DAO and iBATIS SQL Maps. Only the DAO framework is being deprecated. The iBATIS SQL Mapper (i.e. DataMapper) is still being actively developed and supported.
Hope that helps.
Clinton
On 11/5/06, Mr Li <[EMAIL PROTECTED]> wrote:
Hi,
I'm currently assigned to a large project that requires individual ejb modularity.
In this case, its a standard app->service(sessionEJB)->db(ibatis) design.
The problem with this, is that different people will work on different service ejbs and the boss wanted seperate DaoManager( dao.xmls) for each service.
Well, this design should work perfectly for CMP as the datasource is assigned by the container during deployment, but for ibatis this would mean a different daomanager for each service which would make it very error prone, although it uses a 'pre-agreed' jndi datasource.
But practically, this would mean multiple daomanager for single datebase app and jndi name could very well change right? The potential datasource misconfigure disaster is what I'm afraid... :)
Forcing a single daomanager singleton design would break this 'ejb modularity concept' and would create bloated dao.xml and sqlmapconfig.xml files my boss says...
Anyway, is there any global-dao.xml where one could be use to assemble multiple dao.xml as one?
Any advice?
regards,
stanley
