[ http://issues.apache.org/jira/browse/JS2-326?page=all ]
Michael Lipp updated JS2-326:
-----------------------------
Attachment: j2-LocalDS-patches-20050811.txt.gz
Attached are the required patches. They include a new bean
org.apache.jetspeed.util.ConnectionRepositoryEntry that replaces the
org.springframework.jndi.JndiObjectFactoryBean as "connection creator". This
bean properly configures a JCD (JDBC connection descriptor). OJB, however, does
not honor the connection factory class configured in the JCD and always uses
the ConnectionFactory configured in OJB.properties. While this does not cause
problems in production environments (where ConnectionFactoryManagedImpl can
always be used), it requires the property to be modified in OJB.properties for
tests.
The patch therefore also provides an alternate implementation of
ConnectionFactoryImpl. If configured to be used in OJB.properties, this
implementation fixes the problem by first looking if a connection factory is
configured for a specific JCD and using the ConnectionFactory from
OJB.properties as a fallback only. Thus it is sufficient to provide a
differently configured ConnectionRepositoryEntry bean to run the tests (I'm not
sure how tests are run, "maven allTests" doesn't seem to work; I have, however,
successfully run a test in eclipse).
The patch also includes all changes that must be made in the configuration
files.
In both cases, production and test environment, the JCD platform setting is
adapted to the configured data base automaticall. While I did remove the
setting of the platform attribute from repository_database.xml, I did not
remove the replacement actions from the maven build process (this should be
done by someone who knows this process better).
> 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
> Attachments: j2-LocalDS-patches-20050811.txt.gz
>
> 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]
