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]
