I think I found the source of my problem...Here's the solution for those
that care:
 
I had deployed all three jars with a "database.properties" file
referenced by the dao.xml.  This file lived in the top-level of each
jar, so there was no distinction between Order vs. Catalog vs. Customer
when the class loader was invoked to pull the resource at runtime.
 
Putting them in package-qualified directories (or renaming the files)
fixed the problem.
 
-D

________________________________

From: Dave Rodenbaugh 
Sent: Thursday, January 25, 2007 11:18 AM
To: user-java@ibatis.apache.org
Subject: Deployment question


Hi everyone,
 
I have iBATIS in an application we've deployed into Weblogic.  Things
run nicely as unit tests, so I know I have the basic plumbing working...
 
Here's where things get a little tricky--I have three separate CVS
modules that are built as different jars.  Each has its own properties
file that is referenced from the configuration XML for iBATIS.  I'm
trying this with the dataSource type='SIMPLE' setup, and all the
properties are defined properly for each jar.
 
Let's say the three modules are Catalog.jar, Customer.jar, and
Order.jar.  Order depends on Customer, Order also depends on Catalog.
Each of the three has a different database user defined for connection
(that's a DBA thing here...not my call, nor is it changeable).  So
there's an CAT_USER, CUST_USER, and ORD_USER.
 
The problem is that when I run my unit tests on Order, I'm seeing errors
trying to reference things in Customer--the error indicates a view
doesn't exist (it's a customer view).  However, if I run the same query
as the right user, I definitely get positive results from my DB.  I
*suspect* things are implicitly using the Order database properties so
I'm running the Customer query as ORD_USER which is bad.  Seems like for
stuff referenced in another JAR, iBATIS should use the properties local
to that JAR...
 
My questions are thus:
 
1)  Is there a way to output what user a query is using?  (or
connection)
2)  Can you confirm or deny that the above scenario is the right way to
structure this?
 
Thanks,
-Dave

Reply via email to