[
http://issues.apache.org/jira/browse/JS2-326?page=comments#action_12330477 ]
Scott T Weaver commented on JS2-326:
------------------------------------
It appears that the OJB.properties is not being found. Has the need for this
been removed? Why is it looking in the tomcat /bin directory for it? Is there
any documentation regarding these changes?
[BOOT] WARN: Could not load properties file 'OJB.properties'. Using default
settings!
d:\jakarta-tomcat-5.0.30\bin\OJB.properties (The system cannot find the file
specified)
java.io.FileNotFoundException: d:\jakarta-tomcat-5.0.30\bin\OJB.properties (The
system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69)
at
org.apache.ojb.broker.util.configuration.impl.ConfigurationAbstractImpl.load(ConfigurationAbstractImpl.java:432)
at
org.apache.ojb.broker.util.configuration.impl.OjbConfiguration.load(OjbConfiguration.java:224)
at
org.apache.ojb.broker.util.configuration.impl.ConfigurationAbstractImpl.<init>(ConfigurationAbstractImpl.java:67)
at
org.apache.ojb.broker.util.configuration.impl.OjbConfiguration.<init>(OjbConfiguration.java:94)
at
org.apache.ojb.broker.util.configuration.impl.OjbConfigurator.<init>(OjbConfigurator.java:55)
at
org.apache.ojb.broker.util.configuration.impl.OjbConfigurator.<clinit>(OjbConfigurator.java:41)
at
org.apache.ojb.broker.metadata.MetadataManager.init(MetadataManager.java:145)
at
org.apache.ojb.broker.metadata.MetadataManager.<init>(MetadataManager.java:139)
at
org.apache.ojb.broker.metadata.MetadataManager.getInstance(MetadataManager.java:173)
at
org.apache.jetspeed.components.rdbms.ojb.ConnectionRepositoryEntry.afterPropertiesSet(ConnectionRepositoryEntry.java:233)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1072)
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:206)
at
org.apache.jetspeed.engine.JetspeedEngine.start(JetspeedEngine.java:138)
at
org.apache.jetspeed.engine.JetspeedServlet.init(JetspeedServlet.java:135)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1044)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:876)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4017)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4337)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
at
org.apache.catalina.core.StandardHostDeployer.addChild(StandardHostDeployer.java:903)
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:324)
at
org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216)
at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:256)
at org.apache.commons.digester.Rule.end(Rule.java:276)
at org.apache.commons.digester.Digester.endElement(Digester.java:1058)
at
org.apache.catalina.util.CatalinaDigester.endElement(CatalinaDigester.java:76)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.digester.Digester.parse(Digester.java:1567)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:488)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:863)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:483)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
at
org.apache.catalina.core.StandardService.start(StandardService.java:480)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
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:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
> 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]
