See About JavaBeans for background details. Each jar file ships with a mapping file used by the newInstance method to return an instance of a Bean based on a given type or a given id. The newInstance method found in DomainObject is used for serving up instances of Beans derived from DomainObject based on a business type or an object id. The newInstance method found in DomainRelationship is used for serving up instances of Beans derived from DomainRelationship based on a relationship type or a rel id. The mapping file naming convention uses an emx prefix and a MappingFile.properties suffix. In between is the name of the application or the word "Common". For example, the mapping file found in the engineering.jar file is named: emxEngineeringMappingFile.properties The mapping file found in the common.jar file is named: emxCommonMappingFile.properties The newInstance methods (found in both DomainObject and DomainRelationship) use these mapping files to serve up a new object instance of the appropriate class. The methods take an additional string argument that specifies the application name. This is used to find the application-specific version of a common components class. The search algorithm of the newInstance method guarantees the application-specific class is returned. The system first looks for the given type and then moves up the type hierarchy defined in the schema until a match is found. If no such class is found, the system continues to look for the given type in common components and then moves up the type hierarchy defined in the schema until a match is found. If no such class is found, the appropriate base class (DomainObject or DomainRelationship) is returned. The Bean lookup method also includes a way for one or more Beans to be found before all other Beans when using the newInstance() method. This is a requirement for integrations to ensure that their Beans will always be found first. The mappings are included in an external file that can be managed independently of the ENOVIA products. A property in emxSystem.properties lists the external mapping files that should be looked at first. The emxFramework.BeanMapping.PreliminarySearchFiles property can be used to list one or more mapping files that will be searched before falling back on the standard search algorithm, which looks at the mapping files associated with the Bean packages shipped with the ENOVIA products. The order in which the mapping files are given is important. If you want a mapping file searched first, then it must be listed first. In the example below, customMappingFile.properties will always be searched first. Then emxIntegrationsBeanMappingFile.properties will be searched. Finally, if no entry is found, the standard search will take place across the mapping files shipped with the applications. By default, the property is set to emxIntegrationsBeanMappingFile.properties. emxFramework.BeanMapping.PreliminarySearchFiles = customMappingFile.properties,emxIntegrationsBeanMappingFile.properties This hard override, finding the appropriate Bean for a given type using newInstance(), blocks the standard search algorithm which begins in the mapping file of the given application and then moves on to the common mapping file to find a matching entry. It is important to understand that an entry placed in the mapping file associated with the emxFramework.BeanMapping.PreliminarySearchFiles property will override all Beans for a given type. For example, if the following mapping files all had an entry for type Part as shown below... customMappingFile.properties -------> type_Part= com.matrixone.apps.custom.CustomPart emxIntegrationsBeanMappingFile.properties -----> type_Part= com.matrixone.apps.integrations.IntegrationsPart emxEngineeringMappingFile.properties -----> type_Part= com.matrixone.apps.engineering.Part emxCommonMappingFile.properties -----> type_Part= com.matrixone.apps.common.Part ...then the newInstance() method would always return com.matrixone.apps.custom.CustomPart, even when called with a third argument set to engineering. | |||||||