Bug 793916 (JBEPP-987) - EPP 5.1.1.DEV02 fails to start against existing DB schema
Summary: EPP 5.1.1.DEV02 fails to start against existing DB schema
Keywords:
Status: CLOSED NEXTRELEASE
Alias: JBEPP-987
Product: JBoss Enterprise Portal Platform 5
Classification: JBoss
Component: Portal
Version: 5.1.1.DEV02,5.1.1.CR01
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 5.1.1.DEV03,5.1.1.GA
Assignee: hfnukal@redhat.com
QA Contact:
URL: http://jira.jboss.org/jira/browse/JBE...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-22 14:47 UTC by Martin Weiler
Modified: 2011-08-05 02:33 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-02 05:57:12 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBEPP-987 0 None None None Never
Red Hat Issue Tracker JBQA-4899 0 None None None Never

Description Martin Weiler 2011-06-22 14:47:09 UTC
Steps to Reproduce: - Configure EPP 5.1.0 to use a DB other than Hypersonic (eg. MySQL)
- Start EPP 5.1.0, shutdown
- Use the same DB settings for EPP 5.1.1
- Start EPP 5.1.1 -> ERROR
Workaround Description: Workaround is to manually delete the entries in the JCR_CONFIG table.
project_key: JBEPP

Starting EPP 5.1.1.DEV02 against a DB schema created by EPP 5.1.0 is resulting in the following ERRORs during startup:

ERROR [exo.jcr.component.core.RepositoryServiceImpl] (main) Error start repository service
org.exoplatform.services.jcr.config.RepositoryConfigurationException: java.io.IOException: Can't find or open file:classpath:/conf/jcr/jbosscache/local/config.xml
	at org.exoplatform.services.jcr.impl.RepositoryContainer.registerWorkspace(RepositoryContainer.java:374)
	at org.exoplatform.services.jcr.impl.RepositoryContainer.registerWorkspacesComponents(RepositoryContainer.java:549)
	at org.exoplatform.services.jcr.impl.RepositoryContainer.registerComponents(RepositoryContainer.java:491)
	at org.exoplatform.services.jcr.impl.RepositoryContainer.<init>(RepositoryContainer.java:132)
	at org.exoplatform.services.jcr.impl.RepositoryServiceImpl.createRepository(RepositoryServiceImpl.java:151)
	at org.exoplatform.services.jcr.impl.RepositoryServiceImpl.init(RepositoryServiceImpl.java:360)
	at org.exoplatform.services.jcr.impl.RepositoryServiceImpl.start(RepositoryServiceImpl.java:275)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.picocontainer.defaults.LifecycleVisitor.traverse(LifecycleVisitor.java:75)
	at org.picocontainer.defaults.LifecycleVisitor.start(LifecycleVisitor.java:113)
	at org.exoplatform.container.ConcurrentPicoContainer.start(ConcurrentPicoContainer.java:464)
	at org.exoplatform.container.ExoContainer.start(ExoContainer.java:186)
	at org.exoplatform.container.PortalContainer.start(PortalContainer.java:620)
	at org.exoplatform.container.ExoContainer.start(ExoContainer.java:180)
	at org.exoplatform.container.RootContainer.createPortalContainer(RootContainer.java:357)
	at org.exoplatform.container.RootContainer.registerPortalContainer(RootContainer.java:228)
	at org.exoplatform.portal.application.PortalController.afterInit(PortalController.java:114)
	at org.exoplatform.container.web.AbstractHttpServlet.init(AbstractHttpServlet.java:79)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:950)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4122)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4417)
	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321)
	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:145)
	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:122)
	at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
	at $Proxy38.start(Unknown Source)
	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1652)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:938)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:988)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:826)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:556)
	at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
	at org.jboss.system.ServiceController.start(ServiceController.java:460)
	at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1454)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1172)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1193)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1225)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1113)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1652)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:938)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:988)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:826)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:556)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:789)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:699)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1652)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:938)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:988)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:778)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:543)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.RuntimeException: Cannot instantiate component class org.exoplatform.services.jcr.impl.dataflow.persistent.LocalWorkspaceDataManagerStub
	at org.exoplatform.container.jmx.MX4JComponentAdapter.getComponentInstance(MX4JComponentAdapter.java:131)
	at org.exoplatform.container.management.ManageableComponentAdapter.getComponentInstance(ManageableComponentAdapter.java:68)
	at org.exoplatform.container.ConcurrentPicoContainer.getInstance(ConcurrentPicoContainer.java:400)
	at org.exoplatform.container.ConcurrentPicoContainer.getComponentInstanceOfType(ConcurrentPicoContainer.java:389)
	at org.exoplatform.container.CachingContainer.getComponentInstanceOfType(CachingContainer.java:139)
	at org.exoplatform.services.jcr.impl.RepositoryContainer.registerWorkspace(RepositoryContainer.java:344)
	... 92 more
Caused by: java.lang.RuntimeException: Cannot instantiate component class org.exoplatform.services.jcr.impl.dataflow.persistent.CacheableWorkspaceDataManager
	at org.exoplatform.container.jmx.MX4JComponentAdapter.getComponentInstance(MX4JComponentAdapter.java:131)
	at org.exoplatform.container.management.ManageableComponentAdapter.getComponentInstance(ManageableComponentAdapter.java:68)
	at org.exoplatform.container.ConcurrentPicoContainer.getInstance(ConcurrentPicoContainer.java:400)
	at org.exoplatform.container.ConcurrentPicoContainer.getComponentInstanceOfType(ConcurrentPicoContainer.java:389)
	at org.exoplatform.container.CachingContainer.getComponentInstanceOfType(CachingContainer.java:139)
	at org.exoplatform.container.ExoContainer.createComponent(ExoContainer.java:311)
	at org.exoplatform.container.jmx.MX4JComponentAdapter.getComponentInstance(MX4JComponentAdapter.java:94)
	... 97 more
Caused by: java.lang.RuntimeException: Cannot instantiate component class org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.JBossCacheWorkspaceStorageCache
	at org.exoplatform.container.jmx.MX4JComponentAdapter.getComponentInstance(MX4JComponentAdapter.java:131)
	at org.exoplatform.container.management.ManageableComponentAdapter.getComponentInstance(ManageableComponentAdapter.java:68)
	at org.exoplatform.container.ConcurrentPicoContainer.getInstance(ConcurrentPicoContainer.java:400)
	at org.exoplatform.container.ConcurrentPicoContainer.getComponentInstanceOfType(ConcurrentPicoContainer.java:389)
	at org.exoplatform.container.CachingContainer.getComponentInstanceOfType(CachingContainer.java:139)
	at org.exoplatform.container.ExoContainer.createComponent(ExoContainer.java:311)
	at org.exoplatform.container.jmx.MX4JComponentAdapter.getComponentInstance(MX4JComponentAdapter.java:94)
	... 103 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
	at org.exoplatform.container.ExoContainer.createComponent(ExoContainer.java:321)
	at org.exoplatform.container.jmx.MX4JComponentAdapter.getComponentInstance(MX4JComponentAdapter.java:94)
	... 109 more
Caused by: org.exoplatform.services.jcr.config.RepositoryConfigurationException: java.io.IOException: Can't find or open file:classpath:/conf/jcr/jbosscache/local/config.xml
	at org.exoplatform.services.jcr.jbosscache.ExoJBossCacheFactory.createCache(ExoJBossCacheFactory.java:129)
	at org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.JBossCacheWorkspaceStorageCache.<init>(JBossCacheWorkspaceStorageCache.java:292)
	... 115 more
Caused by: java.io.IOException: Can't find or open file:classpath:/conf/jcr/jbosscache/local/config.xml
	at org.exoplatform.services.jcr.config.TemplateConfigurationHelper.fillTemplate(TemplateConfigurationHelper.java:173)
	at org.exoplatform.services.jcr.config.TemplateConfigurationHelper.fillTemplate(TemplateConfigurationHelper.java:213)
	at org.exoplatform.services.jcr.jbosscache.ExoJBossCacheFactory.createCache(ExoJBossCacheFactory.java:125)
	... 116 more

Comment 1 Thomas Heute 2011-06-22 14:56:24 UTC
Good catch... The infamous JCR_CONFIG

We have 2 choices:
- Duplicate the file so that it woks for new and existing solutions
- Document the workaround

I would be tempted to duplicate and add a comment in the one embedded in the jar

Comment 2 hfnukal@redhat.com 2011-07-07 13:25:14 UTC
What about make update script for DB, it can search for wrong records and replace it.

Comment 3 Thomas Heute 2011-07-07 13:34:29 UTC
Patch upgrade should be as easy as possible (binary replacement).
Unless *absolute* need.

Comment 4 Michal Vanco 2011-07-28 10:23:45 UTC
Link: Added: This issue relates to JBQA-4899


Comment 5 hfnukal@redhat.com 2011-08-04 03:55:01 UTC
Release Notes Text: Added: JCR cache configuration was moved from jar file to folder in web to be editable. When upgrading form previous version of EPP, path to config is stored in database in JCR_CONFIG table. For backward compatibility, to avoid changing database, configuration files are duplicated in jar. If config changes in JCR cache are needed, its important to update or delete JCR_CONFIG table to use "war:" prefix instead of "classpath:".


Comment 6 Scott Mumford 2011-08-04 04:46:42 UTC
Release Notes Text: Removed: JCR cache configuration was moved from jar file to folder in web to be editable. When upgrading form previous version of EPP, path to config is stored in database in JCR_CONFIG table. For backward compatibility, to avoid changing database, configuration files are duplicated in jar. If config changes in JCR cache are needed, its important to update or delete JCR_CONFIG table to use "war:" prefix instead of "classpath:". Added: ORIGINAL TEXT:
JCR cache configuration was moved from jar file to folder in web to be editable. When upgrading form previous version of EPP, path to config is stored in database in JCR_CONFIG table. For backward compatibility, to avoid changing database, configuration files are duplicated in jar. If config changes in JCR cache are needed, its important to update or delete JCR_CONFIG table to use "war:" prefix instead of "classpath:".

UPDATED TEXT:
The JCR cache configuration files in JBoss Enterprise Portal Platform 5.1.1 have been moved from the /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/lib/exo.jcr.component.core-VERSION.jar to  /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr.

This change prevented upgraded versions of JBoss Enterprise Portal Platform from starting with the path to the old JCR configuration files stored in the database JCR_CONFIG table.

This issue has been resolved by retaining duplicates of the configuration files in the original jar. This corrects the issue and ensures backward compatibility, without the need to change the database.

Note:
As a result of this change, if configuration changes to the JCR cache are required, it is important that the JCR_CONFIG table be updated to use  the "war:" prefix instead of "classpath:" (for example; file:war:/conf/jcr/jbosscache/local/config.xml).


Comment 7 Scott Mumford 2011-08-05 00:44:45 UTC
Updated file name in Release Note text as per advice from Honza

Comment 8 Scott Mumford 2011-08-05 00:44:45 UTC
Release Notes Text: Removed: ORIGINAL TEXT:
JCR cache configuration was moved from jar file to folder in web to be editable. When upgrading form previous version of EPP, path to config is stored in database in JCR_CONFIG table. For backward compatibility, to avoid changing database, configuration files are duplicated in jar. If config changes in JCR cache are needed, its important to update or delete JCR_CONFIG table to use "war:" prefix instead of "classpath:".

UPDATED TEXT:
The JCR cache configuration files in JBoss Enterprise Portal Platform 5.1.1 have been moved from the /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/lib/exo.jcr.component.core-VERSION.jar to  /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr.

This change prevented upgraded versions of JBoss Enterprise Portal Platform from starting with the path to the old JCR configuration files stored in the database JCR_CONFIG table.

This issue has been resolved by retaining duplicates of the configuration files in the original jar. This corrects the issue and ensures backward compatibility, without the need to change the database.

Note:
As a result of this change, if configuration changes to the JCR cache are required, it is important that the JCR_CONFIG table be updated to use  the "war:" prefix instead of "classpath:" (for example; file:war:/conf/jcr/jbosscache/local/config.xml). Added: The JCR cache configuration files in JBoss Enterprise Portal Platform 5.1.1 have been moved from the /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/lib/exo.portal.component.common-<version>.jar to  /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr.

This change prevented upgraded versions of JBoss Enterprise Portal Platform from starting with the path to the old JCR configuration files stored in the database JCR_CONFIG table.

This issue has been resolved by retaining duplicates of the configuration files in the original jar. This corrects the issue and ensures backward compatibility, without the need to change the database.

Note:
As a result of this change, if configuration changes to the JCR cache are required, it is important that the JCR_CONFIG table be updated to use  the "war:" prefix instead of "classpath:" (for example; file:war:/conf/jcr/jbosscache/local/config.xml).


Comment 9 Scott Mumford 2011-08-05 02:33:42 UTC
Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Resolved Issue
Release Notes Text: Removed: The JCR cache configuration files in JBoss Enterprise Portal Platform 5.1.1 have been moved from the /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/lib/exo.portal.component.common-<version>.jar to  /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/02portal.war/WEB-INF/conf/jcr.

This change prevented upgraded versions of JBoss Enterprise Portal Platform from starting with the path to the old JCR configuration files stored in the database JCR_CONFIG table.

This issue has been resolved by retaining duplicates of the configuration files in the original jar. This corrects the issue and ensures backward compatibility, without the need to change the database.

Note:
As a result of this change, if configuration changes to the JCR cache are required, it is important that the JCR_CONFIG table be updated to use  the "war:" prefix instead of "classpath:" (for example; file:war:/conf/jcr/jbosscache/local/config.xml). Added: The JCR cache configuration files in JBoss Enterprise Portal Platform 5.1.1 have been moved from the /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/lib/exo.portal.component.common-<version>.jar to  /JBOSS_HOME/server/PROFILE/deploy/gatein.ear/02portal.war/WEB-INF/conf/.

This change created problems when attempting to start upgraded versions of JBoss Enterprise Portal Platform that had the original file path stored in the JCR_CONFIG table in the database. To resolve the issue, duplicates of the configuration files have been retained in the original location. This also ensures backward compatibility, without the need to change the database.

Note:
After this change, if configuration changes to the JCR cache are required, it is important that the JCR_CONFIG table be updated to use the "war:" prefix instead of "classpath:" (for example; file:war:/conf/jcr/jbosscache/local/config.xml).



Note You need to log in before you can comment on or make changes to this bug.