|
»
»
configuration of jdbc URL in context.xml
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
configuration of jdbc URL in context.xml
by Martin Sudmann
::
Rate this Message:
Hi all,
I am running Continuum as a webapp on Tomcat. I first installed it as the standalone version (thus creating the databases in the continuum install directory), but now I want to run it as a .war on Tomcat. I don't know how to configure the JDBC URL correctly: I want to use the databases from the initial install (not inside the Tomcat directory), but when I use an absolute unix file path the logs say that they cannot find the database. <Context path="/continuum" docBase="/users/integ.continue/tomcat/webapps/continuum/continuum.war"> <Resource name="jdbc/users" auth="Container" type="javax.sql.DataSource" username="sa" password="" driverClassName="org.apache.derby.jdbc.EmbeddedDriver" url="jdbc:derby:/users/integ.continue/continuum/data/databases/users;create= false" /> <Resource name="jdbc/continuum" auth="Container" type="javax.sql.DataSource" username="sa" password="" driverClassName="org.apache.derby.jdbc.EmbeddedDriver" url="jdbc:derby:/users/integ.continue/continuum/data/databases/continuum;cre ate=false" /> .. Can anyone help me? Thanks, Martin |
|
|
Re: configuration of jdbc URL in context.xml
by brettporter
::
Rate this Message:
What exception do you obtain? The Derby documentation indicates that
an absolute path should work. - Brett On 16/09/2009, at 4:55 PM, Martin Sudmann wrote: > Hi all, > > > > I am running Continuum as a webapp on Tomcat. > > I first installed it as the standalone version (thus creating the > databases > in the continuum install directory), but now I want to run it as > a .war on > Tomcat. > > I don't know how to configure the JDBC URL correctly: > > I want to use the databases from the initial install (not inside the > Tomcat > directory), but when I use an absolute unix file path the logs say > that they > cannot find the database. > > > > <Context path="/continuum" > > > docBase="/users/integ.continue/tomcat/webapps/continuum/ > continuum.war"> > > <Resource name="jdbc/users" > > auth="Container" > > type="javax.sql.DataSource" > > username="sa" > > password="" > > driverClassName="org.apache.derby.jdbc.EmbeddedDriver" > > > url="jdbc:derby:/users/integ.continue/continuum/data/databases/ > users;create= > false" /> > > <Resource name="jdbc/continuum" > > auth="Container" > > type="javax.sql.DataSource" > > username="sa" > > password="" > > driverClassName="org.apache.derby.jdbc.EmbeddedDriver" > > > url="jdbc:derby:/users/integ.continue/continuum/data/databases/ > continuum;cre > ate=false" /> > > .. > > > > Can anyone help me? > > > > Thanks, > > Martin > |
|
|
RE: configuration of jdbc URL in context.xml
by Martin Sudmann
::
Rate this Message:
I get the trace below, but actually I a afraid that the problem isn't really
the DB access, as I got the same error later with relative paths as well... 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed initialising database. Please check that your database JDBC driver is accessible, and the database URL and userna me/password are correct. Exception : Cannot create PoolableConnectionFactory (Failed to start database '/users/integ.continue/continuum/data/databases/continuum', see the next ex ception for details.) org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Failed to start database '/users/integ.continue/continuum/data/databases/continuum', see the next exception for details.) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource .java:1225) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.ja va:880) at org.jpox.util.FailoverUtils.getConnection(FailoverUtils.java:51) at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java:244) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces sorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc torAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) at org.jpox.store.StoreManagerFactory.getStoreManager(StoreManagerFactory.java: 73) at org.jpox.AbstractPersistenceManager.getStoreManager(AbstractPersistenceManag er.java:295) at org.jpox.AbstractPersistenceManager.<init>(AbstractPersistenceManager.java:2 17) at org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:42) at org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceMana gerFactoryImpl.java:178) at org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceMana gerFactoryImpl.java:153) at org.apache.continuum.dao.AbstractDao.getPersistenceManager(AbstractDao.java: 178) at org.apache.continuum.dao.AbstractDao.getPersistenceManager(AbstractDao.java: 173) at org.apache.continuum.dao.AbstractDao.getAllObjectsDetached(AbstractDao.java: 153) at org.apache.continuum.dao.AbstractDao.getAllObjectsDetached(AbstractDao.java: 148) at org.apache.continuum.dao.AbstractDao.getAllObjectsDetached(AbstractDao.java: 143) at org.apache.continuum.dao.SystemConfigurationDaoImpl.getSystemConfiguration(S ystemConfigurationDaoImpl.java:52) at org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat a(DefaultConfigurationService.java:707) at org.apache.maven.continuum.configuration.DefaultConfigurationService.initial ize(DefaultConfigurationService.java:92) 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:597) Thx, Martin -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : vendredi 18 septembre 2009 04:31 À : users@... Objet : Re: configuration of jdbc URL in context.xml What exception do you obtain? The Derby documentation indicates that an absolute path should work. - Brett On 16/09/2009, at 4:55 PM, Martin Sudmann wrote: > Hi all, > > > > I am running Continuum as a webapp on Tomcat. > > I first installed it as the standalone version (thus creating the > databases > in the continuum install directory), but now I want to run it as > a .war on > Tomcat. > > I don't know how to configure the JDBC URL correctly: > > I want to use the databases from the initial install (not inside the > Tomcat > directory), but when I use an absolute unix file path the logs say > that they > cannot find the database. > > > > <Context path="/continuum" > > > docBase="/users/integ.continue/tomcat/webapps/continuum/ > continuum.war"> > > <Resource name="jdbc/users" > > auth="Container" > > type="javax.sql.DataSource" > > username="sa" > > password="" > > driverClassName="org.apache.derby.jdbc.EmbeddedDriver" > > > url="jdbc:derby:/users/integ.continue/continuum/data/databases/ > users;create= > false" /> > > <Resource name="jdbc/continuum" > > auth="Container" > > type="javax.sql.DataSource" > > username="sa" > > password="" > > driverClassName="org.apache.derby.jdbc.EmbeddedDriver" > > > url="jdbc:derby:/users/integ.continue/continuum/data/databases/ > continuum;cre > ate=false" /> > > .. > > > > Can anyone help me? > > > > Thanks, > > Martin > |
|
|
Re: configuration of jdbc URL in context.xml
by brettporter
::
Rate this Message:
Is there a "next exception" as it states? With Derby, common causes
might be that another instance is connected to it at the same time (eg, the old standalone server). - Brett On 18/09/2009, at 10:53 PM, Martin Sudmann wrote: > I get the trace below, but actually I a afraid that the problem > isn't really > the DB access, as I got the same error later with relative paths as > well... > > 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed > initialising database. Please check that your database JDBC driver is > accessible, and the database URL and userna > me/password are correct. Exception : Cannot create > PoolableConnectionFactory > (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see the > next ex > ception for details.) > org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create > PoolableConnectionFactory (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see > the next exception for details.) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource > (BasicDataSource > .java:1225) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection > (BasicDataSource.ja > va:880) > at org.jpox.util.FailoverUtils.getConnection > (FailoverUtils.java:51) > at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java: > 244) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0 > (Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance > (NativeConstructorAcces > sorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance > (DelegatingConstruc > torAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java: > 513) > at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) > at > org.jpox.store.StoreManagerFactory.getStoreManager > (StoreManagerFactory.java: > 73) > at > org.jpox.AbstractPersistenceManager.getStoreManager > (AbstractPersistenceManag > er.java:295) > at > org.jpox.AbstractPersistenceManager.<init> > (AbstractPersistenceManager.java:2 > 17) > at > org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:42) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:178) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:153) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 178) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 173) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 153) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 148) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 143) > at > org.apache.continuum.dao.SystemConfigurationDaoImpl.getSystemConfiguration > (S > ystemConfigurationDaoImpl.java:52) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat > a(DefaultConfigurationService.java:707) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.initial > ize(DefaultConfigurationService.java:92) > 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:597) > > Thx, > Martin > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : vendredi 18 septembre 2009 04:31 > À : users@... > Objet : Re: configuration of jdbc URL in context.xml > > What exception do you obtain? The Derby documentation indicates that > an absolute path should work. > > - Brett > > On 16/09/2009, at 4:55 PM, Martin Sudmann wrote: > >> Hi all, >> >> >> >> I am running Continuum as a webapp on Tomcat. >> >> I first installed it as the standalone version (thus creating the >> databases >> in the continuum install directory), but now I want to run it as >> a .war on >> Tomcat. >> >> I don't know how to configure the JDBC URL correctly: >> >> I want to use the databases from the initial install (not inside the >> Tomcat >> directory), but when I use an absolute unix file path the logs say >> that they >> cannot find the database. >> >> >> >> <Context path="/continuum" >> >> >> docBase="/users/integ.continue/tomcat/webapps/continuum/ >> continuum.war"> >> >> <Resource name="jdbc/users" >> >> auth="Container" >> >> type="javax.sql.DataSource" >> >> username="sa" >> >> password="" >> >> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >> >> >> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >> users;create= >> false" /> >> >> <Resource name="jdbc/continuum" >> >> auth="Container" >> >> type="javax.sql.DataSource" >> >> username="sa" >> >> password="" >> >> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >> >> >> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >> continuum;cre >> ate=false" /> >> >> .. >> >> >> >> Can anyone help me? >> >> >> >> Thanks, >> >> Martin >> > > |
|
|
RE: configuration of jdbc URL in context.xml
by Martin Sudmann
::
Rate this Message:
Not really (see trace below), or I miss something...
2009-09-15 17:11:55,602 [main] WARN net.sf.ehcache.config.ConfigurationFactory - No configuration found. Configuring ehcache from ehcache-failsafe.xml found in the classpath: jar:file:/users/integ.continue/apache-tomcat-6.0.18/webapps/continuum/WEB-IN F/lib/ehcache-1.5.0.jar!/ehcache-failsafe.xml 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed initialising database. Please check that your database JDBC driver is accessible, and the database URL and userna me/password are correct. Exception : Cannot create PoolableConnectionFactory (Failed to start database '/users/integ.continue/continuum/data/databases/continuum', see the next ex ception for details.) org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Failed to start database '/users/integ.continue/continuum/data/databases/continuum', see the next exception for details.) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource .java:1225) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.ja va:880) at org.jpox.util.FailoverUtils.getConnection(FailoverUtils.java:51) at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java:244) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces sorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc torAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) at org.jpox.store.StoreManagerFactory.getStoreManager(StoreManagerFactory.java: 73) at org.jpox.AbstractPersistenceManager.getStoreManager(AbstractPersistenceManag er.java:295) at org.jpox.AbstractPersistenceManager.<init>(AbstractPersistenceManager.java:2 17) at org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:42) at org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceMana gerFactoryImpl.java:178) at org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceMana gerFactoryImpl.java:153) at org.apache.continuum.dao.AbstractDao.getPersistenceManager(AbstractDao.java: 178) at org.apache.continuum.dao.AbstractDao.getPersistenceManager(AbstractDao.java: 173) at org.apache.continuum.dao.AbstractDao.getAllObjectsDetached(AbstractDao.java: 153) at org.apache.continuum.dao.AbstractDao.getAllObjectsDetached(AbstractDao.java: 148) at org.apache.continuum.dao.AbstractDao.getAllObjectsDetached(AbstractDao.java: 143) at org.apache.continuum.dao.SystemConfigurationDaoImpl.getSystemConfiguration(S ystemConfigurationDaoImpl.java:52) at org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat a(DefaultConfigurationService.java:707) at org.apache.maven.continuum.configuration.DefaultConfigurationService.initial ize(DefaultConfigurationService.java:92) 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:597) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory .invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1414) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory .invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory .initializeBean(AbstractAutowireCapableBeanFactory.java:1335) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory .doCreateBean(AbstractAutowireCapableBeanFactory.java:473) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory $1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory .createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(Ab stractBeanFactory.java:264) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi ngleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(Abst ractBeanFactory.java:261) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra ctBeanFactory.java:185) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra ctBeanFactory.java:168) at org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection(DriverC onnectionFactory.java:38) at org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject(PoolableCon nectionFactory.java:294) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.validateConnectionFactory(BasicD ataSource.java:1247) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource .java:1221) ... 84 more -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : vendredi 18 septembre 2009 15:11 À : users@... Objet : Re: configuration of jdbc URL in context.xml Is there a "next exception" as it states? With Derby, common causes might be that another instance is connected to it at the same time (eg, the old standalone server). - Brett On 18/09/2009, at 10:53 PM, Martin Sudmann wrote: > I get the trace below, but actually I a afraid that the problem > isn't really > the DB access, as I got the same error later with relative paths as > well... > > 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed > initialising database. Please check that your database JDBC driver is > accessible, and the database URL and userna > me/password are correct. Exception : Cannot create > PoolableConnectionFactory > (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see the > next ex > ception for details.) > org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create > PoolableConnectionFactory (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see > the next exception for details.) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource > (BasicDataSource > .java:1225) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection > (BasicDataSource.ja > va:880) > at org.jpox.util.FailoverUtils.getConnection > (FailoverUtils.java:51) > at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java: > 244) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0 > (Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance > (NativeConstructorAcces > sorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance > (DelegatingConstruc > torAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java: > 513) > at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) > at > org.jpox.store.StoreManagerFactory.getStoreManager > (StoreManagerFactory.java: > 73) > at > org.jpox.AbstractPersistenceManager.getStoreManager > (AbstractPersistenceManag > er.java:295) > at > org.jpox.AbstractPersistenceManager.<init> > (AbstractPersistenceManager.java:2 > 17) > at > org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:42) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:178) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:153) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 178) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 173) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 153) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 148) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 143) > at > org.apache.continuum.dao.SystemConfigurationDaoImpl.getSystemConfiguration > (S > ystemConfigurationDaoImpl.java:52) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat > a(DefaultConfigurationService.java:707) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.initial > ize(DefaultConfigurationService.java:92) > 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:597) > > Thx, > Martin > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : vendredi 18 septembre 2009 04:31 > À : users@... > Objet : Re: configuration of jdbc URL in context.xml > > What exception do you obtain? The Derby documentation indicates that > an absolute path should work. > > - Brett > > On 16/09/2009, at 4:55 PM, Martin Sudmann wrote: > >> Hi all, >> >> >> >> I am running Continuum as a webapp on Tomcat. >> >> I first installed it as the standalone version (thus creating the >> databases >> in the continuum install directory), but now I want to run it as >> a .war on >> Tomcat. >> >> I don't know how to configure the JDBC URL correctly: >> >> I want to use the databases from the initial install (not inside the >> Tomcat >> directory), but when I use an absolute unix file path the logs say >> that they >> cannot find the database. >> >> >> >> <Context path="/continuum" >> >> >> docBase="/users/integ.continue/tomcat/webapps/continuum/ >> continuum.war"> >> >> <Resource name="jdbc/users" >> >> auth="Container" >> >> type="javax.sql.DataSource" >> >> username="sa" >> >> password="" >> >> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >> >> >> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >> users;create= >> false" /> >> >> <Resource name="jdbc/continuum" >> >> auth="Container" >> >> type="javax.sql.DataSource" >> >> username="sa" >> >> password="" >> >> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >> >> >> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >> continuum;cre >> ate=false" /> >> >> .. >> >> >> >> Can anyone help me? >> >> >> >> Thanks, >> >> Martin >> > > |
|
|
Re: configuration of jdbc URL in context.xml
by brettporter
::
Rate this Message:
Sorry but there is little I can do to help with that information - I
suggest you try connecting to the database with another application (Eg SquirrelSQL or your IDE's SQL tools), and further investigate Tomcat's documentation for setting up connection pools to see if you can find the problem. Good luck! - Brett On 21/09/2009, at 10:19 PM, Martin Sudmann wrote: > Not really (see trace below), or I miss something... > > 2009-09-15 17:11:55,602 [main] WARN > net.sf.ehcache.config.ConfigurationFactory - No configuration found. > Configuring ehcache from ehcache-failsafe.xml found in the classpath: > jar:file:/users/integ.continue/apache-tomcat-6.0.18/webapps/ > continuum/WEB-IN > F/lib/ehcache-1.5.0.jar!/ehcache-failsafe.xml > 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed > initialising database. Please check that your database JDBC driver is > accessible, and the database URL and userna > me/password are correct. Exception : Cannot create > PoolableConnectionFactory > (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see the > next ex > ception for details.) > org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create > PoolableConnectionFactory (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see > the next exception for details.) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource > (BasicDataSource > .java:1225) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection > (BasicDataSource.ja > va:880) > at org.jpox.util.FailoverUtils.getConnection > (FailoverUtils.java:51) > at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java: > 244) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0 > (Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance > (NativeConstructorAcces > sorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance > (DelegatingConstruc > torAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java: > 513) > at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) > at > org.jpox.store.StoreManagerFactory.getStoreManager > (StoreManagerFactory.java: > 73) > at > org.jpox.AbstractPersistenceManager.getStoreManager > (AbstractPersistenceManag > er.java:295) > at > org.jpox.AbstractPersistenceManager.<init> > (AbstractPersistenceManager.java:2 > 17) > at > org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:42) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:178) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:153) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 178) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 173) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 153) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 148) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 143) > at > org.apache.continuum.dao.SystemConfigurationDaoImpl.getSystemConfiguration > (S > ystemConfigurationDaoImpl.java:52) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat > a(DefaultConfigurationService.java:707) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.initial > ize(DefaultConfigurationService.java:92) > 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:597) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1414) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .initializeBean(AbstractAutowireCapableBeanFactory.java:1335) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .doCreateBean(AbstractAutowireCapableBeanFactory.java:473) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > $1.run(AbstractAutowireCapableBeanFactory.java:409) > at java.security.AccessController.doPrivileged(Native Method) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .createBean(AbstractAutowireCapableBeanFactory.java:380) > at > org.springframework.beans.factory.support.AbstractBeanFactory > $1.getObject(Ab > stractBeanFactory.java:264) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi > ngleton(DefaultSingletonBeanRegistry.java:222) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean > (Abst > ractBeanFactory.java:261) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean > (Abstra > ctBeanFactory.java:185) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean > (Abstra > ctBeanFactory.java:168) > at > org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection > (DriverC > onnectionFactory.java:38) > at > org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject > (PoolableCon > nectionFactory.java:294) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.validateConnectionFactory > (BasicD > ataSource.java:1247) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource > (BasicDataSource > .java:1221) > ... 84 more > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : vendredi 18 septembre 2009 15:11 > À : users@... > Objet : Re: configuration of jdbc URL in context.xml > > Is there a "next exception" as it states? With Derby, common causes > might be that another instance is connected to it at the same time > (eg, the old standalone server). > > - Brett > > On 18/09/2009, at 10:53 PM, Martin Sudmann wrote: > >> I get the trace below, but actually I a afraid that the problem >> isn't really >> the DB access, as I got the same error later with relative paths as >> well... >> >> 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed >> initialising database. Please check that your database JDBC driver is >> accessible, and the database URL and userna >> me/password are correct. Exception : Cannot create >> PoolableConnectionFactory >> (Failed to start database >> '/users/integ.continue/continuum/data/databases/continuum', see the >> next ex >> ception for details.) >> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create >> PoolableConnectionFactory (Failed to start database >> '/users/integ.continue/continuum/data/databases/continuum', see >> the next exception for details.) >> at >> org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource >> (BasicDataSource >> .java:1225) >> at >> org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection >> (BasicDataSource.ja >> va:880) >> at org.jpox.util.FailoverUtils.getConnection >> (FailoverUtils.java:51) >> at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java: >> 244) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0 >> (Native >> Method) >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance >> (NativeConstructorAcces >> sorImpl.java:39) >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance >> (DelegatingConstruc >> torAccessorImpl.java:27) >> at java.lang.reflect.Constructor.newInstance(Constructor.java: >> 513) >> at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) >> at >> org.jpox.store.StoreManagerFactory.getStoreManager >> (StoreManagerFactory.java: >> 73) >> at >> org.jpox.AbstractPersistenceManager.getStoreManager >> (AbstractPersistenceManag >> er.java:295) >> at >> org.jpox.AbstractPersistenceManager.<init> >> (AbstractPersistenceManager.java:2 >> 17) >> at >> org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java: >> 42) >> at >> org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager >> (PersistenceMana >> gerFactoryImpl.java:178) >> at >> org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager >> (PersistenceMana >> gerFactoryImpl.java:153) >> at >> org.apache.continuum.dao.AbstractDao.getPersistenceManager >> (AbstractDao.java: >> 178) >> at >> org.apache.continuum.dao.AbstractDao.getPersistenceManager >> (AbstractDao.java: >> 173) >> at >> org.apache.continuum.dao.AbstractDao.getAllObjectsDetached >> (AbstractDao.java: >> 153) >> at >> org.apache.continuum.dao.AbstractDao.getAllObjectsDetached >> (AbstractDao.java: >> 148) >> at >> org.apache.continuum.dao.AbstractDao.getAllObjectsDetached >> (AbstractDao.java: >> 143) >> at >> org.apache.continuum.dao.SystemConfigurationDaoImpl.getSystemConfiguration > >> (S >> ystemConfigurationDaoImpl.java:52) >> at >> > org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat >> a(DefaultConfigurationService.java:707) >> at >> > org.apache.maven.continuum.configuration.DefaultConfigurationService.initial >> ize(DefaultConfigurationService.java:92) >> 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:597) >> >> Thx, >> Martin >> >> -----Message d'origine----- >> De : Brett Porter [mailto:brett@...] De la part de Brett >> Porter >> Envoyé : vendredi 18 septembre 2009 04:31 >> À : users@... >> Objet : Re: configuration of jdbc URL in context.xml >> >> What exception do you obtain? The Derby documentation indicates that >> an absolute path should work. >> >> - Brett >> >> On 16/09/2009, at 4:55 PM, Martin Sudmann wrote: >> >>> Hi all, >>> >>> >>> >>> I am running Continuum as a webapp on Tomcat. >>> >>> I first installed it as the standalone version (thus creating the >>> databases >>> in the continuum install directory), but now I want to run it as >>> a .war on >>> Tomcat. >>> >>> I don't know how to configure the JDBC URL correctly: >>> >>> I want to use the databases from the initial install (not inside the >>> Tomcat >>> directory), but when I use an absolute unix file path the logs say >>> that they >>> cannot find the database. >>> >>> >>> >>> <Context path="/continuum" >>> >>> >>> docBase="/users/integ.continue/tomcat/webapps/continuum/ >>> continuum.war"> >>> >>> <Resource name="jdbc/users" >>> >>> auth="Container" >>> >>> type="javax.sql.DataSource" >>> >>> username="sa" >>> >>> password="" >>> >>> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >>> >>> >>> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >>> users;create= >>> false" /> >>> >>> <Resource name="jdbc/continuum" >>> >>> auth="Container" >>> >>> type="javax.sql.DataSource" >>> >>> username="sa" >>> >>> password="" >>> >>> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >>> >>> >>> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >>> continuum;cre >>> ate=false" /> >>> >>> .. >>> >>> >>> >>> Can anyone help me? >>> >>> >>> >>> Thanks, >>> >>> Martin >>> >> >> > > |
|
|
RE: configuration of jdbc URL in context.xml
by Martin Sudmann
::
Rate this Message:
Thanks Brett,
When I deleted the old standalone instance the Derby DB could be accessed correctly. Martin -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : lundi 21 septembre 2009 18:42 À : users@... Objet : Re: configuration of jdbc URL in context.xml Sorry but there is little I can do to help with that information - I suggest you try connecting to the database with another application (Eg SquirrelSQL or your IDE's SQL tools), and further investigate Tomcat's documentation for setting up connection pools to see if you can find the problem. Good luck! - Brett On 21/09/2009, at 10:19 PM, Martin Sudmann wrote: > Not really (see trace below), or I miss something... > > 2009-09-15 17:11:55,602 [main] WARN > net.sf.ehcache.config.ConfigurationFactory - No configuration found. > Configuring ehcache from ehcache-failsafe.xml found in the classpath: > jar:file:/users/integ.continue/apache-tomcat-6.0.18/webapps/ > continuum/WEB-IN > F/lib/ehcache-1.5.0.jar!/ehcache-failsafe.xml > 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed > initialising database. Please check that your database JDBC driver is > accessible, and the database URL and userna > me/password are correct. Exception : Cannot create > PoolableConnectionFactory > (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see the > next ex > ception for details.) > org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create > PoolableConnectionFactory (Failed to start database > '/users/integ.continue/continuum/data/databases/continuum', see > the next exception for details.) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource > (BasicDataSource > .java:1225) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection > (BasicDataSource.ja > va:880) > at org.jpox.util.FailoverUtils.getConnection > (FailoverUtils.java:51) > at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java: > 244) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0 > (Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance > (NativeConstructorAcces > sorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance > (DelegatingConstruc > torAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java: > 513) > at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) > at > org.jpox.store.StoreManagerFactory.getStoreManager > (StoreManagerFactory.java: > 73) > at > org.jpox.AbstractPersistenceManager.getStoreManager > (AbstractPersistenceManag > er.java:295) > at > org.jpox.AbstractPersistenceManager.<init> > (AbstractPersistenceManager.java:2 > 17) > at > org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:42) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:178) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager > (PersistenceMana > gerFactoryImpl.java:153) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 178) > at > org.apache.continuum.dao.AbstractDao.getPersistenceManager > (AbstractDao.java: > 173) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 153) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 148) > at > org.apache.continuum.dao.AbstractDao.getAllObjectsDetached > (AbstractDao.java: > 143) > at > org.apache.continuum.dao.SystemConfigurationDaoImpl.getSystemConfiguration > (S > ystemConfigurationDaoImpl.java:52) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat > a(DefaultConfigurationService.java:707) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.initial > ize(DefaultConfigurationService.java:92) > 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:597) > at > > .invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1414) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1375) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .initializeBean(AbstractAutowireCapableBeanFactory.java:1335) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .doCreateBean(AbstractAutowireCapableBeanFactory.java:473) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > $1.run(AbstractAutowireCapableBeanFactory.java:409) > at java.security.AccessController.doPrivileged(Native Method) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory > .createBean(AbstractAutowireCapableBeanFactory.java:380) > at > org.springframework.beans.factory.support.AbstractBeanFactory > $1.getObject(Ab > stractBeanFactory.java:264) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSi > ngleton(DefaultSingletonBeanRegistry.java:222) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean > (Abst > ractBeanFactory.java:261) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean > (Abstra > ctBeanFactory.java:185) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean > (Abstra > ctBeanFactory.java:168) > at > org.apache.tomcat.dbcp.dbcp.DriverConnectionFactory.createConnection > (DriverC > onnectionFactory.java:38) > at > org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.makeObject > (PoolableCon > nectionFactory.java:294) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.validateConnectionFactory > (BasicD > ataSource.java:1247) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource > (BasicDataSource > .java:1221) > ... 84 more > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : vendredi 18 septembre 2009 15:11 > À : users@... > Objet : Re: configuration of jdbc URL in context.xml > > Is there a "next exception" as it states? With Derby, common causes > might be that another instance is connected to it at the same time > (eg, the old standalone server). > > - Brett > > On 18/09/2009, at 10:53 PM, Martin Sudmann wrote: > >> I get the trace below, but actually I a afraid that the problem >> isn't really >> the DB access, as I got the same error later with relative paths as >> well... >> >> 2009-09-15 17:11:57,175 [main] ERROR JPOX.RDBMS.Schema - Failed >> initialising database. Please check that your database JDBC driver is >> accessible, and the database URL and userna >> me/password are correct. Exception : Cannot create >> PoolableConnectionFactory >> (Failed to start database >> '/users/integ.continue/continuum/data/databases/continuum', see the >> next ex >> ception for details.) >> org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create >> PoolableConnectionFactory (Failed to start database >> '/users/integ.continue/continuum/data/databases/continuum', see >> the next exception for details.) >> at >> org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource >> (BasicDataSource >> .java:1225) >> at >> org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection >> (BasicDataSource.ja >> va:880) >> at org.jpox.util.FailoverUtils.getConnection >> (FailoverUtils.java:51) >> at org.jpox.store.rdbms.RDBMSManager.<init>(RDBMSManager.java: >> 244) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0 >> (Native >> Method) >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance >> (NativeConstructorAcces >> sorImpl.java:39) >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance >> (DelegatingConstruc >> torAccessorImpl.java:27) >> at java.lang.reflect.Constructor.newInstance(Constructor.java: >> 513) >> at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) >> at >> org.jpox.store.StoreManagerFactory.getStoreManager >> (StoreManagerFactory.java: >> 73) >> at >> org.jpox.AbstractPersistenceManager.getStoreManager >> (AbstractPersistenceManag >> er.java:295) >> at >> org.jpox.AbstractPersistenceManager.<init> >> (AbstractPersistenceManager.java:2 >> 17) >> at >> org.jpox.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java: >> 42) >> at >> org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager >> (PersistenceMana >> gerFactoryImpl.java:178) >> at >> org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager >> (PersistenceMana >> gerFactoryImpl.java:153) >> at >> org.apache.continuum.dao.AbstractDao.getPersistenceManager >> (AbstractDao.java: >> 178) >> at >> org.apache.continuum.dao.AbstractDao.getPersistenceManager >> (AbstractDao.java: >> 173) >> at >> org.apache.continuum.dao.AbstractDao.getAllObjectsDetached >> (AbstractDao.java: >> 153) >> at >> org.apache.continuum.dao.AbstractDao.getAllObjectsDetached >> (AbstractDao.java: >> 148) >> at >> org.apache.continuum.dao.AbstractDao.getAllObjectsDetached >> (AbstractDao.java: >> 143) >> at >> > >> (S >> ystemConfigurationDaoImpl.java:52) >> at >> > org.apache.maven.continuum.configuration.DefaultConfigurationService.loadDat >> a(DefaultConfigurationService.java:707) >> at >> > org.apache.maven.continuum.configuration.DefaultConfigurationService.initial >> ize(DefaultConfigurationService.java:92) >> 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:597) >> >> Thx, >> Martin >> >> -----Message d'origine----- >> De : Brett Porter [mailto:brett@...] De la part de Brett >> Porter >> Envoyé : vendredi 18 septembre 2009 04:31 >> À : users@... >> Objet : Re: configuration of jdbc URL in context.xml >> >> What exception do you obtain? The Derby documentation indicates that >> an absolute path should work. >> >> - Brett >> >> On 16/09/2009, at 4:55 PM, Martin Sudmann wrote: >> >>> Hi all, >>> >>> >>> >>> I am running Continuum as a webapp on Tomcat. >>> >>> I first installed it as the standalone version (thus creating the >>> databases >>> in the continuum install directory), but now I want to run it as >>> a .war on >>> Tomcat. >>> >>> I don't know how to configure the JDBC URL correctly: >>> >>> I want to use the databases from the initial install (not inside the >>> Tomcat >>> directory), but when I use an absolute unix file path the logs say >>> that they >>> cannot find the database. >>> >>> >>> >>> <Context path="/continuum" >>> >>> >>> docBase="/users/integ.continue/tomcat/webapps/continuum/ >>> continuum.war"> >>> >>> <Resource name="jdbc/users" >>> >>> auth="Container" >>> >>> type="javax.sql.DataSource" >>> >>> username="sa" >>> >>> password="" >>> >>> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >>> >>> >>> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >>> users;create= >>> false" /> >>> >>> <Resource name="jdbc/continuum" >>> >>> auth="Container" >>> >>> type="javax.sql.DataSource" >>> >>> username="sa" >>> >>> password="" >>> >>> driverClassName="org.apache.derby.jdbc.EmbeddedDriver" >>> >>> >>> url="jdbc:derby:/users/integ.continue/continuum/data/databases/ >>> continuum;cre >>> ate=false" /> >>> >>> .. >>> >>> >>> >>> Can anyone help me? >>> >>> >>> >>> Thanks, >>> >>> Martin >>> >> >> > > |
|
|
Current prepare build queue never emptied
by Martin Sudmann
::
Rate this Message:
Hi,
I have upgraded to 1.3.4 build 807129, running on tomcat with the default Derby DB. SCM is Bazaar. I started with a fresh Derby DB. When I start a build project manually, it enter the "prepare build" queue, but it never leaves that queue, blocking all waiting builds. The build never shows up on the "constructions" screen of the project. The project is configured to work in mode update (no full extractions). In the continuum.log file I get the following, whenever the screen of the build queues refreshes: 2009-09-23 11:49:11,014 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'none' in namespace: ''. Form action defaulting to 'action' attribute's literal value. 2009-09-23 11:49:11,015 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'none' in namespace: ''. Form action defaulting to 'action' attribute's literal value. 2009-09-23 11:49:11,015 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'none' in namespace: ''. Form action defaulting to 'action' attribute's literal value. 2009-09-23 11:49:11,016 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'none' in namespace: ''. Form action defaulting to 'action' attribute's literal value. 2009-09-23 11:49:11,018 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'none' in namespace: ''. Form action defaulting to 'action' attribute's literal value. 2009-09-23 11:49:11,020 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'none' in namespace: ''. Form action defaulting to 'action' attribute's literal value. 2009-09-23 11:49:11,020 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'removePrepareBuildEntries.action' in namespace: ''. Form action defaulting to 'action' attribute's literal value. 2009-09-23 11:49:11,023 [http-9090-2] WARN org.apache.struts2.components.Form - No configuration found for the specified action: 'removePrepareBuildEntries.action' in namespace: ''. Form action defaulting to 'action' attribute's literal value. I also get a lot of SCM warnings (don't know if this is related though): 2009-09-23 11:40:53,695 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V37_0_0 2009-09-23 11:40:53,714 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V36_0_0 2009-09-23 11:40:53,719 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V35_0_0 2009-09-23 11:40:53,727 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V34_0_0 2009-09-23 11:40:53,730 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V33_0_0 2009-09-23 11:40:53,734 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V32_0_1 2009-09-23 11:40:53,735 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V32_0_0 2009-09-23 11:40:53,749 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_3 2009-09-23 11:40:53,750 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_2 2009-09-23 11:40:53,751 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_1 2009-09-23 11:40:53,752 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_0 2009-09-23 11:40:53,760 [Thread-30] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V30_0_0 Thanks for your help, Martin |
|
|
Re: Current prepare build queue never emptied
by brettporter
::
Rate this Message:
On 23/09/2009, at 7:57 PM, Martin Sudmann wrote:
> > 2009-09-23 11:49:11,014 [http-9090-2] WARN > org.apache.struts2.components.Form - No configuration found for the > specified action: 'none' in namespace: ''. Form action defaulting to > 'action' attribute's literal value. This could be a bug in the page that you should report, but I don't think it's the cause of the problem > I also get a lot of SCM warnings (don't know if this is related > though): > > 2009-09-23 11:40:53,695 [Thread-30] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V37_0_0 The SCM problem seems the one relevant to your builds getting stuck. This is coming from the bazaar SCM provider that it doesn't understand the output line "tags: V37_0_0". It shouldn't block it though, so I'm not sure. Do the logs state what bzr command is being run? - Brett |
|
|
RE: Current prepare build queue never emptied
by Martin Sudmann
::
Rate this Message:
The Bazaar commands are the following, the "tags" output comes from the
command "bzr log --verbose". But nothing has changed in our Bazaar configuration and the output of that command has always been like that. When I restart tomcat, the queue is emptied, though the build button on the project line on the project group page still shows "cancel build". When I try another build, it instantly gets stuck with the same log entries as before. 2009-09-24 07:30:00,062 [pool-7-thread-1] INFO org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/sh -c cd /users/integ.continue/apache-tomcat-6.0.18/webapps/con tinuum/data/working-directory/7 && bzr pull 2009-09-24 07:30:00,614 [pool-7-thread-1] INFO org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/sh -c cd /users/integ.continue/apache-tomcat-6.0.18/webapps/con tinuum/data/working-directory/7 && bzr revno 2009-09-24 07:30:00,848 [pool-7-thread-1] INFO org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/sh -c cd /users/integ.continue/apache-tomcat-6.0.18/webapps/con tinuum/data/working-directory/7 && bzr diff --revision 25547 2009-09-24 07:30:03,914 [pool-7-thread-1] INFO org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/sh -c cd /users/integ.continue/apache-tomcat-6.0.18/webapps/con tinuum/data/working-directory/7 && bzr log --verbose 2009-09-24 07:30:39,339 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V50_0_1 2009-09-24 07:30:39,339 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V50_0_0 2009-09-24 07:31:44,008 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V49_0_0 2009-09-24 07:32:56,251 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V48_0_0 2009-09-24 07:32:56,261 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V47_0_1 2009-09-24 07:32:56,262 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V47_0_0 2009-09-24 07:35:06,347 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V46_0_1 2009-09-24 07:35:06,348 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V46_0_0 2009-09-24 07:35:06,364 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V45_0_1 2009-09-24 07:35:06,364 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V45_0_0 2009-09-24 07:35:06,364 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V42_0_0 2009-09-24 07:35:06,374 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V44_0_2 2009-09-24 07:35:06,376 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V44_0_1 2009-09-24 07:35:06,376 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V44_0_0 2009-09-24 07:38:42,451 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V43_0_2 2009-09-24 07:38:42,452 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V43_0_1 2009-09-24 07:38:42,453 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V43_0_0 2009-09-24 07:38:42,476 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: 2009-09-24 07:38:42,479 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V41_0_1 2009-09-24 07:38:42,481 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V41_0_0 2009-09-24 07:38:42,490 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V40_0_0 2009-09-24 07:38:42,500 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V39_0_0 2009-09-24 07:42:17,269 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V38_0_0 2009-09-24 07:42:17,271 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V37_0_0 2009-09-24 07:42:17,285 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V36_0_0 2009-09-24 07:42:17,288 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V35_0_0 2009-09-24 07:42:17,294 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V34_0_0 2009-09-24 07:42:17,296 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V33_0_0 2009-09-24 07:42:17,299 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V32_0_1 2009-09-24 07:42:17,300 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V32_0_0 2009-09-24 07:42:17,311 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_3 2009-09-24 07:42:17,311 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_2 2009-09-24 07:42:17,312 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_1 2009-09-24 07:42:17,312 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V31_0_0 2009-09-24 07:45:54,142 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: tags: V30_0_0 2009-09-24 07:45:54,143 [Thread-79] WARN org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure out of: : -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : jeudi 24 septembre 2009 01:34 À : users@... Objet : Re: Current prepare build queue never emptied On 23/09/2009, at 7:57 PM, Martin Sudmann wrote: > > 2009-09-23 11:49:11,014 [http-9090-2] WARN > org.apache.struts2.components.Form - No configuration found for the > specified action: 'none' in namespace: ''. Form action defaulting to > 'action' attribute's literal value. This could be a bug in the page that you should report, but I don't think it's the cause of the problem > I also get a lot of SCM warnings (don't know if this is related > though): > > 2009-09-23 11:40:53,695 [Thread-30] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V37_0_0 The SCM problem seems the one relevant to your builds getting stuck. This is coming from the bazaar SCM provider that it doesn't understand the output line "tags: V37_0_0". It shouldn't block it though, so I'm not sure. Do the logs state what bzr command is being run? - Brett |
|
|
Re: Current prepare build queue never emptied
by brettporter
::
Rate this Message:
Does this happen on freshly created projects as well, or is only
projects in a certain state? Do you have projects using other SCMs? - Brett On 24/09/2009, at 5:59 PM, Martin Sudmann wrote: > The Bazaar commands are the following, the "tags" output comes from > the > command "bzr log --verbose". But nothing has changed in our Bazaar > configuration and the output of that command has always been like > that. > When I restart tomcat, the queue is emptied, though the build button > on the > project line on the project group page still shows "cancel build". > When I try another build, it instantly gets stuck with the same log > entries > as before. > > > 2009-09-24 07:30:00,062 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr pull > 2009-09-24 07:30:00,614 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr revno > 2009-09-24 07:30:00,848 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr diff --revision 25547 > 2009-09-24 07:30:03,914 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr log --verbose > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_1 > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_0 > 2009-09-24 07:31:44,008 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V49_0_0 > 2009-09-24 07:32:56,251 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V48_0_0 > 2009-09-24 07:32:56,261 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_1 > 2009-09-24 07:32:56,262 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_0 > 2009-09-24 07:35:06,347 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_1 > 2009-09-24 07:35:06,348 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_1 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V42_0_0 > 2009-09-24 07:35:06,374 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_2 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_1 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_0 > 2009-09-24 07:38:42,451 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_2 > 2009-09-24 07:38:42,452 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_1 > 2009-09-24 07:38:42,453 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_0 > 2009-09-24 07:38:42,476 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > 2009-09-24 07:38:42,479 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_1 > 2009-09-24 07:38:42,481 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_0 > 2009-09-24 07:38:42,490 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V40_0_0 > 2009-09-24 07:38:42,500 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V39_0_0 > 2009-09-24 07:42:17,269 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V38_0_0 > 2009-09-24 07:42:17,271 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V37_0_0 > 2009-09-24 07:42:17,285 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V36_0_0 > 2009-09-24 07:42:17,288 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V35_0_0 > 2009-09-24 07:42:17,294 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V34_0_0 > 2009-09-24 07:42:17,296 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V33_0_0 > 2009-09-24 07:42:17,299 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_1 > 2009-09-24 07:42:17,300 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_0 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_3 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_2 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_1 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_0 > 2009-09-24 07:45:54,142 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V30_0_0 > 2009-09-24 07:45:54,143 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > : > > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : jeudi 24 septembre 2009 01:34 > À : users@... > Objet : Re: Current prepare build queue never emptied > > On 23/09/2009, at 7:57 PM, Martin Sudmann wrote: > >> >> 2009-09-23 11:49:11,014 [http-9090-2] WARN >> org.apache.struts2.components.Form - No configuration found for the >> specified action: 'none' in namespace: ''. Form action defaulting to >> 'action' attribute's literal value. > > This could be a bug in the page that you should report, but I don't > think it's the cause of the problem > >> I also get a lot of SCM warnings (don't know if this is related >> though): >> >> 2009-09-23 11:40:53,695 [Thread-30] WARN >> org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure >> out of: >> tags: V37_0_0 > > The SCM problem seems the one relevant to your builds getting stuck. > This is coming from the bazaar SCM provider that it doesn't understand > the output line "tags: V37_0_0". > > It shouldn't block it though, so I'm not sure. Do the logs state what > bzr command is being run? > > - Brett > > > |
|
|
RE: Current prepare build queue never emptied
by Martin Sudmann
::
Rate this Message:
This happens also to freshly created projects. I think that the first
project after installation passed 3 times, using the DEFAULT_SCHEDULE with the default build queue. Then I added 3 more build queues and clicked on the build button for 2 projects rapidly one after the other; the first one got stuck like I described in "current prepare build queue" and blocked the second in "prepare build queue". I could delete the second one, but no way to get rid of the first one in the "current" queue. By the way, I have created the Jira http://jira.codehaus.org/browse/CONTINUUM-2369. Do you know where I can get a 1.3.3 or 1.3.2 war file from the download site in order to test if this pb is specific to the new version? My old war file got corrupted. Thanks, Martin -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : lundi 28 septembre 2009 01:20 À : users@... Objet : Re: Current prepare build queue never emptied Does this happen on freshly created projects as well, or is only projects in a certain state? Do you have projects using other SCMs? - Brett On 24/09/2009, at 5:59 PM, Martin Sudmann wrote: > The Bazaar commands are the following, the "tags" output comes from > the > command "bzr log --verbose". But nothing has changed in our Bazaar > configuration and the output of that command has always been like > that. > When I restart tomcat, the queue is emptied, though the build button > on the > project line on the project group page still shows "cancel build". > When I try another build, it instantly gets stuck with the same log > entries > as before. > > > 2009-09-24 07:30:00,062 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr pull > 2009-09-24 07:30:00,614 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr revno > 2009-09-24 07:30:00,848 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr diff --revision 25547 > 2009-09-24 07:30:03,914 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr log --verbose > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_1 > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_0 > 2009-09-24 07:31:44,008 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V49_0_0 > 2009-09-24 07:32:56,251 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V48_0_0 > 2009-09-24 07:32:56,261 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_1 > 2009-09-24 07:32:56,262 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_0 > 2009-09-24 07:35:06,347 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_1 > 2009-09-24 07:35:06,348 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_1 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V42_0_0 > 2009-09-24 07:35:06,374 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_2 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_1 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_0 > 2009-09-24 07:38:42,451 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_2 > 2009-09-24 07:38:42,452 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_1 > 2009-09-24 07:38:42,453 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_0 > 2009-09-24 07:38:42,476 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > 2009-09-24 07:38:42,479 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_1 > 2009-09-24 07:38:42,481 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_0 > 2009-09-24 07:38:42,490 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V40_0_0 > 2009-09-24 07:38:42,500 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V39_0_0 > 2009-09-24 07:42:17,269 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V38_0_0 > 2009-09-24 07:42:17,271 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V37_0_0 > 2009-09-24 07:42:17,285 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V36_0_0 > 2009-09-24 07:42:17,288 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V35_0_0 > 2009-09-24 07:42:17,294 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V34_0_0 > 2009-09-24 07:42:17,296 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V33_0_0 > 2009-09-24 07:42:17,299 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_1 > 2009-09-24 07:42:17,300 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_0 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_3 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_2 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_1 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_0 > 2009-09-24 07:45:54,142 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V30_0_0 > 2009-09-24 07:45:54,143 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > : > > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : jeudi 24 septembre 2009 01:34 > À : users@... > Objet : Re: Current prepare build queue never emptied > > On 23/09/2009, at 7:57 PM, Martin Sudmann wrote: > >> >> 2009-09-23 11:49:11,014 [http-9090-2] WARN >> org.apache.struts2.components.Form - No configuration found for the >> specified action: 'none' in namespace: ''. Form action defaulting to >> 'action' attribute's literal value. > > This could be a bug in the page that you should report, but I don't > think it's the cause of the problem > >> I also get a lot of SCM warnings (don't know if this is related >> though): >> >> 2009-09-23 11:40:53,695 [Thread-30] WARN >> org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure >> out of: >> tags: V37_0_0 > > The SCM problem seems the one relevant to your builds getting stuck. > This is coming from the bazaar SCM provider that it doesn't understand > the output line "tags: V37_0_0". > > It shouldn't block it though, so I'm not sure. Do the logs state what > bzr command is being run? > > - Brett > > > |
|
|
RE: Current prepare build queue never emptied
by Parashar-c, Jay
::
Rate this Message:
Not sure if it's related to this topic of builds getting stuck in build queue. I have version 1.3.4 and have only one project(the default project is deleted and we have our own one). On every build, the build shows the icon of "building" and the log says that projects are in the build queue. I am unable to build any projects now (either through the scheduler or manually). The "building" state remains for ever. The checking out phase happens successfully.
Is there a work around? This will be a great help if there is a way to build the project. Currently, we are stuck. Appreciate any help Thanks Jay "2009-09-28 08:02:27,166 [pool-7-thread-1] INFO org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor - Ending prepare build 2009-09-28 08:02:27,198 [pool-7-thread-1] INFO org.apache.maven.continuum.scm.queue.PrepareBuildProjectsTaskExecutor - Performing action create-build-project-task 2009-09-28 08:02:27,198 [pool-7-thread-1] INFO action#create-build-project-task - Project 'LIBSnxtGen project' already being built. 2009-09-28 08:02:27,198 [pool-7-thread-1] ERROR org.apache.continuum.buildmanager.ParallelBuildsManager - Projects are already in build queue." -----Original Message----- From: Martin Sudmann [mailto:martin.sudmann@...] Sent: Monday, September 28, 2009 7:23 AM To: users@... Subject: RE: Current prepare build queue never emptied This happens also to freshly created projects. I think that the first project after installation passed 3 times, using the DEFAULT_SCHEDULE with the default build queue. Then I added 3 more build queues and clicked on the build button for 2 projects rapidly one after the other; the first one got stuck like I described in "current prepare build queue" and blocked the second in "prepare build queue". I could delete the second one, but no way to get rid of the first one in the "current" queue. By the way, I have created the Jira http://jira.codehaus.org/browse/CONTINUUM-2369. Do you know where I can get a 1.3.3 or 1.3.2 war file from the download site in order to test if this pb is specific to the new version? My old war file got corrupted. Thanks, Martin -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : lundi 28 septembre 2009 01:20 À : users@... Objet : Re: Current prepare build queue never emptied Does this happen on freshly created projects as well, or is only projects in a certain state? Do you have projects using other SCMs? - Brett On 24/09/2009, at 5:59 PM, Martin Sudmann wrote: > The Bazaar commands are the following, the "tags" output comes from > the > command "bzr log --verbose". But nothing has changed in our Bazaar > configuration and the output of that command has always been like > that. > When I restart tomcat, the queue is emptied, though the build button > on the > project line on the project group page still shows "cancel build". > When I try another build, it instantly gets stuck with the same log > entries > as before. > > > 2009-09-24 07:30:00,062 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr pull > 2009-09-24 07:30:00,614 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr revno > 2009-09-24 07:30:00,848 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr diff --revision 25547 > 2009-09-24 07:30:03,914 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr log --verbose > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_1 > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_0 > 2009-09-24 07:31:44,008 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V49_0_0 > 2009-09-24 07:32:56,251 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V48_0_0 > 2009-09-24 07:32:56,261 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_1 > 2009-09-24 07:32:56,262 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_0 > 2009-09-24 07:35:06,347 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_1 > 2009-09-24 07:35:06,348 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_1 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V42_0_0 > 2009-09-24 07:35:06,374 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_2 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_1 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_0 > 2009-09-24 07:38:42,451 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_2 > 2009-09-24 07:38:42,452 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_1 > 2009-09-24 07:38:42,453 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_0 > 2009-09-24 07:38:42,476 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > 2009-09-24 07:38:42,479 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_1 > 2009-09-24 07:38:42,481 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_0 > 2009-09-24 07:38:42,490 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V40_0_0 > 2009-09-24 07:38:42,500 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V39_0_0 > 2009-09-24 07:42:17,269 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V38_0_0 > 2009-09-24 07:42:17,271 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V37_0_0 > 2009-09-24 07:42:17,285 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V36_0_0 > 2009-09-24 07:42:17,288 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V35_0_0 > 2009-09-24 07:42:17,294 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V34_0_0 > 2009-09-24 07:42:17,296 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V33_0_0 > 2009-09-24 07:42:17,299 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_1 > 2009-09-24 07:42:17,300 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_0 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_3 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_2 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_1 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_0 > 2009-09-24 07:45:54,142 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V30_0_0 > 2009-09-24 07:45:54,143 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > : > > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : jeudi 24 septembre 2009 01:34 > À : users@... > Objet : Re: Current prepare build queue never emptied > > On 23/09/2009, at 7:57 PM, Martin Sudmann wrote: > >> >> 2009-09-23 11:49:11,014 [http-9090-2] WARN >> org.apache.struts2.components.Form - No configuration found for the >> specified action: 'none' in namespace: ''. Form action defaulting to >> 'action' attribute's literal value. > > This could be a bug in the page that you should report, but I don't > think it's the cause of the problem > >> I also get a lot of SCM warnings (don't know if this is related >> though): >> >> 2009-09-23 11:40:53,695 [Thread-30] WARN >> org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure >> out of: >> tags: V37_0_0 > > The SCM problem seems the one relevant to your builds getting stuck. > This is coming from the bazaar SCM provider that it doesn't understand > the output line "tags: V37_0_0". > > It shouldn't block it though, so I'm not sure. Do the logs state what > bzr command is being run? > > - Brett > > > |
|
|
download access to apache-continuum-1.3.2.war ?
by Martin Sudmann
::
Rate this Message:
Could someone give me access to a continuum .war file of version 1.3.2 or
1.3.3 ? As the 1.3.4 really doesn't work for me, I'd like to try an older 1.3.x version. Thanks, Martin -----Message d'origine----- De : Martin Sudmann [mailto:martin.sudmann@...] Envoyé : lundi 28 septembre 2009 14:23 À : users@... Objet : RE: Current prepare build queue never emptied This happens also to freshly created projects. I think that the first project after installation passed 3 times, using the DEFAULT_SCHEDULE with the default build queue. Then I added 3 more build queues and clicked on the build button for 2 projects rapidly one after the other; the first one got stuck like I described in "current prepare build queue" and blocked the second in "prepare build queue". I could delete the second one, but no way to get rid of the first one in the "current" queue. By the way, I have created the Jira http://jira.codehaus.org/browse/CONTINUUM-2369. Do you know where I can get a 1.3.3 or 1.3.2 war file from the download site in order to test if this pb is specific to the new version? My old war file got corrupted. Thanks, Martin -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : lundi 28 septembre 2009 01:20 À : users@... Objet : Re: Current prepare build queue never emptied Does this happen on freshly created projects as well, or is only projects in a certain state? Do you have projects using other SCMs? - Brett On 24/09/2009, at 5:59 PM, Martin Sudmann wrote: > The Bazaar commands are the following, the "tags" output comes from > the > command "bzr log --verbose". But nothing has changed in our Bazaar > configuration and the output of that command has always been like > that. > When I restart tomcat, the queue is emptied, though the build button > on the > project line on the project group page still shows "cancel build". > When I try another build, it instantly gets stuck with the same log > entries > as before. > > > 2009-09-24 07:30:00,062 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr pull > 2009-09-24 07:30:00,614 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr revno > 2009-09-24 07:30:00,848 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr diff --revision 25547 > 2009-09-24 07:30:03,914 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr log --verbose > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_1 > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_0 > 2009-09-24 07:31:44,008 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V49_0_0 > 2009-09-24 07:32:56,251 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V48_0_0 > 2009-09-24 07:32:56,261 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_1 > 2009-09-24 07:32:56,262 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_0 > 2009-09-24 07:35:06,347 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_1 > 2009-09-24 07:35:06,348 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_1 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V42_0_0 > 2009-09-24 07:35:06,374 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_2 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_1 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_0 > 2009-09-24 07:38:42,451 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_2 > 2009-09-24 07:38:42,452 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_1 > 2009-09-24 07:38:42,453 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_0 > 2009-09-24 07:38:42,476 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > 2009-09-24 07:38:42,479 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_1 > 2009-09-24 07:38:42,481 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_0 > 2009-09-24 07:38:42,490 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V40_0_0 > 2009-09-24 07:38:42,500 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V39_0_0 > 2009-09-24 07:42:17,269 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V38_0_0 > 2009-09-24 07:42:17,271 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V37_0_0 > 2009-09-24 07:42:17,285 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V36_0_0 > 2009-09-24 07:42:17,288 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V35_0_0 > 2009-09-24 07:42:17,294 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V34_0_0 > 2009-09-24 07:42:17,296 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V33_0_0 > 2009-09-24 07:42:17,299 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_1 > 2009-09-24 07:42:17,300 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_0 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_3 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_2 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_1 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_0 > 2009-09-24 07:45:54,142 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V30_0_0 > 2009-09-24 07:45:54,143 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > : > > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : jeudi 24 septembre 2009 01:34 > À : users@... > Objet : Re: Current prepare build queue never emptied > > On 23/09/2009, at 7:57 PM, Martin Sudmann wrote: > >> >> 2009-09-23 11:49:11,014 [http-9090-2] WARN >> org.apache.struts2.components.Form - No configuration found for the >> specified action: 'none' in namespace: ''. Form action defaulting to >> 'action' attribute's literal value. > > This could be a bug in the page that you should report, but I don't > think it's the cause of the problem > >> I also get a lot of SCM warnings (don't know if this is related >> though): >> >> 2009-09-23 11:40:53,695 [Thread-30] WARN >> org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure >> out of: >> tags: V37_0_0 > > The SCM problem seems the one relevant to your builds getting stuck. > This is coming from the bazaar SCM provider that it doesn't understand > the output line "tags: V37_0_0". > > It shouldn't block it though, so I'm not sure. Do the logs state what > bzr command is being run? > > - Brett > > > |
|
|
Re: download access to apache-continuum-1.3.2.war ?
by brettporter
::
Rate this Message:
On 02/10/2009, at 10:08 PM, Martin Sudmann wrote: > Could someone give me access to a continuum .war file of version > 1.3.2 or > 1.3.3 ? > As the 1.3.4 really doesn't work for me, I'd like to try an older > 1.3.x > version. http://archive.apache.org/dist/continuum/binaries/ Cheers, Brett |
|
|
RE: download access to apache-continuum-1.3.2.war ?
by Martin Sudmann
::
Rate this Message:
Thanks Brett!
Because the Continuum website points to a Maven archive, where the most recent version is 1.1 :) Martin -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : mardi 6 octobre 2009 02:46 À : users@... Objet : Re: download access to apache-continuum-1.3.2.war ? On 02/10/2009, at 10:08 PM, Martin Sudmann wrote: > Could someone give me access to a continuum .war file of version > 1.3.2 or > 1.3.3 ? > As the 1.3.4 really doesn't work for me, I'd like to try an older > 1.3.x > version. http://archive.apache.org/dist/continuum/binaries/ Cheers, Brett |
|
|
Re: download access to apache-continuum-1.3.2.war ?
by brettporter
::
Rate this Message:
Thanks, I'll fix that.
On 08/10/2009, at 6:38 PM, Martin Sudmann wrote: > Thanks Brett! > > Because the Continuum website points to a Maven archive, where the > most > recent version is 1.1 :) > > Martin > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : mardi 6 octobre 2009 02:46 > À : users@... > Objet : Re: download access to apache-continuum-1.3.2.war ? > > > > On 02/10/2009, at 10:08 PM, Martin Sudmann wrote: > >> Could someone give me access to a continuum .war file of version >> 1.3.2 or >> 1.3.3 ? >> As the 1.3.4 really doesn't work for me, I'd like to try an older >> 1.3.x >> version. > > http://archive.apache.org/dist/continuum/binaries/ > > Cheers, > Brett > |
|
|
RE: Current prepare build queue never emptied
by Martin Sudmann
::
Rate this Message:
Hi,
I have the problem of the build queue that is never emptied and thus blocks the whole queue also with older versions of continuum, not only with 1.3.4. Because of the scm errors related to the Bazaar command bzr log --verbose, I think that the problem might be due to our version of Bazaar, which is 1.14.1. Which Bazaar version is supported by Continuum? I didn't find anything in the documentation. Thanks, Martin -----Message d'origine----- De : Martin Sudmann [mailto:martin.sudmann@...] Envoyé : lundi 28 septembre 2009 14:23 À : users@... Objet : RE: Current prepare build queue never emptied This happens also to freshly created projects. I think that the first project after installation passed 3 times, using the DEFAULT_SCHEDULE with the default build queue. Then I added 3 more build queues and clicked on the build button for 2 projects rapidly one after the other; the first one got stuck like I described in "current prepare build queue" and blocked the second in "prepare build queue". I could delete the second one, but no way to get rid of the first one in the "current" queue. By the way, I have created the Jira http://jira.codehaus.org/browse/CONTINUUM-2369. Do you know where I can get a 1.3.3 or 1.3.2 war file from the download site in order to test if this pb is specific to the new version? My old war file got corrupted. Thanks, Martin -----Message d'origine----- De : Brett Porter [mailto:brett@...] De la part de Brett Porter Envoyé : lundi 28 septembre 2009 01:20 À : users@... Objet : Re: Current prepare build queue never emptied Does this happen on freshly created projects as well, or is only projects in a certain state? Do you have projects using other SCMs? - Brett On 24/09/2009, at 5:59 PM, Martin Sudmann wrote: > The Bazaar commands are the following, the "tags" output comes from > the > command "bzr log --verbose". But nothing has changed in our Bazaar > configuration and the output of that command has always been like > that. > When I restart tomcat, the queue is emptied, though the build button > on the > project line on the project group page still shows "cancel build". > When I try another build, it instantly gets stuck with the same log > entries > as before. > > > 2009-09-24 07:30:00,062 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr pull > 2009-09-24 07:30:00,614 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr revno > 2009-09-24 07:30:00,848 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr diff --revision 25547 > 2009-09-24 07:30:03,914 [pool-7-thread-1] INFO > org.apache.continuum.scm.manager.Slf4jScmLogger - EXECUTING: /bin/ > sh -c cd > /users/integ.continue/apache-tomcat-6.0.18/webapps/con > tinuum/data/working-directory/7 && bzr log --verbose > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_1 > 2009-09-24 07:30:39,339 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V50_0_0 > 2009-09-24 07:31:44,008 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V49_0_0 > 2009-09-24 07:32:56,251 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V48_0_0 > 2009-09-24 07:32:56,261 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_1 > 2009-09-24 07:32:56,262 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V47_0_0 > 2009-09-24 07:35:06,347 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_1 > 2009-09-24 07:35:06,348 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V46_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_1 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V45_0_0 > 2009-09-24 07:35:06,364 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V42_0_0 > 2009-09-24 07:35:06,374 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_2 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_1 > 2009-09-24 07:35:06,376 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V44_0_0 > 2009-09-24 07:38:42,451 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_2 > 2009-09-24 07:38:42,452 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_1 > 2009-09-24 07:38:42,453 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V43_0_0 > 2009-09-24 07:38:42,476 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > 2009-09-24 07:38:42,479 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_1 > 2009-09-24 07:38:42,481 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V41_0_0 > 2009-09-24 07:38:42,490 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V40_0_0 > 2009-09-24 07:38:42,500 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V39_0_0 > 2009-09-24 07:42:17,269 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V38_0_0 > 2009-09-24 07:42:17,271 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V37_0_0 > 2009-09-24 07:42:17,285 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V36_0_0 > 2009-09-24 07:42:17,288 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V35_0_0 > 2009-09-24 07:42:17,294 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V34_0_0 > 2009-09-24 07:42:17,296 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V33_0_0 > 2009-09-24 07:42:17,299 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_1 > 2009-09-24 07:42:17,300 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V32_0_0 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_3 > 2009-09-24 07:42:17,311 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_2 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_1 > 2009-09-24 07:42:17,312 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V31_0_0 > 2009-09-24 07:45:54,142 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > tags: V30_0_0 > 2009-09-24 07:45:54,143 [Thread-79] WARN > org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure > out of: > : > > > -----Message d'origine----- > De : Brett Porter [mailto:brett@...] De la part de Brett > Porter > Envoyé : jeudi 24 septembre 2009 01:34 > À : users@... > Objet : Re: Current prepare build queue never emptied > > On 23/09/2009, at 7:57 PM, Martin Sudmann wrote: > >> >> 2009-09-23 11:49:11,014 [http-9090-2] WARN >> org.apache.struts2.components.Form - No configuration found for the >> specified action: 'none' in namespace: ''. Form action defaulting to >> 'action' attribute's literal value. > > This could be a bug in the page that you should report, but I don't > think it's the cause of the problem > >> I also get a lot of SCM warnings (don't know if this is related >> though): >> >> 2009-09-23 11:40:53,695 [Thread-30] WARN >> org.apache.continuum.scm.manager.Slf4jScmLogger - Could not figure >> out of: >> tags: V37_0_0 > > The SCM problem seems the one relevant to your builds getting stuck. > This is coming from the bazaar SCM provider that it doesn't understand > the output line "tags: V37_0_0". > > It shouldn't block it though, so I'm not sure. Do the logs state what > bzr command is being run? > > - Brett > > > |
| Free embeddable forum powered by Nabble | Forum Help |
