You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org> on 2007/02/27 18:32:05 UTC
[jira] Created: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
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-Mx
Reporter: Kelvin Goodson
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.
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.
(I have more description to append here, but I have to stop, so I will append the rest later)
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512401 ]
Kelvin Goodson commented on TUSCANY-1143:
-----------------------------------------
David,
I don't think we want to make a 1:1 association between scopes and factories. The only place that you need the new scope instance member in your current implementation is in the method getInstanceStaticFactory(String namespaceURI), which is only referenced in the initializeMetaData methods of generated factory impls. This is not needed. You can refer to the Factory interface's INSTANCE variable. This is what I meant by "The pattern of looking up models from within packages is not required, since the code can just refer to each model's singleton INSTANCE" so the line in generated factories that currently looks like ....
ModelFactoryImpl theModelPackageImpl = (ModelFactoryImpl)getInstanceStaticFactory(ModelFactoryImpl.NAMESPACE_URI);
would become
ModelFactoryImpl theModelPackageImpl = (ModelFactoryImpl)ModelFactory.INSTANCE;
> 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
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514361 ]
Fuhwei Lwo commented on TUSCANY-1143:
-------------------------------------
After more investigation, the problem is surfaced when the sub-type has the same as the super-type. The SDO_PROPERTY_COUNT below becomes ambiguous. Since this is only a corner case, I will open another JIRA to track this so this JIRA can be closed.
public class InfoTypeImpl extends InfoTypeImpl implements InfoType
{
public final static int STREET = InfoTypeImpl.SDO_PROPERTY_COUNT + 0;
public final static int SDO_PROPERTY_COUNT = InfoTypeImpl.SDO_PROPERTY_COUNT + 1;
> 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, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514352 ]
Fuhwei Lwo commented on TUSCANY-1143:
-------------------------------------
I gened the test/resources/extensible/infostreet.xsd and the generated files cannot be compiled.
I think the problem is due to the sub types.
<xsd:complexType name="InfoType">
<xsd:complexContent>
<xsd:extension base="customer:InfoType">
<xsd:sequence>
<xsd:element name="street" type="xsd:string" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
> 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, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512428 ]
Kelvin Goodson commented on TUSCANY-1143:
-----------------------------------------
Sorry to do this in such a piecemeal fashion, but I note that we still have a reference to the dependent factories in the generated factory's init() method. We can drop this completely. The dependencies will then only be initialized the first time the static INSTANCES are referenced in the initializeMetaData calls as part of the register operation.
> 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
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1143:
------------------------------------
Affects Version/s: (was: Java-SDO-Mx)
Java-SDO-M3
> 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-M3
> Reporter: Kelvin Goodson
> Fix For: Java-SDO-Mx
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1143:
------------------------------------
Description:
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.
was:
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.
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.
(I have more description to append here, but I have to stop, so I will append the rest later)
> 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-Mx
> Reporter: Kelvin Goodson
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David T. Adcox updated TUSCANY-1143:
------------------------------------
Attachment: 1143.patch
I have incorporate Kelvin's thoughts into this latest patch. The FactoryInterface.INSTANCE is now used as the means of retrieving the dependent factory instances in metadata initialization. This enabled me to move the initializesMetadata back down into the init() method. This also meant that I could remove the scope from being stored in the factory.
> 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
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson resolved TUSCANY-1143.
-------------------------------------
Resolution: Fixed
> 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, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512901 ]
Kelvin Goodson commented on TUSCANY-1143:
-----------------------------------------
Hi David,
I'm afraid that when I apply this patch now I get quite a few failures (see below). I looked into the first, where DefineTypeTestCase.testDefineDataType fails with a ClassCastException. Before the patch the instanceClass of MyIntType was int, but after applying the patch the instanceClass of this type is null. Can you take a look at this please?
AllTests
junit.framework.TestSuite
org.apache.tuscany.sdo.test.DefineTypeTestCase
testDefineDataType(org.apache.tuscany.sdo.test.DefineTypeTestCase)
java.lang.ClassCastException: The value of type 'class java.lang.Integer' must be of type 'org.apache.tuscany.sdo.impl.DataTypeImpl@4940494 (name: MyIntType) (instanceClassName: null) (serializable: true)'
at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettableDynamic.validate(EStructuralFeatureImpl.java:2176)
at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettable.dynamicSet(EStructuralFeatureImpl.java:2116)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:709)
at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:160)
at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1459)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:654)
at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:142)
at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java:526)
at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java:525)
at org.apache.tuscany.sdo.test.DefineTypeTestCase.testDefineDataType(DefineTypeTestCase.java:304)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase
testLargePayload(org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase)
java.lang.IllegalArgumentException
at org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:61)
at org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:43)
at org.apache.tuscany.sdo.test.JavaSerializeDeserializeTestCase.testLargePayload(JavaSerializeDeserializeTestCase.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
org.apache.tuscany.sdo.test.SerializeTypesTestCase
testSerializeXSDBase64BinaryRoundTrip(org.apache.tuscany.sdo.test.SerializeTypesTestCase)
java.lang.IllegalArgumentException
at org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:61)
at org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:43)
at org.apache.tuscany.sdo.test.SerializeTypesTestCase.testSerializeXSDBase64BinaryRoundTrip(SerializeTypesTestCase.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
testSerializeXSDHexBinaryRoundTrip(org.apache.tuscany.sdo.test.SerializeTypesTestCase)
java.lang.IllegalArgumentException
at org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:61)
at org.apache.tuscany.sdo.helper.DataFactoryImpl.create(DataFactoryImpl.java:43)
at org.apache.tuscany.sdo.test.SerializeTypesTestCase.testSerializeXSDHexBinaryRoundTrip(SerializeTypesTestCase.java:173)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
org.apache.tuscany.sdo.test.XSDHelperTestCase
testDefineWithLocation(org.apache.tuscany.sdo.test.XSDHelperTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at org.apache.tuscany.sdo.test.XSDHelperTestCase.testDefineWithLocation(XSDHelperTestCase.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
testDefineWithNoLocation(org.apache.tuscany.sdo.test.XSDHelperTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at org.apache.tuscany.sdo.test.XSDHelperTestCase.testDefineWithNoLocation(XSDHelperTestCase.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
testDuplicateDefineWithLocation(org.apache.tuscany.sdo.test.XSDHelperTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at org.apache.tuscany.sdo.test.XSDHelperTestCase.testDuplicateDefineWithLocation(XSDHelperTestCase.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
org.apache.tuscany.sdo.test.XSDQNameTestCase
testLoad(org.apache.tuscany.sdo.test.XSDQNameTestCase)
java.lang.RuntimeException: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 'policy' not found. (http:///temp.xml, 1, 135)
at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:66)
at org.apache.tuscany.sdo.test.XSDQNameTestCase.testLoad(XSDQNameTestCase.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature 'policy' not found. (http:///temp.xml, 1, 135)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:278)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:666)
at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad(SDOXMLResourceImpl.java:580)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java:634)
at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:259)
at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:238)
at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:104)
at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:64)
... 21 more
Caused by: org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'policy' not found. (http:///temp.xml, 1, 135)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.reportUnknownFeature(XMLHandler.java:1747)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleUnknownFeature(XMLHandler.java:1711)
at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.handleUnknownFeature(SDOXMLResourceImpl.java:367)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLHandler.java:1655)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:887)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:866)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:627)
at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(SDOXMLResourceImpl.java:401)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:268)
... 28 more
testSave(org.apache.tuscany.sdo.test.XSDQNameTestCase)
java.lang.IllegalArgumentException: Class 'Quote' does not have a feature named 'policy'
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2107)
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2250)
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1971)
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1886)
at org.apache.tuscany.sdo.util.DataObjectUtil.set(DataObjectUtil.java:734)
at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:225)
at org.apache.tuscany.sdo.test.XSDQNameTestCase.testSave(XSDQNameTestCase.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
testSave2(org.apache.tuscany.sdo.test.XSDQNameTestCase)
java.lang.IllegalArgumentException: Class 'Quote' does not have a feature named 'policy'
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setFeatureName(DataObjectUtil.java:2107)
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2250)
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1971)
at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1886)
at org.apache.tuscany.sdo.util.DataObjectUtil.set(DataObjectUtil.java:734)
at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:225)
at org.apache.tuscany.sdo.test.XSDQNameTestCase.testSave2(XSDQNameTestCase.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase
testXMLOptionsSchema2(org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase)
junit.framework.AssertionFailedError: expected same:<org.apache.tuscany.sdo.impl.ClassImpl@78d078d0 (name: purchaseReport) (instanceClassName: null) (abstract: false, interface: false)> was not:<org.apache.tuscany.sdo.impl.SDOPackageImpl$1@235a235a (name: AnyTypeDataObject) (instanceClassName: null) (abstract: false, interface: false)>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotSame(Assert.java:278)
at junit.framework.Assert.assertSame(Assert.java:242)
at junit.framework.Assert.assertSame(Assert.java:249)
at org.apache.tuscany.sdo.test.XMLLoadOptionsTestCase.testXMLOptionsSchema2(XMLLoadOptionsTestCase.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> 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
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Frank Budinsky (JIRA)" <tu...@ws.apache.org>.
[ 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515241 ]
Kelvin Goodson commented on TUSCANY-1143:
-----------------------------------------
adding the missing instrumental word to Fuhwei's comment above ...
"... when the sub-type has the same name as the super-type ..."
> 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, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512424 ]
Kelvin Goodson commented on TUSCANY-1143:
-----------------------------------------
David,
just to be a bit more thorough in my treatment of your comments. I think issues 1,2 and 3 are addressed by simply using a reference to the each of the static Factory INSTANCEs for dependencies in the initializeMataData() methods. I have been able to remove the scope variable and associated methods, including the getStaticFactory(URI) and successfully run the tests. Point 4 is addressed by editing the SDOFactory and introducing an INSTANCE variable that will similarly initialize the SDOPackage metadata, then we can treat it in same way as any factory generated by the SDO generator.
> 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
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514088 ]
David T. Adcox commented on TUSCANY-1143:
-----------------------------------------
Here are the two error stacks...
-------------------------------------------------------------------------------
Test set: org.apache.tuscany.sdo.test.DefineTypeTestCase
-------------------------------------------------------------------------------
Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.171 sec <<< FAILURE!
testDefineDataType(org.apache.tuscany.sdo.test.DefineTypeTestCase) Time elapsed: 0 sec <<< ERROR!
java.lang.ClassCastException: The value of type 'class java.lang.Integer' must be of type 'org.apache.tuscany.sdo.impl.DataTypeImpl@75847584 (name: MyIntType) (instanceClassName: null) (serializable: true)'
at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettableDynamic.validate(EStructuralFeatureImpl.java:2176)
at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettable.dynamicSet(EStructuralFeatureImpl.java:2116)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:709)
at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:160)
at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1459)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:654)
at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:142)
at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java:527)
at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java:525)
at org.apache.tuscany.sdo.test.DefineTypeTestCase.testDefineDataType(DefineTypeTestCase.java:304)
at org.apache.tuscany.sdo.test.DefineTypeTestCase.testDefineDataType(DefineTypeTestCase.java:304)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
-------------------------------------------------------------------------------
Test set: org.apache.tuscany.sdo.test.SerializeTypesTestCase
-------------------------------------------------------------------------------
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.453 sec <<< FAILURE!
testSerializeTypesRoundTrip(org.apache.tuscany.sdo.test.SerializeTypesTestCase) Time elapsed: 0.328 sec <<< ERROR!
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value '1' is not legal. (file:///C:/sdosrc/Tuscany/java/sdo/impl/all.datagraph, 115, 25)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:193)
at org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$LoadImpl.load(DataGraphResourceFactoryImpl.java:455)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:179)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094)
at org.apache.tuscany.sdo.helper.SDOHelperImpl.loadDataGraph(SDOHelperImpl.java:139)
at org.apache.tuscany.sdo.helper.SDOHelperImpl.loadDataGraph(SDOHelperImpl.java:160)
at org.apache.tuscany.sdo.helper.SDOHelperImpl.loadDataGraph(SDOHelperImpl.java:185)
at org.apache.tuscany.sdo.api.SDOUtil.loadDataGraph(SDOUtil.java:159)
at org.apache.tuscany.sdo.test.SerializeTypesTestCase.testSerializeTypesRoundTrip(SerializeTypesTestCase.java:118)
Caused by: org.eclipse.emf.ecore.xmi.IllegalValueException: Value '1' is not legal. (file:///C:/sdosrc/Tuscany/java/sdo/impl/all.datagraph, 115, 25)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2421)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2406)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.endElement(XMLHandler.java:1347)
at org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$1.endElement(DataGraphResourceFactoryImpl.java:627)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:183)
... 34 more
Caused by: java.lang.NullPointerException
at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(XMLHelperImpl.java:1018)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2416)
... 47 more
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David T. Adcox updated TUSCANY-1143:
------------------------------------
Attachment: 1143.patch
Ok, so here is my latest attempt for a patch on this issue. During testing of the last 1143 patch, I found some issues (noted by Kelvin) that have been addressed by T-1459. After a T-1459 was posted, I reworked my previous 1143 patch to be compatible. Additionally, I have regenerated the SDO builtin models so they follow the new code gen pattern. So, the good news is that most of the issues have been addressed. Unfortunately, I am still seeing two Errors thrown in org.apache.tuscany.sdo.test.DefineTypeTestCase and org.apache.tuscany.sdo.test.SerializeTypesTestCase (Error stacks will be appended). These errors seem to be the same as what was being seen before T-1459.
It seems that there is still some need for the builtin models to register with the EMF global registry, based on my test results. If I restore the EPackage.Registry registration code found in the second FactoryBase constructor (this code is removed with this patch), the problems are resolved.
More testing is needed to isolate where the EMF registry is being referenced, as it is my understanding that T-1459 should remove any SDO dependency on that registry. So, this patch may or may not be the final solution pending resolution of this last issue.
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David T. Adcox updated TUSCANY-1143:
------------------------------------
Attachment: 1143.patch
Working through this problem I have found some issues that warrant a discussion. I've made some 'executive' decisions on these matters, but I think they still are valid discussion points.
1) One of the design points was to move the dependent package registration from the init() method up into the register(HelperContext) method. That went well, but I found initializing each dependent package triggered a need for the dependent factories static factory. This wasn't good, since we can't retrieve that until the package has registered with the provided scope. So, a portion of the metadata initialization can not take place UNTIL the register(HC) is called.
2) FactoryBase still contained calls to the global registry. Specifically, it contained three such calls. I've commented out two of the registration calls, since this activity is accomplished in the generated code now using the provided HC scope. The third reference will need to remain as it is part of a public static method used to retrieve a static factory. I didn't deprecate this method, but it would seem logical that we should. Additionally, I created a new Instance method that performs a similar action using the instance scope rather than the global one.
3) The current method for tracking whether or not the package was initialized was via a boolean. If this was true, the init() method would return the created instance by calling the global registry. This needed to be changed and since I don't really have access to any registry during init() time under this new design, I changed the way the instance retrieval logic works. Now, I create a class static instance that is used to track whether or not the init has been executed. This class static is used to keep that object available for retrieval on subsequent init() calls.
Take a look over what I've done, let me know if we need to clean up anything and whether or not you'd like to see the old FactoryBase.getStaticFactory(URI) method deprecated.
> 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
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David T. Adcox updated TUSCANY-1143:
------------------------------------
Attachment: 1143.patch
I've incorporated Frank's comments and produced a new patch. I believe this will fix the issues we have been seeing.
> 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, 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1143:
------------------------------------
Fix Version/s: Java-SDO-Mx
> 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-Mx
> Reporter: Kelvin Goodson
> Fix For: Java-SDO-Mx
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1143) Generated code should separate
metadata creation from registration to permit proper scoping
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512288 ]
David T. Adcox commented on TUSCANY-1143:
-----------------------------------------
I need to add a fourth issue for consideration.
4) The problem described by this JIRA includes discussion of how to handle the special case of the SDOFactoryImpl. This issue is addressed in the patch by way of some changes added to the HelperContextImpl class. A static intialization block was added to this class where the SDOPackageImpl is initialized to the global scope. Additionally, changes were made in the getBuildInModelRegistry() method so that the buildIn registry will now defer to the global registry. So the hierarchy is as follows:
Application Registry
|
Built Ins Registry
|
Global Registry
During SDOPackageImpl registration, dependent EMF packages are also registered at this point into the global registry.
> 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
>
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org