This is causing me serious problems. Are there any work-arounds for it? I specified the platform in the datasource.xml and now I am getting errors that the OJB.properites cannot be found.
-Scott > -----Original Message----- > From: Scott T Weaver (JIRA) [mailto:[EMAIL PROTECTED] > Sent: Friday, September 23, 2005 12:03 PM > To: [email protected] > Subject: [jira] Reopened: (JS2-326) Problem with > LocalDataSourceConnectionFactory > > [ http://issues.apache.org/jira/browse/JS2-326?page=all ] > > Scott T Weaver reopened JS2-326: > -------------------------------- > > > This broken for the JTDS drivers for MSSQL. > jdbcMetadataUtils.fillJCDFromDataSource(jcd, ds, null, null); niether > populates driver class nor the platform name. > > > 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.LocalDataSource > ConnectionFactory > > 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/ReadMsg?listName=ojb- > [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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
