You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Rick Rineholt (JIRA)" <tu...@ws.apache.org> on 2006/04/15 00:10:00 UTC
[jira] Created: (TUSCANY-195) Load time EMF registering of URI to
dynamic data object before static types can be registered.
Load time EMF registering of URI to dynamic data object before static types can be registered.
----------------------------------------------------------------------------------------------
Key: TUSCANY-195
URL: http://issues.apache.org/jira/browse/TUSCANY-195
Project: Tuscany
Type: Bug
Components: Java SCA Axis Integration
Environment: ALL current build
Reporter: Rick Rineholt
Priority: Critical
The loading of the TypeHelper in ExternalWebServiceBuilder.createExternalWebServiceClient() line: 183 loads into the EMF registry the URI that most likely maps to a static generated type. But this is occuring at load/build time prior to even any statically generated application SDO's are in scope. Or before they can be registered by the application. This mapping is then done to DynamicDataObjects. This results in a class cast exception when the generated interface expects the static types and a DDO is supplied. My very limited understanding of EMF/SDO is that once the mapping is in place that subsequent registering of static types will not have any affect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-195) Load time EMF registering of URI to
dynamic data object before static types can be registered.
Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-195?page=all ]
ant elder updated TUSCANY-195:
------------------------------
Priority: Blocker (was: Critical)
I've changed this to blocker as it breaking WS interop testing as well.
Frank/Jeremy: On the IRC chat last Friday it sounded like you guys were working on this, hows that going and can I assign the JIRA to one of you?
> Load time EMF registering of URI to dynamic data object before static types can be registered.
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-195
> URL: http://issues.apache.org/jira/browse/TUSCANY-195
> Project: Tuscany
> Type: Bug
> Components: Java SCA Axis Binding
> Environment: ALL current build
> Reporter: Rick Rineholt
> Priority: Blocker
>
> The loading of the TypeHelper in ExternalWebServiceBuilder.createExternalWebServiceClient() line: 183 loads into the EMF registry the URI that most likely maps to a static generated type. But this is occuring at load/build time prior to even any statically generated application SDO's are in scope. Or before they can be registered by the application. This mapping is then done to DynamicDataObjects. This results in a class cast exception when the generated interface expects the static types and a DDO is supplied. My very limited understanding of EMF/SDO is that once the mapping is in place that subsequent registering of static types will not have any affect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-195) Load time EMF registering of URI to
dynamic data object before static types can be registered.
Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-195?page=comments#action_12376239 ]
ant elder commented on TUSCANY-195:
-----------------------------------
This hack only works for externalServices, not for entryPoints. Clients can call SDOUtil.registerStaticTypes before calling the externalService, but I can't see how to do that for entryPoints.
The Tuscany runtime makes available the WS entryPoint, a WS request comes in and the XML needs to be converted to Java objects before the SCA componet is invoked. As nothing has registerged the SDO factory the result is a DynamicDataObject instead of the Objects the component is expecting. All the Axis2 binding code has to go on is the service interface class, and that has been dynamically gen'd from the WSDL so its not even the SEI class the component is using or even in the same class loader.
This is also why the TomcatIntegrationTestCases are broken with this hack applied.
> Load time EMF registering of URI to dynamic data object before static types can be registered.
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-195
> URL: http://issues.apache.org/jira/browse/TUSCANY-195
> Project: Tuscany
> Type: Bug
> Components: Java SCA Axis Binding
> Environment: ALL current build
> Reporter: Rick Rineholt
> Priority: Blocker
>
> The loading of the TypeHelper in ExternalWebServiceBuilder.createExternalWebServiceClient() line: 183 loads into the EMF registry the URI that most likely maps to a static generated type. But this is occuring at load/build time prior to even any statically generated application SDO's are in scope. Or before they can be registered by the application. This mapping is then done to DynamicDataObjects. This results in a class cast exception when the generated interface expects the static types and a DDO is supplied. My very limited understanding of EMF/SDO is that once the mapping is in place that subsequent registering of static types will not have any affect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-195) Load time EMF registering of URI to
dynamic data object before static types can be registered.
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-195?page=comments#action_12376223 ]
Jean-Sebastien Delfino commented on TUSCANY-195:
------------------------------------------------
Here's a hack to workaround this problem and get the WS interop tests to work:
in o.a.t.core.loader.assembly.ImportWSDLLoader, comment out lines 98 and 99:
//XSDHelper xsdHelper = SDOUtil.createXSDHelper(context.getTypeHelper());
//xsdHelper.define(xsdInputStream, null);
Defining the SDO metadata from the WSDL/XSD can be skipped if you have the generated SDO classes and call SDOUtil.registerStaticTypes(TheGeneratedFactory.class) as part of the initialization of one of your components.
This is just a temporary hack to unblock the WS testing (and it should help in the Bigbank scenario as well). This hack breaks other test cases which do not use static types (the TomcatIntegrationTestCases) so a clean fix needs to be provided for this bug ASAP, as most of us are blocked by it.
> Load time EMF registering of URI to dynamic data object before static types can be registered.
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-195
> URL: http://issues.apache.org/jira/browse/TUSCANY-195
> Project: Tuscany
> Type: Bug
> Components: Java SCA Axis Binding
> Environment: ALL current build
> Reporter: Rick Rineholt
> Priority: Blocker
>
> The loading of the TypeHelper in ExternalWebServiceBuilder.createExternalWebServiceClient() line: 183 loads into the EMF registry the URI that most likely maps to a static generated type. But this is occuring at load/build time prior to even any statically generated application SDO's are in scope. Or before they can be registered by the application. This mapping is then done to DynamicDataObjects. This results in a class cast exception when the generated interface expects the static types and a DDO is supplied. My very limited understanding of EMF/SDO is that once the mapping is in place that subsequent registering of static types will not have any affect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-195) Load time EMF registering of URI to
dynamic data object before static types can be registered.
Posted by "Jean-Sebastien Delfino (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-195?page=all ]
Jean-Sebastien Delfino resolved TUSCANY-195:
--------------------------------------------
Resolution: Fixed
This is now fixed. I've added the necessary <import.sdo> statements to the sca.module files and was able to run the test cases successfully.
> Load time EMF registering of URI to dynamic data object before static types can be registered.
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-195
> URL: http://issues.apache.org/jira/browse/TUSCANY-195
> Project: Tuscany
> Type: Bug
> Components: Java SCA Axis Binding
> Environment: ALL current build
> Reporter: Rick Rineholt
> Priority: Blocker
>
> The loading of the TypeHelper in ExternalWebServiceBuilder.createExternalWebServiceClient() line: 183 loads into the EMF registry the URI that most likely maps to a static generated type. But this is occuring at load/build time prior to even any statically generated application SDO's are in scope. Or before they can be registered by the application. This mapping is then done to DynamicDataObjects. This results in a class cast exception when the generated interface expects the static types and a DDO is supplied. My very limited understanding of EMF/SDO is that once the mapping is in place that subsequent registering of static types will not have any affect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-195) Load time EMF registering of URI to
dynamic data object before static types can be registered.
Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-195?page=comments#action_12376468 ]
ant elder commented on TUSCANY-195:
-----------------------------------
This still does not work for me for WS entryPoints with complex types after the changes to support import.sdo. It does work for simple types, eg, Ricks account WS from BB, but the interop.service in the sandbox does not. Hopefully its just me doing something wrong, could someone else have a go and confirm if it works for them or not?
> Load time EMF registering of URI to dynamic data object before static types can be registered.
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-195
> URL: http://issues.apache.org/jira/browse/TUSCANY-195
> Project: Tuscany
> Type: Bug
> Components: Java SCA Axis Binding
> Environment: ALL current build
> Reporter: Rick Rineholt
> Priority: Blocker
>
> The loading of the TypeHelper in ExternalWebServiceBuilder.createExternalWebServiceClient() line: 183 loads into the EMF registry the URI that most likely maps to a static generated type. But this is occuring at load/build time prior to even any statically generated application SDO's are in scope. Or before they can be registered by the application. This mapping is then done to DynamicDataObjects. This results in a class cast exception when the generated interface expects the static types and a DDO is supplied. My very limited understanding of EMF/SDO is that once the mapping is in place that subsequent registering of static types will not have any affect.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira