Hide Forgot
Affects: Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration project_key: SOA The schema tool that facilitates switching databases for SOA-P components should also support ModeShape. ModeShape can store its content in various RDBMSs - the same as supported by SOA-P. However, since ModeShape is optional - it will only be present when a user purchases EDS, not just the base SOA platform, the tool should first determine if MS is present before performing any configuration.
Parent: Added: SOA-2271
This needs more consideration. In summary, the schema script changes the database for all the components that use a database, and it makes them all use the same database. However, this is too restrictive for ModeShape, which will normally use multiple data sources. Also, some ModeShape data sources (non-database ones) make no sense for the other components.
ModeShape will likely be configured in SOA-P to have a single repository that uses a single database. That will be sufficient out-of-the-box; changes can be made to that by customers if needed, but more likely they will leave the configuration for that repository alone (and maybe add other repositories). So the tool could definitely manipulate the specific fragment in the ModeShape configuration file that corresponds to this out-of-the-box repository source. The question is whether the ModeShape repository content should be stored in the same database with other data. (I don't know what that other data entails, so it certainly might make sense.) All of the tables in the ModeShape schema should start with "MODE_" or "DNA_" (for legacy reasons), but I'm not sure whether our index names use a prefix. Hopefully there won't be a name conflict with other tables in the shared database. ModeShape does come with an executable JAR that will generate the DDL script for a particular database, if that's required or useful. (See http://docs.jboss.org/modeshape/latest/manuals/reference/html_single/reference-guide-en.html#jdbc-storage-connector for details.)
To use the schema tool to update modeshape repository appears to be complex, because the modeshape config file can be updated by users (adding other repositories) and therefore a template can't be used to replace the database properties (as is done with the others). We could build a complex UI so the user can choose what to replace (the most flexible) or use the schema tool to only replace the config when only 1 repository is defined. If more then one exist, then alternative (manual) measures must be taken by the user.
Parent: Removed: SOA-2271
Link: Added: This issue is duplicated by SOA-2398
First step is to change the DB schema templates to have a substitution variable: @JNIDNAME@ that will be substituted for when tool is run. Doing this will allow modeshape to reuse the templates to create its -ds.xml file that have its defined JNDI name.
Committed changes so that the modeshape-eds-store-ds.xml will be replaced with new settings that were applied to the template.
Changes were applied to the soa build project and should be in the ER5 release.
DataSource is reconfigured but modeshape-config.xml file still contains incorrect dialect configuration - like mode:dialect="org.hibernate.dialect.HSQLDialect
This could be problematic, because the config file can't templetized because we can't be sure what the user has already changed. They now could have multiple sources that use HSQLDialect. Do we, by default, change all occurrences? Maybe, when the db schema tool is run, and modeshape is determined to be deployed, we add a prompt telling the user that they will need to update the config file with this "DIALECT". Suggestions?
I'd say modify the file in that way that only dialect for eds-store JpaSource is modified, rest is untouched.
Added logic to replace the dialect for the eds-store in the modeshape-config.xml
The db schema-tool has be fixed to update the appropriate files (i.e., config file and -ds.xml) so that all references are updated accordingly.