You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Ron Gavlin <rg...@yahoo.com> on 2006/06/01 13:58:38 UTC
Re: Deserializing SDOs using scoped registries
Frank,
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
Frank Budinsky wrote: Ron,
See more questions and comments below. Sorry that I'm asking more
questions then I'm answering :-)
Frank.
Ron Gavlin <rg...@yahoo.com> 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?
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?
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.
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.
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 <fr...@ca.ibm.com>
To: tuscany-user@ws.apache.org
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 <rg...@yahoo.com> 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 <fr...@ca.ibm.com> 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:
tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail:
tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org