[ http://issues.apache.org/jira/browse/JS2-326?page=all ]
Ate Douma updated JS2-326:
--------------------------
Attachment: j2-LocalDS-patches-20050820.txt
Michael,
I tested your patch and while it seems to work fine when deployed, some
testcases are broken :-(
First of all, I moved your new classes to a new components/rdbms
o.a.j.components.rdbms.ojb package.
That way, these classes can be found for testcases which require an OJB
connection and I think its a better location for these classes.
Note: I've attached new patch diff "j2-LocalDS-patches-20050820.txt" with only
these changes.
But then, still the testcases using SpringEngineHelper (components/portal) to
start a JetspeedEngine fail (TestSpringEngine, TestPipeLine and
TestNavigationalState) with the following error:
org.springframework.transaction.CannotCreateTransactionException: Could not
create OJB transaction; nested exception is
java.lang.UnsupportedOperationException: Not supported in managed environment
java.lang.UnsupportedOperationException: Not supported in managed environment
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.newConnectionFromDriverManager(ConnectionFactoryManagedImpl.java:39)
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl.getConnectionFromPool(ConnectionFactoryNotPooledImpl.java:40)
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(ConnectionFactoryAbstractImpl.java:118)
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookupConnection(ConnectionFactoryManagedImpl.java:33)
at
org.apache.jetspeed.components.rdbms.ojb.ConnectionManagerImpl.getConnection(ConnectionManagerImpl.java:158)
at
org.springframework.orm.ojb.PersistenceBrokerTransactionManager.doBegin(PersistenceBrokerTransactionManager.java:198)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:289)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:202)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:49)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
at $Proxy7.createNode(Unknown Source)
at
org.apache.jetspeed.prefs.impl.PreferencesImpl.<init>(PreferencesImpl.java:96)
at
org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl.init(PreferencesFactoryImpl.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1106)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1076)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:343)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:260)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:221)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:145)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:291)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:317)
at
org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:131)
at
org.apache.jetspeed.components.SpringComponentManager.start(SpringComponentManager.java:217)
at
org.apache.jetspeed.engine.JetspeedEngine.start(JetspeedEngine.java:138)
at
org.apache.jetspeed.testhelpers.SpringEngineHelper.setUp(SpringEngineHelper.java:52)
at
org.apache.jetspeed.engine.AbstractEngineTest.setUp(AbstractEngineTest.java:72)
at junit.framework.TestCase.runBare(TestCase.java:125)
I've no idea yet how to fix this but when I restore the
org.springframework.orm.ojb.support.LocalDataSourceConnectionFactory as
ConnectionFactory
these testcases work again.
I can see our testcases don't provide a managed environment but I've no idea
how do so.
Maybe we should not/need not do that in the testcases but then how to solve
this problem.
Maybe provide a different ConnectjonFactory for testcases but then we will need
to use an Ant filter again...
Anyways, it certainly looks you are on the right track for this and I hope you
(or someone else) might know a simple solution for this one.
I definitely like your patch and as soon as this testcase problem is fixed and
no other problems pop up, I'd like to commit it.
> 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.
--
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]
