[ http://issues.apache.org/jira/browse/JS2-326?page=comments#action_12330470 ]
Michael Lipp commented on JS2-326: ---------------------------------- >From the sources: JdbcMetadataUtils recognizes the Sub-Protocol "mysql" and >sets the database type accordingly, i.e. anything that looks like >"jdbc:mysql:..." should be recognized. > Problem with LocalDataSourceConnectionFactory > --------------------------------------------- > > Key: JS2-326 > URL: http://issues.apache.org/jira/browse/JS2-326 > Project: Jetspeed 2 > Type: Bug > Components: Persistence and DAO > Versions: 2.0-M4 > Environment: JBoss/HSQL > Reporter: Michael Lipp > Assignee: Ate Douma > Fix For: 2.0-M4 > Attachments: j2-JNDI-lookup-20050910.txt, > j2-LocalDS-patches-20050811.txt.gz, j2-LocalDS-patches-20050817.txt.gz, > j2-LocalDS-patches-20050820.txt > > I'm trying to get the JBoss security module back to work after the changes > made in the recent weeks. The really big problem is that OJB.properties has > changed and uses LocalDataSourceConnectionFactory now: > ConnectionFactoryClass=org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory > This is rather fatal (at least until we get and use dbojb 1.1). Let me > briefly explain why. > There is a problem when using dbojb in a library or framework or simply > anything that is meant to integrate with other code. The problem is the usage > of static classes and singletons for configuration in dbojb. It implies that > you can configure only a single instance of OJB (within the same > classloader). The issue is known and to be resolved with dbojb 1.1 > (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=11150). > Jetspeed uses dbojb and is thus "in control" of dbojb. Anything that wants to > use dbojb too must either live with the configuration provided by Jetspeed > (at least the parts Jetspeed relies on, some things can certainly be changed > in OJB.properties without breaking Jetspeed) or somehow use dbojb in its own > classloader (not that easily chievable in the J2EE environment). > The JBoss security module for Jetspeed is provided by an MBean in the form of > a "server extension". Obviously, this MBean cannot depend on the deployment > of some WebApplication (Jetspeed) and therefore the MBean > needs its own "instance" of dbojb. Up to M3, this has been no problem because > the MBean simply used the dbojb classes with the configuration information > also used by Jetspeed and thus the Jetspeed web applications never "noticed" > that it wasn't really them that instantiated dbojb (or vice vera, whoever > caused loading first). The MBean augmented the dbojb configuration, however, > by specifying a new JDBC connection description (using the API). This is > necessary because the datasource used by the web application is not available > outside the web application. This has been no problem, the JDBC connection > description has simply been registered in the dbojb ConnectionRepository as > another connection that uses the "global" JNDI entry for the data source. > All this has worked fine up to M3 because the ConnectionRepository is used to > lookup connections by the ConnectionFactoryManagedImpl. But currently, the > LocalDataSourceConnectionFactory is used in place of the > ConnectionFactoryManagedImpl. This means that connection descriptions are no > longer looked up in the ConnectionRespository but must rather exist in a > specific Spring BeanContext (set once). Of course, this is the BeanContext > used (and set) by Jetspeed and this context is not accessible outside > Jetspeed, i.e. it is not accessible by the MBean. > What has been achieved by using LocalDataSourceConnectionFactory? IMO very > little: the connection used by Jetspeed is now configured using a Spring > controlled JavaBean instead of providing the information in > repository_database.xml. What has been lost? A lot: the possibility to > sustain (within the ojb configuration restrictions of Jetspeed) other data > base connections in parallel and thus use dbojb for more object persistence > tasks in parallel to Jetspeed. > I therefore propose to revert this change. Configuration of the db connection > in a JavaBean could still be done (even better) by writing a JavaBean that > creates the JDBC connection description in the ConnectionRepository. Most of > the code can be taken from JetspeedSecurityService. boot/datasource.xml would > instantiate this JavaBean and thus create the entry in the > ConnectionRepository (it is the currently used solution provided by Spring > that leads to the problems). There would be another major advantage to this > solution: dbojb 1.0.3 provides JdbcMetadataUtils.fillJCDFromDataSource which > can be used to obtain initial information for the JDBC connection descriptor > from the JDBC data source. Among this information is the value of "platform". > I.e. we could get rid of the necessity to provide this information by > patching it in the maven scripts (ending up with a WAR that can be deployed > with a single RDBMS type only). The Jetspeed web application would then > automatically adapt to the RDBMs used (as does JetspeedSecurityService > already)! > As has been discussed on the developer's list I'm going to provide the > patches for the proposed change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
