-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 10 posts ] 
Author Message
 Post subject: Need help: Datasource is requiring username/password in conf
PostPosted: Thu Dec 08, 2005 5:09 pm 
Newbie

Joined: Thu Dec 08, 2005 3:54 pm
Posts: 11
I'm trying to connect to my database via a datasource. Currently, it's only working if I provide a user ID and password in the Hibernate config file - but I don't want to do that. Part of the point of using a datasource is to avoid putting user IDs and passwords into config files.... SO, I'm sure I have something configured incorrectly. I just don't know what...

We're running an EAR with four or five basic Java jar files and one WAR file contained in the EAR. (We're in WebSphere - version details below.) The Hibernate jar files are all up in the EAR, and our Persistence project (the jar file with our Java code implementing our Hiberate DAOs) accesses the Hibernate jar files via references from the MANIFEST.MF in our jar file. I think the code is working. We are able to save objects to and read objects from the database.

Hibernate version: 3.0.5

Database: DB2 version 8.2.2 (for NT)

Application Server: WebSphere 5.1 (testing in Rational Application Developer (RAD) version 6.0.1, using the built-in WebSphere v5.1 Test Environment)

DataSource configuration:
In RAD, in the Admin Console for our WebSphere v5.1 Test Environment, under Resources, under JDBC Providers, at the Server scope, we're using a DB2 Universal JDBC Driver Provider. We've mapped the driver to its needed jar files (db2jcc.jar and db2jcc_license_cu.jar). The JDBC Driver Implementation Classname is its default value of com.ibm.db2.jcc.DB2ConnectionPoolDataSource. We've defined one data source with a JNDI name of jdbc/EASDataSource. The data source is not configured for use with Container managed persistence. The Datasource Helper Classname has its default value of [coide]com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper[/i].

Here's what may be the important stuff: The Component-managed Authentication Alias is left at its default value of (none). The Container-managed Authentication Alias is devEAS_auth_alias, which is a J2C Authentication Data Entry that defines the name/password I want to be use with the datasource. I believe this is all correct because the "Test Connection" button on the Data Source page works fine.

In the Data Source Custom Properties, we define the database name, we defined the driverType as 4 so we are using DB2's Type 4 Universal Driver, and we define values for serverName and portNumber to define the database connection.

In the code, we're not using any EJBs. Our Hibernate DAOs exist in their own "Persistence" Java jar. So our Hibernate code is not inside any EJB and it's not inside a Servlet - so we're not using the java:comp/env approach to name the datasource. Instead, the JNDI name of our datasource is simply jdbc/EASDataSource.

Here's the hibernate.cfg.xml file without the references to our mappings:

Code:
<hibernate-configuration>
   <session-factory name="java:comp/env/hibernate/SessionFactory">       
      <property name="default_schema">EADEV</property>      
      <property name="connection.datasource">jdbc/EASDataSource</property>
       <property name="connection.username">xxx</property>
      <property name="connection.password">xxxxxxx</property>

      <property name="dialect">org.hibernate.dialect.DB2Dialect</property>

      <property name="transaction.factory_class">
           org.hibernate.transaction.JTATransactionFactory
      </property>
      <property name="transaction.manager_lookup_class">
           org.hibernate.transaction.WebSphereTransactionManagerLookup
      </property>
        <property name="jta.UserTransaction">java:comp/UserTransaction</property>
   </session-factory>

</hibernate-configuration>


If I leave out the connection username and password, I get this error (see the first error message and then the last line of the stack trace that says "Caused by"):

Code:
[12/8/05 13:38:58:656 CST] 72b7c66b NamingHelper  I org.hibernate.util.NamingHelper  JNDI InitialContext properties:{}
[12/8/05 13:38:58:922 CST] 72b7c66b DatasourceCon I org.hibernate.connection.DatasourceConnectionProvider  Using datasource: jdbc/EASDataSource
[12/8/05 13:38:59:656 CST] 72b7c66b FreePool      E J2CA0046E: Method createManagedConnctionWithMCWrapper caught an exception during creation of the ManagedConnection for resource jdbc/EASDataSource, throwing ResourceAllocationException.  Original exception: com.ibm.ws.exception.WsException: DSRA8100E: Unable to get a PooledConnection from the DataSource.
   at com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:244)
   at com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:171)
   at com.ibm.ws.rsadapter.AdapterUtil.createDataStoreAdapterException(AdapterUtil.java:209)
   at com.ibm.ws.rsadapter.DSConfigurationHelper.getPooledConnection(DSConfigurationHelper.java:911)
   at com.ibm.ws.rsadapter.spi.WSRdbDataSource.getPooledConnection(WSRdbDataSource.java:675)
   at com.ibm.ws.rsadapter.spi.WSManagedConnectionFactoryImpl.createManagedConnection(WSManagedConnectionFactoryImpl.java:731)
   at com.ibm.ejs.j2c.poolmanager.FreePool.createManagedConnectionWithMCWrapper(FreePool.java:1330)
   at com.ibm.ejs.j2c.poolmanager.FreePool.createOrWaitForConnection(FreePool.java:1131)
   at com.ibm.ejs.j2c.poolmanager.PoolManager.reserve(PoolManager.java:1685)
   at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java:685)
   at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java:462)
   at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:241)
   at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:214)
   at org.hibernate.connection.DatasourceConnectionProvider.getConnection(DatasourceConnectionProvider.java:59)
   at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:72)
   at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:1463)
   at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1004)
   at org.srskansas.eas.persistence.hibernate.HibernateUtil.<clinit>(HibernateUtil.java:24)
   at org.srskansas.eas.persistence.hibernate.HibernateCodeTableDAO.save(HibernateCodeTableDAO.java:33)
   at org.srskansas.eas.persistence.data.CodeValueFileLoader.main(CodeValueFileLoader.java:89)
   at org.srskansas.eas.persistence.data.CoreDataFileLoader.main(CoreDataFileLoader.java:13)
   at org.srskansas.eas.common.actions.EASInitializerAction.init(EASInitializerAction.java:31)
   at javax.servlet.GenericServlet.init(GenericServlet.java:258)
   at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doInit(StrictServletInstance.java:82)
   at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._init(StrictLifecycleServlet.java:147)
   at com.ibm.ws.webcontainer.servlet.PreInitializedServletState.init(StrictLifecycleServlet.java:270)
   at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.init(StrictLifecycleServlet.java:113)
   at com.ibm.ws.webcontainer.servlet.ServletInstance.init(ServletInstance.java:189)
   at javax.servlet.GenericServlet.init(GenericServlet.java:258)
   at com.ibm.ws.webcontainer.webapp.WebAppServletManager.addServlet(WebAppServletManager.java:876)
   at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadServlet(WebAppServletManager.java:224)
   at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadAutoLoadServlets(WebAppServletManager.java:542)
   at com.ibm.ws.webcontainer.webapp.WebApp.loadServletManager(WebApp.java:1279)
   at com.ibm.ws.webcontainer.webapp.WebApp.init(WebApp.java:283)
   at com.ibm.ws.webcontainer.srt.WebGroup.loadWebApp(WebGroup.java:392)
   at com.ibm.ws.webcontainer.srt.WebGroup.init(WebGroup.java:211)
   at com.ibm.ws.webcontainer.WebContainer.addWebApplication(WebContainer.java:1005)
   at com.ibm.ws.runtime.component.WebContainerImpl.install(WebContainerImpl.java:136)
   at com.ibm.ws.runtime.component.WebContainerImpl.start(WebContainerImpl.java:356)
   at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:505)
   at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:808)
   at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:354)
   at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:578)
   at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:299)
   at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:576)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
   at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
   at com.tivoli.jmx.modelmbean.MMBInvoker.invoke(MMBInvoker.java:46)
   at com.tivoli.jmx.modelmbean.MMBInvoker.invokeOperation(MMBInvoker.java:115)
   at com.tivoli.jmx.modelmbean.DynamicModelMBeanSupport.invoke(DynamicModelMBeanSupport.java:409)
   at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:323)
   at com.tivoli.jmx.GenericMBeanSupport.invoke(GenericMBeanSupport.java:178)
   at com.tivoli.jmx.MBeanAccess.invoke(MBeanAccess.java:113)
   at com.tivoli.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:290)
   at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:659)
   at com.ibm.ws.management.connector.AdminServiceDelegator.invoke(AdminServiceDelegator.java:130)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
   at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
   at com.ibm.ws.management.connector.soap.SOAPConnector.invoke(SOAPConnector.java:306)
   at com.ibm.ws.management.connector.soap.SOAPConnector.service(SOAPConnector.java:176)
   at com.ibm.ws.management.connector.soap.SOAPConnection.handleRequest(SOAPConnection.java:55)
   at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:615)
   at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:439)
   at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)
Caused by: com.ibm.db2.jcc.b.SqlException: null userid not supported




If I try an "empty" connection username, I get a different "Caused by" error:

Code:
Caused by: com.ibm.db2.jcc.b.SqlException: userid length, 0, is not allowed.


If I provide connection.username and connection.password in hibernate.cfg.xml, then it all works.

What/how many changes do I need to make to still use my WebSphere managed DataSource to DB2, using the Type 4 driver, without putting a userid and password in the hibernate config file? I want the datasource to always use the name/password defined by WebSphere. I don't want Hibernate to try and provide names/passwords to the datasource. Since the "test connection" button on the datasource page works within the WebSphere Admin Console, I'm confident WebSphere knows the correct name/password to use for this particular datasource. I just haven't been able to figure out why WebSphere is not using that name/password when Hibernate asks for the datasource.

Thanks,
Bill


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 6:43 pm 
Expert
Expert

Joined: Mon Jul 04, 2005 5:19 pm
Posts: 720
I don't have time to read all that but you might want to look at the Configuration API. It allows you to set properties (the same ones you set in hibernate.cfg.xml) programmatically. This means your app can pull the username from any source (command line, JAAS, etc.)


Top
 Profile  
 
 Post subject: Configuration API not the answer
PostPosted: Thu Dec 08, 2005 6:53 pm 
Newbie

Joined: Thu Dec 08, 2005 3:54 pm
Posts: 11
So much for trying to "provide all information..." You do, and they say it's too long to read.

;-)

When a datasource is defined on an application server - the username and password are parameters saved on the application server. They are not supposed to be used by or known by the users of the datasource.

The java application never sees the name and password for the datasource (and the java application has no business asking the server for the name and password). SO - using the Configuration API would be of no help. I'm not supposed to have a name/password to pass in to the configuration.

The goal is - use the datasource just by referring to it by name. Outside of Hibernate the datasource seems to be working fine - which is why I suspect it's a Hibernate/Datasource interface problem. Maybe specific to the IBM DB2 Type 4 driver being used as the datasource connector? Maybe not.

Any other ideas?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 11:21 pm 
Expert
Expert

Joined: Mon Jul 04, 2005 5:19 pm
Posts: 720
Maybe you could try JNDI datasource?

Code:
<property name="connection.datasource">java:comp/env/jdbc/foo</property>


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 11:25 pm 
Expert
Expert

Joined: Mon Jul 04, 2005 5:19 pm
Posts: 720
OK, I read it. I don't know. But we have several apps here that do now require login credentials in hibernate.cfg.xml using JNDI in both JBOSS and plaing tomcat. Sorry.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 08, 2005 11:26 pm 
Expert
Expert

Joined: Mon Jul 04, 2005 5:19 pm
Posts: 720
errata : change "now" to "not".


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 09, 2005 12:25 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 3:00 pm
Posts: 1816
Location: Austin, TX
Sounds like the datasource is secure. That would then require username/password to access the datasource itself. Is this the case?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 09, 2005 11:45 am 
Newbie

Joined: Thu Dec 08, 2005 3:54 pm
Posts: 11
That's a very good question. I'll find out.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 09, 2005 5:42 pm 
Newbie

Joined: Mon Jul 18, 2005 10:15 am
Posts: 17
a) Typically a production-level database will definitely need a user id / password to get a connection.
b) Sounds you are in the correct direction -- you are NOT supposed to put password in any config file, especially in the plain text mode - one of enterprise app best practice I'm advocating.
c) As suggested by other folks, for Hibernate , use
Code:
<property name="connection.datasource">java:comp/env/jdbc/foo</property>
-- without specifying user id/password -- will work. But you have to do the mapping - map this resource reference to the global JNDI name jdbc/foo.
d) I'm using this style of config in production. Please feel free to post your question in this regard if there's any (more).

HTH,
JB


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 10, 2005 10:33 am 
Beginner
Beginner

Joined: Thu Dec 01, 2005 7:07 pm
Posts: 21
In the J2C you have to specify the user credentials and use the same in the datasource configurtion. That should solve the problem.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 10 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.