I am also getting this with MySQL. Are there some new, undocumented settings that need to be in place before I build?
-Scott > -----Original Message----- > From: Scott T Weaver [mailto:[EMAIL PROTECTED] > Sent: Friday, September 23, 2005 12:43 PM > To: 'Jetspeed Developers List' > Subject: RE: [jira] Reopened: (JS2-326) Problem with > LocalDataSourceConnectionFactory > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
