Broadleaf Commerce Discussion Forums

First, my setup:

1. BLC 2.0 M1-6
2. Eclipse workspace (Heat Clinic)
3. Setup a Tomcat server locally (Just downloaded Tomcat, untar'd, set up as server in Eclipse)
4. Switched to MySQL successfully.

When I start up Tomcat, Hibernate seems to recreate the schema entirely from scratch, as if drop-create is set somewhere. No matter what I try I can't prevent Hibernate from recreating the database. This poses two problems: any new changes to my dev data are wiped out, and second it adds a couple minutes to app startup. I tried setting the ddl.auto settings in common-shared.properties to none/null/update, and nothing worked. Am I supposed to do a mvn install to pick those up since the site project depends on core?

Also, when I shut down hibernate, the same schema export happens again, as if it's somehow hooked into the bean lifecycle shutdown hook.

The Hibernate ddl is set to create-drop by default, since the default runtime configuration is set to "develop" (you can also change the environment by passing -Druntime.environment=production or staging to the JVM).

Anyway, the runtime.environment -D argument really controls the properties files to use in the application (if unset, the environment is develop). So you can either change the ddl property to something like "update" or "validate" in develop.properties, or specify a different environment. You can read more about how the properties files work by lookin at the common-shared.properties file in the core project.

Thanks for the reply. I'll give it a shot. When I was skimming the common-shared.properties file I guess I figured it would override all unset properties in the environment-specific props files. When I looked in develop.props there was nothing in there except a comment to check out common-shared. I'll report back on my findings in case others come across the same issue.

The comment in common-shared.properties explains the order of priority in the merge process:

# common-shared.properties (in the core project)
# [specific-environment]-shared.properties (in the core project)
# common.properties (in either site or admin project, depending on which app is starting)
# [specific-environment].properties (in either site or admin project, depending on which app is starting)

If you were running in the development environment, that means that this would be the order:

common-shared
development-shared
common
development

Later files have more priority.

This means that any property set in development would override the same property set in any other environment.

Yup, exactly what my thought was. But here's the trick: My development.properties file is empty except for the comment that explains that the documentation for props file merging is in common-shared. So, shouldn't the value that's in common-shared be the one it takes? And in common-shared, when the ddl.auto value is set to none/null/update, it still does create-drop anyway.

You're correct.

Have you done a maven clean and install after modifying the property file?

Probably not. I'll check that out when I get the chance.

As far as the environment-specific properties files go, have you guys given any thought to using Spring Bean Profiles? Just curious if you tried it out and it didn't work well, or you tried it out and liked it but aren't shipping with it yet.

I think I might know the confusion. There are also properties files in the site and admin projects which will override anything from core. In the site development.properties file the Hibernate ddl is set to create-drop by default.

Ahh yeah, that's probably it. I'll be home in a few hours to try it out. Thanks for clearing that up!

Follow-up: Yup, you guys were spot on. I was editing the properties files in core, not in site. Changing the appropriate entries in site/development.properties solved the issue. Thanks!