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]
