Raymond, Thanks for the input. See comments below. - Ron ----- Original Message ---- From: Raymond Feng <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, May 26, 2006 1:04:29 PM Subject: Re: Deserializing SDOs using scoped registries
Hi, I have some comments as well. Thanks, Raymond ----- Original Message ----- From: "Ron Gavlin" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, May 26, 2006 9:44 AM Subject: Re: Deserializing SDOs using scoped registries > 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. > <rfeng>This is an interesting topic. The basic question is: "Do we want to honor the static model if its namespace is referenced by the XSD when XSD2Ecore is performed?" . For example, your XSD has something like <element name="customer" type="customer:Customer"/> and you already have a static model registered for customer. I have some similar code as you described.<rfeng> <rg> Yes, you have described a more mainstream case. Our model in whiich a "dynamic" type extends a "static" type is probably less common and more demanding on the XMLLoader. <rg> > 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. > <rfeng>When you say local type helper, is it the one assoicated with the application classloader? If so, I believe CORBA code has access to it since the global registry will delegate to it.</rfeng> <rg> The "local" TypeHelper registry I am referring to is the "extendedMetaData" member variable within the Tuscany TypeHelperImpl instance. When CORBA code accesses the registry for de-serialization, does it know to how to navigate beyond the global registry into the "extendedMetaData" within this particular TypeHelperImpl instance?<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. > > First, do you have any ideas how problem "1b" can be solved? > > 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? > <rfeng>By my experience, I didn't have problems in CORBA serialization/deserialization (passing DataObject over RMI/IIOP) with dynamic model using EMF/SDO 1.0.</rfeng> <rg> My server application is packaged as an ear with child ejb and war modules. The EMF/SDO jars are stored in the APP-INF/lib directory of the ear. A startupServlet in the war module registers the static and dynamic modules. Session beans in the ejb module pass DataGraphs to/from an RMI/IIOP client. It may be that the war housing the startupServlet has a different classloader than its peer ejb module doing the serialization/de-serialization. If so, this may be causing the problem described above in 1b. Does that make sense? I'll check my appserver documentation to confirm.<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]
