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]
