Add'l comments. Regards, - Ron ----- Original Message ---- From: Raymond Feng <[EMAIL PROTECTED]> To: [email protected]; [email protected] Sent: Friday, May 26, 2006 3:12:45 PM Subject: Re: Deserializing SDOs using scoped registries
Please see my further comments. Thanks, Raymond ----- Original Message ----- From: "Ron Gavlin" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, May 26, 2006 11:45 AM Subject: Re: Deserializing SDOs using scoped registries > 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> > <rfeng>I checked the Tuscany SDO code and it seems that each TypeHelper has its own registry which delegates (only get, not put) to EPackage.Registry.INSTNACE which is classloader-aware.In this case, I understand CORBA code cannot assess the model in your TypeHelper instance. It leads to an interesting question: What registry does the DataGraph/DataObject java deserialization use? So really, we need to have a scope-aware registry and SDO should provide such a pluggability so that it will resolve to the same TypeHelper for serialization and deserialization in a given context.</rfeng> <rg> Exactly. This is the problem I was attempting to expose.</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> <rfeng>Again, I used the classloader-aware registry and that's why it worked for me.</rfeng> <rg> Were you by chance using WebSphere? I suspect the EMF classloader-aware registry was written with WebSphere in mind. I am using WebLogic 8.1 and the EMF classloader-aware registry isn't working for me out of the box. I'll keep investigating. Any suggestions are welcome.</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]
