[
https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514240
]
Frank Budinsky commented on TUSCANY-1143:
-----------------------------------------
I tracked down two places that the global EMF registry was being used. Fixes
are needed in TypeImpl.getInstanceClassName() and
DataObjectBase.resolveProxy(). Here are my fixed versions of the two methods:
public String getInstanceClassName()
{
if (javaClassFeature == null)
{
//FB TODO figure out what helper to use
javaClassFeature =
(EStructuralFeature)TypeHelper.INSTANCE.getOpenContentProperty("commonj.sdo/java",
"javaClass");
}
Sequence anyAttribute = getAnyAttribute();
int count = anyAttribute.size();
for (int i = 0; i < count; i++)
{
EStructuralFeature eFeature =
(EStructuralFeature)anyAttribute.getProperty(i);
if (eFeature == javaClassFeature)
{
return (String)anyAttribute.getValue(i);
}
}
return null;
}
protected Object resolveProxy(Object proxy)
{
Resource resource = this.eResource();
ResourceSet resourceSet = resource != null ? resource.getResourceSet() :
null;
if (resourceSet != null) return EcoreUtil.resolve((EObject)proxy,
resourceSet);
URI proxyURI = ((InternalEObject)proxy).eProxyURI();
if (proxyURI != null)
{
EPackage ePackage =
HelperContextImpl.getBuiltInModelRegistry().getEPackage(proxyURI.trimFragment().toString());
if (ePackage != null)
{
resource = ePackage.eResource();
if (resource != null)
{
return resource.getEObject(proxyURI.fragment().toString());
}
}
}
> Generated code should separate metadata creation from registration to permit
> proper scoping
> -------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1143
> URL: https://issues.apache.org/jira/browse/TUSCANY-1143
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Tools
> Affects Versions: Java-SDO-beta1
> Reporter: Kelvin Goodson
> Fix For: Java-SDO-1.0
>
> Attachments: 1143.patch, 1143.patch, 1143.patch
>
>
> The switch to registration of metadata from the global scope to selected
> scopes is not complete yet, although for all current test cases there are no
> failures.
> Currently the generated init() method for a factory calls the deprecated
> SDOUtil.registerStaticTypes for its simple dependencies.
> In the simple case this is just ModelFactory and SDOFactory, but could
> contain other user generated dependencies if for example
> there were to be an xsd import of another namespace (exposed a gap in our
> test case set). This would mean that the user generated model dependency
> would also be registered against the global registry.
> It is proposed that all registrations, including the built in models, are
> made against the helper context provided to the Factory's register method.
> I.e. a state invariant that no models are ever registered against the global
> registry.
> The pattern of looking up models from within packages is not required, since
> the code can just refer to each model's singleton INSTANCE (see below for the
> exception SDOFactoryImpl). Creation of the metadata should be done in the
> init
> method, and the registration of all metadata (built-in or otherwise) should
> be done in the register method. It would appear on inspection that no
> reference to the simple dependencies of a factory need be made in its init
> method, and simple reference to the dependencies INSTANCE in the register
> will be enough to ensure that those dependencies are initialised before being
> registered against the provided scope.
> SDOFactoryImpl does not have an INSTANCE currently. The current proposed
> solution is to modify SDOFactory to have an INSTANCE, in order that it can
> behave like an ordinary generated dependency in this new approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
