Hi,

I had a very similar problem using hibernate and a jndi datasource, the way I got around this for
unit testing was to create the jndi datasource within my unittest setup method, it's a little messy
but works for me (tihs class also loads the spring configuration files too):

import java.util.Properties;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;

import junit.framework.TestCase;

import org.apache.commons.dbcp.BasicDataSourceFactory;
import org.apache.log4j.Logger;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.msoft.lite.exception.DAOException;


public class JndiConfigurationTestCase extends TestCase {

 protected Logger        log  = Logger.getLogger( this.getClass() );


 protected ApplicationContext  application;




 /*
  * (non-Javadoc)
  *
  * @see junit.framework.TestCase#setUp()
  */
 @Override
 protected void setUp() throws Exception {
   super.setUp();
   try {
     // Create initial context
     System.setProperty( Context.INITIAL_CONTEXT_FACTORY,
"org.apache.commons.naming.java.javaURLContextFactory" );
     // System.setProperty( Context.URL_PKG_PREFIXES, "org.apache.commons.naming" );
     InitialContext initialContext = new InitialContext();


     Context javaCompContext = getOrCreateSubcontext( "java:comp", initialContext );
     Context envContext = getOrCreateSubcontext( "env", javaCompContext );
     Context jdbcContext = getOrCreateSubcontext( "jdbc", envContext );

     try {
       jdbcContext.lookup( "mshoplite" );
     } catch ( Exception exp ) {
       log.info( "Datasource does not exist, creating..." );


       Properties properties = new Properties();
       properties.put( "driverClassName", "com.mysql.jdbc.Driver" );
       properties.put( "url", "jdbc:mysql://localhost:3306/DB" );
       properties.put( "username", "username" );
       properties.put( "password", "********" );

       DataSource dataSource = BasicDataSourceFactory.createDataSource( properties );

       initialContext.bind( "java:comp/env/jdbc/db", dataSource );
     }

     application = new ClassPathXmlApplicationContext( "/META-INF/sharedApplicationContext.xml" );
   } catch ( Exception exp ) {
     log.error( "Unable to setup test case", exp );
     throw exp;
   }
 }




 protected Context getOrCreateSubcontext( String contextName, Context context ) throws NamingException {
   try {
     return (Context) context.lookup( contextName );
   } catch ( Exception exp ) {
     return context.createSubcontext( contextName );
   }
 }




 public void testJndiConfiguration() throws Exception {
   try {
     Context ctx = new InitialContext();
     if ( ctx == null ) {
       throw new DAOException( "Unable to obtain initial context" );
     }

     DataSource ds = (DataSource) ctx.lookup( "java:comp/env/jdbc/db" );
     assertNotNull( ds );
     assertNotNull( ds.getConnection() );
   } catch ( Exception exp ) {
     log.error( "Unable to load datasource connection", exp );
     throw exp;
   }
 }
}


Wesley Wannemacher wrote:
> Hello, I have a Lazy Friday question for everyone...
>
> When configuring the database connections, where do you tend to put
> them?
>
> In my situation, I usually configure the connection pool in the web-app
> context and find them with JNDI. However, I am moving to iBATIS for my
> most recent project and iBATIS has the ability to create a DBCP pool on
> it's own (rather than in the web-app context).
>
> In the past, I could use a read-only connection in the context both for
> my own coding and I could have Tomcat create a JNDI realm for
> authentication. So, I would have to have a database connection
> configured by Tomcat. In my current project, I am not going to use
> Tomcat's Container managed security, so I don't need the database
> connections available to Tomcat, so I am leaning toward using the
> built-in iBATIS capability.
>
> I am asking because I don't want to have to change later when I find
> something else that I am currently forgetting about.
>
> The main reason that I am currently leaning toward the iBATIS solution
> is that I am finding jUnit tests difficult to write for my persistence
> layer. If I tell iBATIS to find the database connections in the Tomcat
> context, iBATIS can't find them when I am running unit tests (since the
> unit tests don't load the tomcat context).
>
> Opinions?
>
> -Wes
>
> --
> Wes Wannemacher
> Director of Operations
> Double A Trailer Sales, Inc.
> wesw@(protected)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
>

--
Gareth Evans

Senior Developer

MSoft eSolutions Limited
Technology Centre
Inward Way
Rossmore Business Park
Ellesmere Port
Cheshire
CH65 3EN

--
Tel:   +44 (0)870 0100 704
Fax:   +44 (0)870 9010 705
E-Mail: gareth@(protected)
Web:   www.msoft.co.uk

----------------------------------------------
Terms:
Please note that any prices quoted within this e-mail are subject to VAT.
All program details and code described in this e-mail are subject to
copyright ? of MSoft eSolutions Limited and remain the intellectual
property of MSoft eSolutions Limited.
Any proposal or pricing information contained within this e-mail are
subject to MSoft eSolutions' Terms and Conditions
----------------------------------------------
Disclaimer:
This message is intended only for use of the addressee. If this message
was sent to you in error, please notify the sender and delete this
message. MSoft eSolutions Limited cannot accept responsibility for viruses,
so please scan attachments. Views expressed in this message do not
necessarily reflect those of MSoft eSolutions Limited who will not
necessarily be bound by its contents.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)