Hi,
I have some comments as well.
Thanks,
Raymond
----- Original Message -----
From: "Ron Gavlin" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 26, 2006 9:44 AM
Subject: Re: Deserializing SDOs using scoped registries
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.
<rfeng>This is an interesting topic. The basic question is: "Do we want to
honor the static model if its namespace is referenced by the XSD when
XSD2Ecore is performed?" . For example, your XSD has something like <element
name="customer" type="customer:Customer"/> and you already have a static
model registered for customer. I have some similar code as you
described.<rfeng>
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.
<rfeng>When you say local type helper, is it the one assoicated with the
application classloader? If so, I believe CORBA code has access to it since
the global registry will delegate to it.</rfeng>
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.
First, do you have any ideas how problem "1b" can be solved?
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?
<rfeng>By my experience, I didn't have problems in CORBA
serialization/deserialization (passing DataObject over RMI/IIOP) with
dynamic model using EMF/SDO 1.0.</rfeng>
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]
