[ http://issues.apache.org/jira/browse/JS2-326?page=all ]
Michael Lipp updated JS2-326:
-----------------------------
Attachment: j2-JNDI-lookup-20050910.txt
The applied patch fixes the problem with JNDI lookups. Luckily, the JDBC
connection descriptor accepts arbitrary attributes. So I define one that marks
the JCD as Jetspeed related data source, and only for JCDs thus marked, the
normal ENC is replaced.
BTW, J2-336 can be closed now.
> 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]
