Issue Details (XML | Word | Printable)

Key: NUCACCESS-89
Type: Bug Bug
Status: Closed Closed
Resolution: Incomplete
Priority: Testcase Required Testcase Required
Assignee: Unassigned
Reporter: Hanh Le
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus AccessPlatform

JDOPersistenceManagerFactory fails to load in-memory classes upon metadata registration

Created: 04/May/11 10:42 PM   Updated: 21/Nov/13 11:10 AM   Resolved: 18/Nov/13 05:23 PM
Component/s: Software
Affects Version/s: 3.0.0.m2
Fix Version/s: None


 Description  « Hide
JDOPersistenceManagerFactory provides a way to specify primary class loader via setPrimaryClassLoader but it's not being passed in to org.datanucleus.metadata.MetaDataManager to resolve in-memory classes. Therefore, result in

org.datanucleus.metadata.InvalidMetaDataException: Class {className} has MetaData yet the class cant be found. Please check your CLASSPATH specifications.
org.datanucleus.metadata.AbstractClassMetaData.loadClass(AbstractClassMetaData.java:562)
org.datanucleus.metadata.ClassMetaData.populate(ClassMetaData.java:166)
org.datanucleus.metadata.MetaDataManager$1.run(MetaDataManager.java:2495)
java.security.AccessController.doPrivileged(Native Method)
org.datanucleus.metadata.MetaDataManager.populateAbstractClassMetaData(MetaDataManager.java:2489)
org.datanucleus.metadata.MetaDataManager.populateFileMetaData(MetaDataManager.java:2316)
org.datanucleus.metadata.MetaDataManager.initialiseFileMetaDataForUse(MetaDataManager.java:965)
org.datanucleus.metadata.MetaDataManager.loadUserMetaData(MetaDataManager.java:931)
org.datanucleus.api.jdo.JDOPersistenceManagerFactory.registerMetadata(JDOPersistenceManagerFactory.java:2084)

Should line 2084 of JDOPersistenceManagerFactory be
    mmgr.loadUserMetaData(filemd, getPrimaryClassLoader())
instead of
    mmgr.loadUserMetaData(filemd, null)


Sort Order: Ascending order - Click to sort in descending order
Hanh Le added a comment - 05/May/11 04:03 AM
... further testing I also found that the code block to check for metadata already defined in JDOPersistenceManagerFactory.registerMetadata method is really not necessary and throwing exception in there prevents metadata to dynamically adjust to reflect change(s) in underline schema, e.g. adding/dropping/mapping/unmapping a column. The method can be as simple as

public void registerMetadata(javax.jdo.metadata.JDOMetadata metadata)
{
    MetaDataManager mmgr = nucleusContext.getMetaDataManager();
    FileMetaData filemd = ((JDOMetadataImpl)metadata).getInternal();
    mmgr.loadUserMetaData(filemd, getPrimaryClassLoader());
}

in my opinion.

Andy Jefferson added a comment - 05/May/11 07:37 AM
As per all docs, any issue has to have a valid testcase.

We have testcases for in-memory classes (with in-memory metadata, using the metadata API) and they work. That is the only supported (and sensible) metadata route for that case.


Hanh Le added a comment - 05/May/11 03:47 PM
Hello Andy,

First off, thanks for your quick response. I'm aware of your dynamic class generation test. The test works because everything (generate, enhance, register metadata, create schema, persist) is done in one thread execution and autoCreateSchema, autoCreateTables, autoCreateColumns are all enabled. It doesn't work when generate, enhance, register are done in one thread execution, persist in another, and all the above autoCreates are set to false.

Andy Jefferson added a comment - 18/Nov/13 05:23 PM
No testcase provided, and not a use case I have, so nothing to do. Clearly if people see this as important to them they could a). create a testcase that people can run, and b). get involved in the project and contribute updates to whatever they are seeing