Ron, The changes that have gone in since M1 are as follows and in this order:
1. 409280 - Fix for TUSCANY-425 2. 411265 - Fix for TUSCANY-118 3. 411280 - one more file for TUSCANY-118 4. 412225 - Fix for TUSCANY-22 5, 412857 - DataGraph Java serialization and related cleanup You really only need 412225 and 412857, but the some of the changes may be in files that have been changed by the previous 3 revisions, so I'm not sure what of the previous revs you need. I'd suggest just taking the whole bunch. Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 06/09/2006 07:41:10 AM: > After further investigation, it looks like I need revs 412857, > 412225, 411280, 409180 in that order, correct? > > - Ron > > ----- Original Message ---- > From: Ron Gavlin <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, June 9, 2006 7:32:16 AM > Subject: Re: Deserializing SDOs using scoped registries > > > Frank, > > Thanks for your efforts. I would like to base my testing on the M1 > build plus your SDO serialization fixes. If I overlay M1 with the > TUSCANY-22 fix and overlay that with fix "revision 412857", should > that take care of it? Or are there other SDO-related checkins that I need? > > Thanks in advance, > > - Ron > > ----- Original Message ---- > From: Frank Budinsky <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, June 8, 2006 5:10:01 PM > Subject: Re: Deserializing SDOs using scoped registries > > > Ron, > > I just commited the changes to support DG serialization (revision 412857). > Please let me know if you find any problems with it. > > You're right, the DAS folks have also been asking for this. > > Frank. > > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 06/07/2006 03:36:34 PM: > > > Sounds great. > > > > BTW, are the DAS folks interested in getting DG serialization > > working or are all of their tests performed within a single JVM such > > that they do not require complete DG serialization? > > > > - Ron > > > > ----- Original Message ---- > > From: Frank Budinsky <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Wednesday, June 7, 2006 1:57:54 PM > > Subject: Re: Deserializing SDOs using scoped registries > > > > > > Looking at it, I think I can fix DG serialization with a few hours of > > work. So, if I can find a few spare cycles, I'll try to do it by the end > > > of the week. > > > > Frank. > > > > > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 06/07/2006 12:46:10 PM: > > > > > 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. ll 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] > > > > > > > > > --------------------------------------------------------------------- > > 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]
