Ate/Michael,
I might be able to provide feedback as well today... but I am not in
complete control of my schedule :).
Thanks,
Randy
Ate Douma (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JS2-326?page=comments#action_12319688 ]
Ate Douma commented on JS2-326:
-------------------------------
Thanks a lot for the quick response Michael.
I will test this out today!
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,
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
