Frank,Thanks for the update. I'll give the TUSCANY-22 fixes a try in the near future and let you know if they fix my problem.
In my current project, I am using a hodgepodge of TUSCANY code and SDO 1 code. Specifically, I am augmenting the SDO 1 code with the TUSCANY implementation of the SDO 2 "helper" APIs. I would like to completely move to the TUSCANY SDO 2 codebase but I am concerned about it's stability and maturity. I know TUSCANY is not yet implementing some of the new SDO 2 "features" and that isn't a problem. But, with the features that are implemented, how would you compare its stability to that of SDO 1?
One more question if you don't mind. TUSCANY does not currently support serialization of dataobjects outside a datagraph. Is this a temporary limitation? Will this go away once you implement the new SDO 2 change history feature? Here is why I ask. I have static dataobjects that I would like to pass across the tiers of my application without having to wrap them in a datagraph. Since I don't need change history for these dataobjects, it would be nice to pass them directly. Is there a way currently to workaround this limitation?
Thanks again. - Ron Frank Budinsky wrote:
Hi Ron,>From your latest comments, I get the feeling that your problem may be fixed with the changes I checked in for TUSCANY-22 (revision 412225). Alth ough there's still a general issue with scoping, It sounds like your particular scenario, where dynamic types are registered in TypeHelper.INSTANCE and static types registered globally using SDOUtil.registerStaticTypes(), should work now. I think you're right about the problem with EMF's EDataGraphImpl.EDataGraphExternalizable, not being able to see the TypeHelper.INSTANCE's local registry. But, actually, I'm surprised if that was the only problem. The whole EDataGraphImpl-based implementation of java.io.Serializable was just left over from SDO 1 but meant to be replaced. It wasn't really working in the Tuscany environment anyway. The fix for TUSCANY-22 is the new replacement, and I think it may actually work for you, so please give it a try and let me know how it goes.Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 06/05/2006 10:58:15 AM:Frank,I am re-sending my original response just in case you could not decipher my comments from the rest of the thread. This time I wrapped them in </rg> tags.- RonUnfortunately, I don't have many answers to your questions. I would think the guys responsible for making EMF/SDO (1.0) work in the WebSphere environment might have insights into some of these issues. It may be more of an issue with EMF than the actual Tuscany SDO code. See my comments below. - Ron----- Original Message ---- From: Frank Budinsky <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, May 30, 2006 9:04:04 PM Subject: Re: Deserializing SDOs using scoped registries Ron,See more questions and comments below. Sorry that I'm asking more questions then I'm answering :-)Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 05/26/2006 12:44:52 PM:Frank,My model is similar to the one listed below. Thehttp://example.org/ordthatnamespace is statically registered while thehttp://example.org/info/zipcodeand http://example.org/info/street namespaces are dynamically registered. In my application, add'l "info" namespaces maybe registered/de-registered on the fly so the "info" namespaces can't be statically registered up front. In both the client and server JVMs, the "ord" namespace is statically registered and the "info" namespaces are dynamically registered. I am attempting to pass (serialize/de-serialize) a DataGraph containing the "Sample Instance" DataObject below between the client and server JVMs. Currently, neither Tuscany SDO nor EMF/SDO out of the box appear to support this "mixed" static/dynamic type of model (note how InfoType in the "ord" namespace is extended in each of the "info" namespaces). I subclassed several Tuscany and EMF classes (including XSDEcoreBuilder) to add this support. With these enhancements, XMLHelper.INSTANCE.load() successfully loads the "Sample Instance" as a DataObject using this "mixed" model. I'm currently investigating whether I can contribute these modifications back to Tuscany SDO and EMF.That would be great if you can contribute (or just show us) what you needed to change to make "mixed" static/dynamic models work. This seems like an important scenario to support.This would seem to defeat the purpose of having locally scoped TypeHelpers. What happens if two TypeHelpers have different versions or otherwise conflicting metadata? It seems the root of your problem isNow let me respond to your questions.1a. You are correct, the dynamic models on the client side are stored in local TypeHelper registries, but the CORBA RMI only has access to the global EMF registry. (I solved this problem by stealing the dynamic EPackages from the TypeHelper's ExtendedMetaData and registering them myself in the global EMF registry. Ugly, but it worked.the CORBA RMI can't be passed the right registry. Why does it need touseclassLoaderthe global registry? <rg> It appears the EMF EDataGraphImpl.EDataGraphExternalizable. readExternal performs the deserialization on behalf of the CORBA RMIinfrastructure. Am I correct that somehow the extendedMetaData in the scoped TypeHelpers has to be injected into the EDataGraphImpl/Externalizables for the deserialization to work correctly? Do you have an idea how to make that happen? </rg>1b. Not quite. The server-side CORBA RMI code accesses the server- side, statically-registered "ord" package w/out difficulty using theglobal classloader-specific delegate registries. However, the dynamic models stored in the TypeHelper registries on the server cannot be accessed by the CORBA RMI code (same problem as in 1a above). However, the trick described above didn't work on the server presumably because of the server classloader-specific delegateregistries.I guess that sounds right. But if you did the copy in the sameTypeHelpers.scope that the RMI code runs in, then I would think it should work.First, do you have any ideas how problem "1b" can be solved?I think I need to understand what the scope is of the scopedAre they classLoader scoped? If so, then I think what we would want istouse the actual TypeHelper registries as the delegate registries for EMF.We (or you) could provide a special delegate registry that does that (notice that the EMF registry can be overridden with a system property).EMFI need to understand the scope of the TypeHelpers better. How many are there and who creates them? Ideally we will be able to get rid of theSecond, assume for the moment that I had a pure dynamic model, i.e.,the "ord" namespace was dynamically rather than statically registered. How would the CORBA RMI code get a reference to the appropriate, local TypeHelper registries to de-serialize the DataGraph and its child DataObjects?registry entirely. We might need some kind of global view of the local registries, but I still wonder about the question I asked above about conflicting metadata in the multiple scopes.<rg>Not totally sure what you are asking here. I'll assume you want to know how my code works. In my code on both the client and server,I first register the static namespace using SDOUtil.register... ThenI invoke XSDHelper.INSTANCE.define to register each of my dynamic namespaces. Later, when deserialization is necessary, I expect the "infrastructure" to correctly deserialize the SDOs using both the static and dynamic namespaces. </rg>models,Thanks in advance for your assistance, - RonSo, a couple more questions for you:1) you mention that you have a combination of static and dynamicbut if I'm not sure I understand the scenario you're describing. If ITypeHelperunderstand it right, you have two problems:a) dynamic models on the client side are stored in localregistryregistries, but the CORBA RMI only has access to the global EMF... is that right?b) the static (?) models on the server side are registered in theglobal registry, but since it's running in the appserver environment,theregistriesmetadata is actually going to the classloader-specific delegatedescribing... but presumably, the CORBA RMI code is not running in the same classloader as the app that registered the metadata.Do I have the two problems straight?2) If the answer to the first question is yes, then what you'reis a scenario where the server has statically generated classes for aregisteredmodel that on the client side is manipulated dynamically. Is thatright?3) Can you give me more details on how/where the metadata isonthatBTW, I have The "EDataGraphImpl" I can't afford to statically register them. during thdefined at runtimeboth sides?Sample Instance (chapter04.xml) <ord:order xmlns:ord="<http://example.org/ord>"; xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"; xsi:schemaLocation="<http://example.org/ord> chapter04ord1.xsd"> <ord:number>123ABBCC123</ord:number> <ord:customer> <ord:name>Pat Walmsley</ord:name> <ord:number>15465</ord:number> <info xsi:type="ns1:InfoType" xmlns="" xmlns:ns1="<http://example.org/info/zipcode>";> <zipcode>21043</zipcode> </info> </ord:customer> <ord:customer> <ord:name>Priscilla Walmsley</ord:name> <ord:number>15466</ord:number> <info xsi:type="ns1:InfoType" xmlns="" xmlns:ns1="<http://example.org/info/street>";> <street>341 Duckworth Way</street> </info> </ord:customer> <ord:items> <product> <number>557</number> <name>Short-Sleeved Linen Blouse</name> <size system="US-DRESS">10</size> <color value="blue"/> </product> </ord:items> </ord:order> Schema Document 1 (chapter04ord1.xsd) <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";; targetNamespace="<http://example.org/ord>";; xmlns="<http://example.org/ord>";; xmlns:prod="<http://example.org/prod>";; elementFormDefault="qualified"> <xsd:import namespace="<http://example.org/prod>";; schemaLocation="chapter04prod.xsd"/> <xsd:simpleType name="OrderNumType"> <xsd:restriction base="xsd:string"/> </xsd:simpleType> <xsd:complexType name="InfoType"/> <xsd:complexType name="CustomerType"> <xsd:sequence> <xsd:element name="name" type="CustNameType"/> <xsd:element name="number" type="xsd:integer"/> <xsd:element name="info" type="InfoType" form="unqualified"/> </xsd:sequence> </xsd:complexType> <xsd:simpleType name="CustNameType"> <xsd:restriction base="xsd:string"/> </xsd:simpleType> <xsd:element name="order" type="OrderType"/> <xsd:complexType name="OrderType"> <xsd:sequence> <xsd:element name="number" type="OrderNumType"/><xsd:element name="customer" type="CustomerType"maxOccurs="unbounded"/><xsd:element name="items" type="prod:ItemsType"/> </xsd:sequence> </xsd:complexType> </xsd:schema> Schema Document 2 (chapter04infozipcode.xsd) <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";; xmlns:ord="<http://example.org/ord>";; xmlns="<http://example.org/info/zipcode>";; targetNamespace="<http://example.org/info/zipcode>";; elementFormDefault="unqualified"> <xsd:import namespace="<http://example.org/ord>";; schemaLocation="chapter04ord1.xsd"/> <xsd:complexType name="InfoType"> <xsd:complexContent> <xsd:extension base="ord:InfoType"> <xsd:sequence> <xsd:element name="zipcode" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema> Schema Document 3 (chapter04infostreet.xsd) <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";; xmlns:ord="<http://example.org/ord>";; xmlns="<http://example.org/info/street>";; targetNamespace="<http://example.org/info/street>";; elementFormDefault="unqualified"> <xsd:import namespace="<http://example.org/ord>";; schemaLocation="chapter04ord1.xsd"/> <xsd:complexType name="InfoType"> <xsd:complexContent> <xsd:extension base="ord:InfoType"> <xsd:sequence> <xsd:element name="street" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:schema> Schema Document 4 (chapter04prod.xsd) <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";; xmlns="<http://example.org/prod>";; targetNamespace="<http://example.org/prod>";; elementFormDefault="unqualified"> <xsd:complexType name="ItemsType"> <xsd:sequence> <xsd:element name="product" type="ProductType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ProductType"> <xsd:sequence> <xsd:element name="number" type="xsd:integer"/> <xsd:element name="name" type="xsd:string"/> <xsd:element name="size" type="SizeType"/> <xsd:element name="color" type="ColorType"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="SizeType"> <xsd:simpleContent> <xsd:extension base="xsd:integer"> <xsd:attribute name="system" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:complexType name="ColorType"> <xsd:attribute name="value" type="xsd:string"/> </xsd:complexType> </xsd:schema> ----- Original Message ---- From: Frank Budinsky <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, May 26, 2006 8:51:35 AM Subject: re: Deserializing SDOs using scoped registries Ron,I'm not sure I can answer your questions. I think this is somethingmodels,nobody has tried yet with the Tuscany code (If somebody else knowsbetter,please chime in :-) That said, if you want to keep feeding me more details, we can try toworkit out together, and at the same time help us to design the scoping mechanism right in Tuscany SDO.So, a couple more questions for you:1) you mention that you have a combination of static and dynamicTypeHelperbut if I'm not sure I understand the scenario you're describing. If I understand it right, you have two problems: a) dynamic models on the client side are stored in localregistryregistries, but the CORBA RMI only has access to the global EMFthe... is that right?b) the static (?) models on the server side are registered in the global registry, but since it's running in the appserver environment,metadata is actually going to the classloader-specific delegateregistries... but presumably, the CORBA RMI code is not running in the same classloader as the app that registered the metadata.describingDo I have the two problems straight?2) If the answer to the first question is yes, then what you'reis a scenario where the server has statically generated classes for a model that on the client side is manipulated dynamically. Is thatright?registered3) Can you give me more details on how/where the metadata isonboth sides? Thanks, Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 05/25/2006 11:54:07 AM:Frank, Thanks for explaining the current Tuscany SDO scoping nuances. Specifically, I am having CORBA MARSHALLING/deserialization problems. Let me be morespecific and maybe you can help.I have a model with a mixture of static and dynamic schemas/registries. My client application is attempting to pass Datagraphs back and forth via RMIto a session bean in an appserver.Currently, when I pass datagraphs composed of dynamically typed dataobjects, I receive CORBA MARSHALLING exceptions stating that specific "dynamic" EPackages cannot be found. On the client-side, I fixed this by extracting the dynamic EPackage from the Tuscany scoped registry and registering it in the EMF global registry. I am using a TypeHelperImpl subclass that exposes the scoped registry for this purpose. This technique doesn't seem to work on the server-side presumably due to complexities introduced by the appserver classloader infrastructure. On the appserver, the global registry doesn't appear to be really "global". As expected, if I set the appserver's JVM property "org.eclipse.emf.ecore.EPackage.Registry.INSTANCE" to "org.eclipse.emf.ecore.impl.EPackageRegistryImpl", DataGraph deserialization within the appserver perfectly. But, removing the delegating classloader registry within the appserver is not a good idea. In particular, is there a way currently (w/out disabling the delegating classloader registry) to register dynamic packages in the appserver such that they are available during datagraph deserialization? I presume this works on WebSphere. Does WebSphere have special hooks to support this EMF deserialization? Furthermore, how will the datagraph deserializer in the final Tuscany SDO implementation know how to navigate through the various scopes to find the registries needed to deserialize dynamically/typed data? Thanks in advance for all your help. - Ron --- Frank Budinsky <[EMAIL PROTECTED]> wrote:Ron, The current Tuscany implementation is a bit of amess, including the GLOBAL registry limitation, but the plan is to fixit in the near future. Currently in Tuscany it works like this: - Each TypeHelper instance represents a unique scopewhich encapsulates its own local EPackage registry. - Any metadata registered via XSDHelper.define or TypeHelper.define will be in this local scope.- Local registries currently delegate to the EMFGLOBAL registry for types that are not found in the local registry.- Statically generated classes (which currently usethe EMF generator patterns) are registered in the GLOBAL registry. - As in EMF, the GLOBAL registry, when running standalone (not in Eclipse) actually delegates to another classloader-specificdelegate registry. - The net of all this is that there is a sort of aspider registry configuration currently, with the EMF global registry in the middle (with nothing actually in it).The plan, moving forward, is to make generatedclasses register their metadata in scope specific registries (the TypeHelper-local ones), instead of using the EMF GLOBAL registry. This is actually part of a bigger effort to change the generated class pattern to not have EMF dependencies.We're also planning to allow TypeHelper's(registries) to be configured (wired) any way you want to support nesting ofscopes, etc. I hope this answers your question. Frank.---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
