[
https://issues.apache.org/jira/browse/RAVE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated RAVE-382:
---------------------------
Description:
Currently both rave-shindig and rave-portal seed the person (and related) data
during initialization.
As these data sets overlap (erroneously) and the the initialization order of
these two web applications isn't guaranteed, this can cause an initialization
failure (duplicate key error) at startup.
If this happens, a temporary workaround for the 0.6-incubating release binary
*demo* is:
1) first make sure to remove the (broken) rave database, like with: $ rm
/tmp/rave_db.h2.db
2) before first start of tomcat after extracting the binary demo, temporarily
move the webapps/ROOT.war file outside the webapps folder so it won't get
deployed
3) now start tomcat for the first time, and once fully started stop it
immediately again (don't try to access the portal yet)
4) move or copy back the ROOT.war back into the webapps folder
5) now tomcat can be started normally and be used for the demo
6) whenever you want to 'reset' the database again, rewind back to step 1)
The proper solution for this problem is consolidating and moving all person
data (and for related objects as groups and their associations) from
rave-shindig initial_data.sql to the rave-portal (resources) initial_data.sql
This also is needed (manually) if you want to build and run Rave from source,
including for the 0.6-incubating release/tag, when using the cargo:start
procedure as that automatically managed the deployment of the wars (above
manual steps cannot be performed then).
I'll create a patch for this change to be applied to the trunk, but which also
can be applied when using the 0.6-incubating release/tag sources.
Priority: Blocker (was: Major)
Affects Version/s: 0.6-INCUBATING
Fix Version/s: (was: 0.6-INCUBATING)
0.7-INCUBATING
Assignee: Ate Douma
> Consolidate and move all person data initialization to be done by rave-portal
> -----------------------------------------------------------------------------
>
> Key: RAVE-382
> URL: https://issues.apache.org/jira/browse/RAVE-382
> Project: Rave
> Issue Type: Sub-task
> Components: rave-core, rave-portal, rave-shindig
> Affects Versions: 0.6-INCUBATING
> Reporter: Ate Douma
> Assignee: Ate Douma
> Priority: Blocker
> Fix For: 0.7-INCUBATING
>
>
> Currently both rave-shindig and rave-portal seed the person (and related)
> data during initialization.
> As these data sets overlap (erroneously) and the the initialization order of
> these two web applications isn't guaranteed, this can cause an initialization
> failure (duplicate key error) at startup.
> If this happens, a temporary workaround for the 0.6-incubating release binary
> *demo* is:
> 1) first make sure to remove the (broken) rave database, like with: $ rm
> /tmp/rave_db.h2.db
> 2) before first start of tomcat after extracting the binary demo, temporarily
> move the webapps/ROOT.war file outside the webapps folder so it won't get
> deployed
> 3) now start tomcat for the first time, and once fully started stop it
> immediately again (don't try to access the portal yet)
> 4) move or copy back the ROOT.war back into the webapps folder
> 5) now tomcat can be started normally and be used for the demo
> 6) whenever you want to 'reset' the database again, rewind back to step 1)
> The proper solution for this problem is consolidating and moving all person
> data (and for related objects as groups and their associations) from
> rave-shindig initial_data.sql to the rave-portal (resources) initial_data.sql
> This also is needed (manually) if you want to build and run Rave from source,
> including for the 0.6-incubating release/tag, when using the cargo:start
> procedure as that automatically managed the deployment of the wars (above
> manual steps cannot be performed then).
> I'll create a patch for this change to be applied to the trunk, but which
> also can be applied when using the 0.6-incubating release/tag sources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
