> But, with the features that are implemented, how would you compare > its stability to that of SDO 1?
For the most part (especially for the overlapping function between SDO 1 and 2) I'd say that the stability is roughly the same because most of the SDO 2 code is just the a restructured version of the SDO 1 code from Eclipse. We have introduced a few new bugs as a result of changing things to be SDO 2 compliant, but not really very many. > One more question if you don't mind. TUSCANY does not currently support > serialization of dataobjects outside a datagraph. Is this a temporary > limitation? The fix I committed in TUSCANY-22 is exactly this - support for the new SDO 2 prescribed standard java.io.Serialization support. You can now serialize any DataObject, whether it's in a DataGraph or not. However, this new serialization support does not work when serializing a complete DataGraph (with ChangeSummary). That's still broken in Tuscany :-( The SDO 2 spec seems to be moving in the direction of deprecating DataGraph's since ChangeSummary properties on a DataObject can be used instead. But, in Tuscany, we don't have that working yet either. So, here's the question we're faced with. Which should we concentrate on next in Tuscany: 1) get Java serialization working again for DataGraph's, or 2) get the ChangeSummaryType properties working on DataObject. We've already started working on 2), but it will take a few weeks to finish. On the other hand, 1) could probably be fixed in a few days, but may not be very strategically interesting. Do you have an opinion. What are your timelines for getting this support? Would you like to help? Thanks, Frank. > > 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. > >> > >> - Ron > >> > >> Unfortunately, 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. The > >>> > > http://example.org/ord > > > >>> namespace is statically registered while the > >>> > >> http://example.org/info/zipcode > >> > >>> and 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. > >> > >> > >>> Now 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. > >>> > >> 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 is > >> > > that > > > >> the CORBA RMI can't be passed the right registry. Why does it need to > >> > > use > > > >> the global registry? > >> > >> <rg> > >> It appears the EMF EDataGraphImpl.EDataGraphExternalizable. > >> readExternal performs the deserialization on behalf of the CORBA RMI > >> infrastructure. 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 the > >>> global 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 delegate > >>> > >> registries. > >> I guess that sounds right. But if you did the copy in the same > >> > > classLoader > > > >> 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 scoped > >> > > TypeHelpers. > > > >> Are they classLoader scoped? If so, then I think what we would want is > >> > > to > > > >> use 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). > >> > >> > >>> Second, 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? > >>> > >> I 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 the > >> > > EMF > > > >> 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... Then > >> I 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> > >> > >> > >>> Thanks in advance for your assistance, > >>> > >>> - Ron > >>> > >>> > >>> > >>>> So, a couple more questions for you: > >>>> 1) you mention that you have a combination of static and dynamic > >>>> > >> models, > >> > >>>> but 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 local > >>>> > > TypeHelper > > > >>>> registries, but the CORBA RMI only has access to the global EMF > >>>> > >> registry > >> > >>>> ... 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, > >>>> > > > > > >> the > >> > >>>> metadata is actually going to the classloader-specific delegate > >>>> > >> registries > >> > >>>> ... 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're > >>>> > >> describing > >> > >>>> is a scenario where the server has statically generated classes for a > >>>> > > > > > >>>> model that on the client side is manipulated dynamically. Is that > >>>> > >> right? > >> > >>>> 3) Can you give me more details on how/where the metadata is > >>>> > > registered > > > >> on > >> > >>>> both sides? > >>>> > >>> BTW, I have The "EDataGraphImpl" I can't afford to statically > >>> register them. during thdefined at runtime > >>> > >>> 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 something > >>> > > that > > > >>> nobody has tried yet with the Tuscany code (If somebody else knows > >>> > >> better, > >> > >>> please chime in :-) > >>> > >>> That said, if you want to keep feeding me more details, we can try to > >>> > >> work > >> > >>> it 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 dynamic > >>> > > models, > > > >>> but 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 local > >>> > > TypeHelper > > > >>> registries, but the CORBA RMI only has access to the global EMF > >>> > > registry > > > >>> ... 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, > >>> > >> the > >> > >>> metadata is actually going to the classloader-specific delegate > >>> > >> registries > >> > >>> ... 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're > >>> > >> describing > >> > >>> is a scenario where the server has statically generated classes for a > >>> model that on the client side is manipulated dynamically. Is that > >>> > > right? > > > >>> 3) Can you give me more details on how/where the metadata is > >>> > > registered > > > >> on > >> > >>> both 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 more > >>>> specific 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 RMI > >>>> to 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 a > >>>>> mess, including the > >>>>> GLOBAL registry limitation, but the plan is to fix > >>>>> it in the near future. > >>>>> > >>>>> Currently in Tuscany it works like this: > >>>>> > >>>>> - Each TypeHelper instance represents a unique scope > >>>>> which 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 EMF > >>>>> GLOBAL registry for types > >>>>> that are not found in the local registry. > >>>>> - Statically generated classes (which currently use > >>>>> the 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-specific > >>>>> delegate registry. > >>>>> - The net of all this is that there is a sort of a > >>>>> spider registry > >>>>> configuration currently, with the EMF global > >>>>> registry in the middle (with > >>>>> nothing actually in it). > >>>>> > >>>>> The plan, moving forward, is to make generated > >>>>> classes 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 of > >>>>> scopes, 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] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
