[JBoss-dev] [JBoss JIRA] Created: (EJBTHREE-105) DS: add hibernate.dialect metadata

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

DS: add hibernate.dialect metadata
----------------------------------

         Key: EJBTHREE-105
         URL: http://jira.jboss.com/jira/browse/EJBTHREE-105
     Project: EJB 3.0
        Type: Feature Request
    Versions: Preview 4    
 Environment: Linux, JDK 1.5; Jboss 4.0.1sp1
    Reporter: Jens Elkner
    Priority: Critical

Actually IMHO it is not possible, to deploy an EJB3 application to jboss in a relayable way. E.g. an application may ask a user to create a datasource with a certain name, however, it should not care/dictate, what a database the user chooses (IMHO thats one of the biggest advantage of an J2EE server). 

However, since the hibernate.dialect property depends direct on the type of database, an application can't be shipped with a META-INF/hibernate.properties, where the hibernate.dialect is set. E.g. if so <driver-class>oracle.jdbc.driver.OracleDriver</driver-class> and hibernate.dialect=hibernate.dialect=org.hibernate.dialect.MySQLMyISAMDialect
simply would produce garbage.

Editing the META-INF/hibernate.properties is not an option, since if the archive is signed, this would destroy the inegrity of the archive (besides the fact, that it would be unaceppably to ask the user/admin to that).

To solve this problem, IMHO it is neccessary, that a new optional metadata tag should be allowed in <local-tx-datasource>. E.g.:
<datasources>
   ...
   <metadata>
      ...
      <hibernate.dialect>...</hibernate.dialect>
   </metadata>
</datasources>

Now, if the EBJ3 deployer starts deploying an ejb3 archive,
it may have a look at the DS metadata and add/overwrite the hibernate.dialect property. 

Digging around, I guess, that org.jboss.ejb3.entity.HibernateSessionFactory:createSessionFactory(java.util.Collection classes, Properties props) right before 
"if (props != null) cfg.setProperties(props);" 
would be anappropriate place, doing that.

Unfortunately, I do not know, whether/how it is possible and allowed to access the metadata of the datasource at this point. 

If you can give me a hint, I would try to implement/test this...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira