Extending BLC domain using a single table strategy fails unexpectedly

[dwtalk]

Sometimes when starting up the application, utilizing a single table strategy, the domain extensions of BLC classes are not recognized, and hibernate attempts to create tables for all classes that have been extended. This causes the application to fail startup, and may alter production schemas.

We have the spring instrumentation java agent loaded to match the 3.2.2 version of spring.

Entities specified as:
<bean id="org.broadleafcommerce.core.catalog.domain.Category" class="com.someone.ecommerce.domain.EXTCategoryImpl" scope="prototype" />

@entity
@batchsize(size = 500)
@DiscriminatorValue("EXT")
@AdminPresentationClass(friendlyName = "EXT Category")
@AdminPresentationMergeOverrides({
@AdminPresentationMergeOverride(name = "displayTemplate", mergeEntries = {
@AdminPresentationMergeEntry(propertyType = PropertyType.AdminPresentation.FIELDTYPE, overrideValue = "BROADLEAF_ENUMERATION")
})
})
public class EXTCategoryImpl extends CategoryImpl implements EXTCategory {
....

This is what is seen in the logs:

2014-04-21 21:08:24,000 - ERROR (SchemaUpdate.java:235) - HHH000388: Unsuccessful: create table EXTCategoryImpl (CATEGORY_ID bigint not null, primary key (CATEGORY_ID)) ENGINE=InnoDB
2014-04-21 21:08:24,000 - ERROR (SchemaUpdate.java:236) - CREATE command denied to user 'root'@'localhost' for table 'EXTCategoryImpl'

The application fails to start as the domain is incorrectly loaded and the data cannot be correctly loaded.

We are seeing this randomly in all environments, and cannot reproduce on a regular basis. I can provide a full startup log of when it does occur in development. It may be coincidental but appears to occur more often under system duress and when using tomcat 8 vs tomcat 7.

This problem is usually resolved by restarting tomcat once or twice.

[phillipuniverse]

First red flag I see: as far as I know we haven't done a full investigation of BLC on Tomcat 8. It would be a little weird if this was caused by Tomcat though.

That said, I assume you have a JNDI resource declared at the Tomcat level? In that case maybe Tomcat 8 does connection pooling differently than in Tomcat 7. It's peculiar that you get essentially access denied.

[dwtalk]

The access denied is just because the user does not have the privileges to create the improper tables in development.

As far as tomcat 8 goes, I just noticed it in development.

In our stage/qa/prod environments, we utilize tomcat 7 and see the same tables created due to this process with create table permisssion.

[jefffischer]

The thing for Broadleaf to investigate is whether or not there's a possibility for the Classloader to load classes (i.e. domain classes) before the single table class transformer is enacted in the entity manager factory.

[jefffischer]

Here's an approach for Broadleaf to likely solve this:

1. Test to confirm that loading an entity before the entity manager factory causes the class transformer to be skipped (e.g. add a bean in spring xml whose class is ProductImpl and loads before EMF)
2. Add a new marker class-level annotation via class transformer to loaded entities. This annotation doesn't do anything - just marks entities that have been transformed.
3. In MergePersistenceUnitManager, there should be a place to iterate through the entity classes after they have been transformed (presumably). Check the classes for the presence of the marker annotation. If it's not there, cause the classloader to reload the class, or refresh the transformation in some other way.

[apazzolini]

• Confirm that if a class is loaded before the EntityManagerFactory, transformations do not happen
• Create a new class transformer that marks all class with @Entity as transformed
• In the MergePersistenceUnitManager, if there is an entity class that does not have the marker, forcefully reload the class through the ClassLoader, ensuring transformations take place.

[apazzolini]

I believe that this issue was related to having the spring-instrument JAR inside the WAR (or in the Tomcat lib directory - basically anywhere in the classpath).

This JAR should live outside of the classpath and be referenced by the -javaagent JVM argument only.

A note about this has been made at http://www.broadleafcommerce.com/docs/core/current/appendix/load-time-weaving