We currently rely heavily on the change-history-enabled datagraphs available in SDO 1. Once TUSCANY supports change-history-enabled datagraphs, we will consider using it exclusively given the feedback you provided below. I suspect there are other folks like ourselves in the same boat. All the SDO 2 "helper APIs" as well as the expanded documentation are valuable in-and-of-themselves apart from the enhancements in the v2 spec related to the core SDO core classes themselves. So, fixing Tuscany to serialize DGs with ChangeSummary would be our top priority. In the future, we have no problems with DataGraphs being deprecated. It would, however, take us some time to refactor DataGraphs out of our application. I'll be glad to help Tuscany SDO 2 in a testing capacity by reporting bugs, etc. Take care, - Ron
----- Original Message ---- From: Frank Budinsky <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, June 7, 2006 8:50:15 AM Subject: Re: Deserializing SDOs using scoped registries > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
