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]
