The iBatis framework has been significantly tweaked between versions 2 & 3, so much that even the config file (now often referred to as MapperConfig.xml) is different.
That being said, there are lots of examples online on how to create a JDBC connection pool with iBatis, but I couldn't find one example on how to do it with JNDI. There is an updated user guide at: http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/doc/en/iBATIS-3-User-Guide.pdf which does refer to the JNDI settings on page 19, but I still couldn't it get it correctly communicate with the database.
A working example of a JDNI (container managed connection pool) in iBatis 3 would be greatly appreciated!!
Assuming you've already got a JNDI database resource set up, the following environment for iBatis 3's configuration XML file works for me (running on Tomcat):
<environment id="development">
<transactionManager type="JDBC"/>
<dataSource type="JNDI">
<property name="data_source" value="java:comp/env/jdbc/webDb"/>
</dataSource>
</environment>
This is what I have in my config file, works well in Glassfish and WebSphere:
<dataSource type="JNDI">
<property name ="data_source" value="jdbc/cpswebmon"/>
</dataSource>
"jdbc/cpswebmon" is the JNDI resource name on my application server
Related
I try to deploy a Java EE Application containing several EJB Timer Services (with persistence=true).
The server complains that no datasource was defined:
Caused by: javax.ejb.EJBException: See nested exception; nested exception is: java.lang.IllegalStateException: The ejbPersistentTimer feature is enabled, but the defaultEJBPersistentTimerExecutor persistent executor cannot be resolved. The most likely cause is that the DefaultDataSource datasource has not been configured. Persistent EJB timers require a datasource configuration for persistence.
The ejbPersistentTimer-3.2 feature is turned on.
I can not find an example how to configure such a datasource in the server.xml file
I tried:
<dataSource id="timerDataSource" jndiName="jdbc/timerDataSource">
</dataSource>
<databaseStore id="EJBTimerDatabaseStore"
tablePrefix="EJBTimer_" dataSourceRef="timerDataSource" />
<persistentExecutor
id="defaultEJBPersistentTimerExecutor"
taskStoreRef="EJBTimerDatabaseStore" />
But this seems to be not enoght? Did I need to activate DerbyDB as a feature too?
It looks like your <dataSource> configuration is missing a few items:
A <jdbcDriver> which points to the JDBC driver jar that corresponds with the DB you are using
A <properties> element which identifies DB properties such as the DB server's hostname, port, and DB name.
Since you mentioned using DerbyDB, here is an example of what Derby config might look like:
<dataSource id="timerDataSource" jndiName="jdbc/timerDataSource">
<jdbcDriver libraryRef="DerbyLib"/>
<properties.derby.embedded databaseName="${server.config.dir}/data/EJBTimerDB" createDatabase="create"/>
</dataSource>
<library id="DerbyLib">
<fileset dir="${server.config.dir}/derbyDriverDir/"/>
</library>
For additional info on configuring DataSources in Liberty, check out this doc:
Configuring relational database connectivity in Liberty
I'm new to JPA and Liberty. Could anyone please explain how to relate/link the server.xml, web.xml and persistence.xml configuration to set up the database connection?
your help on this is much appreciated.
In Liberty, you define the location of the JDBC driver jar files and configure a dataSource element with a JNDI name. This knowledge center page contains an example for MySQL,
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_dep_configuring_ds.html
Directly quoting from the above page,
<dataSource id="DefaultDataSource" jndiName="jdbc/mySQL">
<jdbcDriver libraryRef="MySQLLib"/>
<properties databaseName="SAMPLEDB" serverName="localhost" portNumber="3306"/>
</dataSource>
<library id="MySQLLib">
<file name="C:/mysql-connector-java-x.x.xx/mysql-connector-java-x.x.xx.jar"/>
</library>
After this, you can configure the jta-data-source element in your persistence.xml pointing at the JNDI name that you chose. For example,
...
<persistence-unit name="ExamplePersistenceUnit">
<jta-data-source>jdbc/mySQL</jta-data-source>
</persistence-unit>
The above is sufficient to get it working, without involving web.xml.
The deployment descriptor (web.xml) gives you the option of adding a level of indirection/mapping and the ability to configure some additional settings such as shareability and container vs application authentication. You can do this by defining a resource reference in web.xml pointing to the data source. Resource references have names in java:comp/env, java:module/env, java:app/env or java:global/env that reflect their visibility. I'll use java:module in the following example, meaning that the reference we are defining is only visibility within the same module (the web module that provides the web.xml),
<resource-ref>
<res-ref-name>java:module/env/jdbc/mySQLRef</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
<lookup-name>jdbc/mySQL</lookup-name>
</resource-ref>
After defining the resource reference above, the data source continues to be available at the JNDI name specified in server.xml, but also becomes available via the JNDI name of the resource reference, meaning you could alternately specify,
<jta-data-source>java:module/env/jdbc/mySQLRef</jta-data-source>
Deployment descriptors can also do some more advanced things like defining a data source in place of the server config. However, to keep this answer simple, I've skipped over that possibility.
This IBM KnowledgeCenter topic is a good place to start
we are using oracle database, this is how we configured JNDI against oracle on liberty profile, I want to use hikarui-cp instead if javax.sql.ConnectionPoolDataSource.
<library id="oracleJDBCJars" name="oracleJDBCJars">
<fileset dir="${shared.resource.dir}/oracle-jars" includes="*.jar"/>
</library>
<dataSource beginTranForResultSetScrollingAPIs="true"
beginTranForVendorAPIs="false"
commitOrRollbackOnCleanup="rollback"
connectionManagerRef="default-conn-mgr"
isolationLevel="TRANSACTION_READ_COMMITTED"
jndiName="jdbc/dev"
transactional="true"
type="javax.sql.ConnectionPoolDataSource">
<jdbcDriver libraryRef="oracleJDBCJars"/>
<properties.oracle currentSchema="DEV"
databaseName="DBU"
password="Admin12"
portNumber="3714"
serverName="host.local.com"
user="ADMIN"/>
</dataSource>
Opinion part:
First off, I will say that it's probably not necessary to use HikariCP with a Java EE app server. From what I've read, HikariCP is a great connection pool and makes sense to use if you are in a Java SE environment. You might gain a small benefit from using HikariCP in an EE environment, but you will need to jump through additional hoops to get it working when you could just use the Liberty connection pool. In my opinion, your development time will be better spent elsewhere, because Liberty already has a well tested, well performing connection pool out of the box. Using an alternate connection pool on an app server that already provides a good one seems like an unnecessary micro-optimization.
Disclaimer: I am a Liberty developer who works on the connection pool among other things.
To answer your question:
Your configuration is for a DB2 database, not an Oracle database (i.e. properties.oracle should be used instead of properties.db2.jcc). Also, it has many additional properties specified that aren't necessary.
Your configuration can be simplified to this:
<library id="oracleJDBCJars" name="oracleJDBCJars">
<fileset dir="${shared.resource.dir}/oracle-jars" includes="*.jar"/>
</library>
<dataSource jndiName="jdbc/dev">
<jdbcDriver libraryRef="DB2JCC4Jars"/>
<properties.oracle URL="jdbc:oracle:thin:#//host.local.com:3714/DBU"
password="Admin12"
user="ADMIN"/>
</dataSource>
For more info on configuring a data source in Liberty, see this document:
Configuring relational database connectivity in Liberty
Validate your config:
If you have the April beta or newer, you can use the test connection service to check if your data source config works or not. See this article for a walkthrough on how to do that:
Testing database connections in Liberty apps with REST APIs
If you don't have the the April beta or newer, you can write a simple test servlet to attempt to get a connection.
Attempting to use HikariCP:
You will want to modify your jdbc driver <library> to also include the HikariCP jars.
Next, modify your <dataSource> to point to the HikariDataSource implementation. You will need to set 2 attributes (noted below):
<!-- Tell the <dataSource> to use `javax.sql.DataSource` (as opposed to auto-detecting ConnectionPoolDataSource or XADataSource) -->
<dataSource jndiName="jdbc/dev" type="javax.sql.DataSource">
<!-- Tell the <jdbcDriver> what implementation class to use for `javax.sql.DataSource` -->
<jdbcDriver libraryRef="DB2JCC4Jars" javax.sql.DataSource="com.zaxxer.hikari.HikariDataSource"/>
<properties.oracle URL="jdbc:oracle:thin:#//host.local.com:3714/DBU"
password="Admin12"
user="ADMIN"/>
</dataSource>
I have followed the infocenter docs to setup Worklight on Liberty and Oracle Database all on Windows 2008.
(http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/topic/com.ibm.worklight.help.doc/devref/t_transporting_apps_and_adapters.html - Deploying IBM Worklight applications to test and production environments)
When I start the liberty server, I get this error on the browser
Exception thrown by application class 'com.worklight.core.auth.impl.AuthenticationFilter.doFilter:110'
javax.servlet.ServletException: Worklight Project not initialized
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:110)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
Going thru the logs, it shows it did not start because the HSQLDB driver is not found.
The server.xml has the following:
<application id="finance" name="finance" location="finance.war" type="war">
<classloader delegation="parentLast">
<commonLibrary>
<fileset dir="${shared.resource.dir}/worklight/lib" includes="worklight-jee-library.jar"/>
</commonLibrary>
</classloader>
</application>
<library id="worklight/OracleLib">
<fileset dir="${shared.resource.dir}/worklight/oracle" includes="*.jar"/>
</library>
<!-- Declare the IBM Worklight Console database. -->
<dataSource jndiName="worklight/jdbc/WorklightDS" transactional="false">
<jdbcDriver libraryRef="worklight/OracleLib"/>
<properties.oracle driverType="thin" URL="jdbc:oracle:thin:#localhost:1521:ORCLWL" user="WORKLIGHTDIS" password="WORKLIGHTDIS"/>
</dataSource>
I took a step further and checked how the WAR file links to database jndi entries. Going thru the web.xml file I found this:
<resource-ref>
<description>Worklight Server Database</description>
<res-ref-name>jdbc/WorklightDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
The res-ref-name is slightly different from what is declared in the server.xml. Bear in mind that these entries were created by the ant script. This seems to be inconsistent from what the war file contains (created by the WL Studio).
Anyway I gave it a try and changed the server.xml jndi entry to be exactly the same as the web.xml entry (jdbc/WorklightDS). When I restarted the liberty server It did not change the final result at all. The error message and the HSQL driver thing kept showing in the log.
This is the exception
nested exception is java.lang.RuntimeException: java.lang.ClassNotFoundException: Class org.hsqldb.jdbcDriver not found in Worklight platform or project /finance
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:275)
Later on I found out that if I change the element in the server.xml to be worklight value for all atributes it works. How odd it is.
<application id="worklight" name="worklight" location="finance.war" type="war">
Please, any help is much appreciated to help me understand and fix it.
The error message "java.lang.RuntimeException: java.lang.ClassNotFoundException: Class org.hsqldb.jdbcDriver not found in Worklight platform or project ..." is indeed misleading. It should better read something like "Worklight server cannot be started because no data-source is bound to resource reference: 'jdbc/WorklightDS'. Re-configuring the server will solve this problem. for more information search for "Creating and configuring the databases" in IBM Worklight information center."
The explanation for the error message is that by writing <application id="finance" name="finance" location="finance.war" type="war"> you selected a context root /finance, according to the WebSphere Liberty rules at Deploying a web application to the Liberty profile. For this context root, you need to write
<dataSource jndiName="finance/jdbc/WorklightDS" transactional="false">
This is similar to how JNDI environment entries need to be declared for Worklight (see here).
Seems like a simple task. I have a webapp which requires a database connection. I'd like to be able to drop an updated .war file on this app server and load a new version without having to re-edit an applicationConfig.xml file to specify the database connection parameters for production.
Is using the container to setup the data source and then referencing it from JNDI the preferred way to go? I think it is cleaner having it all defined in the spring .xml file, but I can't come up with a clean way to allow the production password to be set only once as we roll out new versions.
So, how do you specify your database connection information in a spring application so that you can upgrade it without having to re-edit the files?
If you use JNDI, how do you handle setting up of your tests since the JNDI is not going to be available outside of the container?
Thanks!
The typical way to externalize database connection properties is to store them in a .properties file and load using <context:property-placeholder .../> . Then you can have different .properties files for testing and production.
If you choose JNDI, you can use a Spring's mock JNDI support for testing.
One approach is for your Spring configuration file to be composed of fragments related to specific layers in your application.
One such fragment could contain your DataSource defintion. For production, this fragment would use a jee:jndi-lookup. And then for test, have a different fragment would use a DriverManagerDataSource ?
Update:
If you want to change the datasource after deployment, then you can use this technique, along with changing the which datasource is injected into your other beans using a PropertyPlaceholderConfigurer as explained in an old post I wrote
eg:
<bean class="foo.bar.SomeClassNeedingDataSource"">
<property name="dataSource" ref="${the.datasource.to.inject}" />
</bean>
<jee:jndi-lookup id="jndiDataSource" ... />
<bean id="driverManagerDataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
...
</bean>
# the properties file
the.datasource.to.inject = jndiDataSource
#the.datasource.to.inject = driverManagerDataSource