portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Reopened: (JS2-326) Problem with LocalDataSourceConnectionFactory
Date Fri, 09 Sep 2005 12:49:33 GMT
     [ http://issues.apache.org/jira/browse/JS2-326?page=all ]
     
Ate Douma reopened JS2-326:
---------------------------


The new (and default) ConnectionManagerImpl has a problem with when created from a different
application context than the jetspeed.
In Tomcat, the JNDI context is stored in the scope of a application context (classloader).
As the OJB ConnectionFactoryManagedImpl creates new a new JDBC DataSource from the JNDI, it
is very important that this i done within the
correct application context.

If an portlet application for instance saves Portlet Preferences, a context specific OJB PersistentBroker
might get
created (initially) which in turn creates a ConnectionManagerImpl. This is all done within
the portlet application context.

As the current ConnectionManagerImpl always creates a new ConnectionFactory the ConnectionFactory
will have to lookup the JDBC
DataSource from the JNDI in the getConnection() method. 
Because this also happens within the application context, this then fails when not called
within the jetspeed context:
 [org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl] ERROR: Naming Exception
while looking up DataSource (java:comp/env/jdbc/jetspeed)
  Name jdbc is not bound in this Context
  javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
          at org.apache.naming.NamingContext.lookup(NamingContext.java:769)
          at org.apache.naming.NamingContext.lookup(NamingContext.java:139)
          at org.apache.naming.NamingContext.lookup(NamingContext.java:780)
          at org.apache.naming.NamingContext.lookup(NamingContext.java:139)
          at org.apache.naming.NamingContext.lookup(NamingContext.java:780)
          at org.apache.naming.NamingContext.lookup(NamingContext.java:152)
          at org.apache.naming.SelectorContext.lookup(SelectorContext.java:153)
          at javax.naming.InitialContext.lookup(InitialContext.java:351)
          at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDataSource(ConnectionFactoryAbstractImpl.java:210)
          at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(ConnectionFactoryAbstractImpl.java:114)
          at org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookupConnection(ConnectionFactoryManagedImpl.java:33)
          at org.apache.jetspeed.components.rdbms.ojb.ConnectionManagerImpl.getConnection(ConnectionManagerImpl.java:182)

Weird thing is: this doesn't always happen. After a clean deployment this still works, but
then all of a sudden it breaks down.

Anyways, I've implemented a fix for this on three levels:
- a static cache of ConnectionFactory instances so their DataSource cache is used more efficient
- instantiation of the ConnectionFactory using the ConnectionManagerImpl own classloader (Jetspeed)
as ContextClassloader
- retrieval of a new connection from the connectionFactory also using the Jetspeed ContextClassLoader

This now guarantees that the ConnectionManagerImpl always retrieves DataSources from the JNDI
within the Jetspeed application context as it should.
Furthermore, Spring transaction AOP now suddenly properly handles the transaction settings
for PreferencesProvider. 
Before, as well as with the default OJB ConnectionManagerImpl, OJB kept reporting that it
wasn't accessed within an transaction scope.
Why this wasn't working before I haven't looked into, but it now seems it was classloader
related as well.

> 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-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/ReadMsg?listName=ojb-dev@db.apache.org&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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message