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]
