You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Scott Kurinskas <sc...@gemstone.com> on 2006/09/06 03:40:06 UTC
RE: DataObject/DataGraph Serialization & DataGraphRoot
Hi All,
I thought I'd check-in regarding the status of this request? Kevin was kind
enough to log jira issue (http://issues.apache.org/jira/browse/TUSCANY-670),
but I'm blocked. Any chance there is a workaround available? I'd like to
use the DAS for DB access, but would be willing to map to/from a XSD if that
would eliminate the current problem.
Thanks,
Scott
-----Original Message-----
From: Kevin Williams [mailto:kevincbw@qwest.net]
Sent: Friday, August 25, 2006 3:25 PM
To: tuscany-user@ws.apache.org; tuscany-dev@ws.apache.org
Subject: Re: DataObject/DataGraph Serialization & DataGraphRoot
Hi Yang,
Comments in line ...
Yang ZHONG wrote:
> You may need to serialize the generated SDO metadata. On the other
> hand, I recommend the scenario design to be reconsidered.
>
> Thank Frank for suggesting a SDOUtil helper taking a list of Types for
> DAS to serialize all generated Types along with DataGraph.
> If you're willing to do that, I'll implement and send it out.
>
Yes. Please implement this method. If I understand correctly, the function
exists today in EMF but we prefer to stay with SDO apis. Also, I am not
sure why the method should take a list of generated Types since they exist
in the graph already. So, why not a method something like
this: serializeTypes() ?
> At the same time, I have some thoughts on the scenario design.
> DataBase schema is unlikely changed frequently, it's inefficient for
> DAS to always generate same SDO metadata over and over again on every
> single query, it's also inefficient to serialize same SDO metadata
> over and over again on every single invocation back to client. A
> typical customer scenario is, both client and server have SDO metadata
> already, therefore SDO metadata serialization isn't really necessary,
> and SDO metadata generation from DAS isn't really necessary. I know an
> early version of DAS (it was under different name) can accept existing
> SDO metadata and generate only SDO instances. My previous product
> customers actually complained about the very poor performance caused
> by repeating same SDO metadata generation and serialization.
>
> So, are you interested in trying such scenario so that you won't have
> "type not found" problem?
>
> Solution 2-1 (typical real scenario):
> 1. deploy SDO metadata to both client and server 2. instruct DAS to
> accept the existing SDO metadata 3. do rest of whatever being done
> right now
>
The DAS supports this scenario today and can accept Static Types from the
client. But, the purely dynamic scenario is an important one so we must
support both.
Thanks!
> Solution 2-2 (temporary if current DAS doesn't take any SDO metadata
> yet) 1. deploy the generated SDO metadata from DAS to client, once 2.
> do rest of whatever being done right now
>
> On 8/25/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> The RDB DAS creates the graph and corresponding Types dynamically
>> from the database query results.
>>
>> Frank Budinsky wrote:
>>
>> >The problem seems to be that the metadata for class DataGraphRoot is
>> not
>> >registered on the client. Is that the only missing metadata? What
>> >about the metadata for the rest of the model. I can't provide any
>> >more help without more details about how the metadata is being defined.
>> >
>> >Frank.
>> >
>> >"Kevin Williams" <ke...@qwest.net> wrote on 08/25/2006 03:30:15 PM:
>> >
>> >
>> >
>> >>It may be that your remote client has not initialized the SDO/EMF
>> >>environment properly and I think that we need some help from the
>> >>SDO team. I have copied this to the dev list since not everyone
>> >>has registered yet for the user list.
>> >>
>> >>--Kevin
>> >>
>> >>
>> >>
>> >>Luciano Resende wrote:
>> >>
>> >>
>> >>
>> >>>Hi Scott
>> >>>
>> >>> So, here is a quick example from our unit testings :
>> >>>
>> >>> /**
>> >>> * Read a specific customer
>> >>> */
>> >>> public void testReadSingle() throws Exception {
>> >>>
>> >>> //Create and initialize command to read customers
>> >>> DAS das = DAS.FACTORY.createDAS(getConnection());
>> >>> Command readCustomers = das.createCommand("select * from
>> >>>CUSTOMER where ID = 1");
>> >>>
>> >>> //Read
>> >>> DataObject root = readCustomers.executeQuery();
>> >>>
>> >>> //Verify
>> >>> assertEquals(1, root.getInt("CUSTOMER[1]/ID"));
>> >>> }
>> >>>
>> >>>If you get a reference to root first, then try to access the
>> >>>customer information, do you still have this problem ?
>> >>>
>> >>>Maybe something like this :
>> >>>
>> >>>DataObject root = readCust.executeQuery(); cust =
>> >>>root.getDataObject("CUSTOMER")
>> >>>
>> >>>Please let me know if this helps...
>> >>>
>> >>>- Luciano
>> >>>
>> >>>
>> >>>On 8/24/06, *Scott Kurinskas* <scott.kurinskas@gemstone.com
>> >>><ma...@gemstone.com>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Now that my DAS example is up and running, I'm trying to move my
>> >>> example to
>> >>> a client/server environment and integrate it with my product. My
>> >>> use-case
>> >>> is very simple, a client makes a request to the server, the
>> server
>> >>> fetches
>> >>> the result from the database and returns the DataObject back to
>> >>> the client.
>> >>> The server side code looks like the following:
>> >>>
>> >>> das = DAS.FACTORY.createDAS(getConfig("CompanyConfig.xml"),
>> >>> connection);
>> >>> String sql = "Select * from customers where
>> >>> customers.customerNumber = " +
>> >>> key;
>> >>> Command readCust = das.createCommand(sql);
>> >>> DataObject cust = readCust.executeQuery();
>> >>> return cust;
>> >>>
>> >>> The code executes fine on the client but for some reason the
>> >>> client is
>> >>> throwing the exception below. The client should be
>> >>> deserializing
>> >>>
>> >>>
>> >the
>> >
>> >
>> >>> response into a DataObject, but for some reason its complaining
>> >>> about class
>> >>> DataGraphRoot not found. The same code executing in a app works
>> >>> great.
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> Thanks again,
>> >>> Scott
>> >>>
>> >>> Caught unexpected Exception
>> >>> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Class
>> >>> 'DataGraphRoot' not found.
>> >>> ( file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20
>> >>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
>> >>>
>> >>>
>> >>20&%20Cache%20
>> >>
>> >>
>> >>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
>> >>>
>> >>>
>> >>20&%20Cache%20>
>> >>
>> >>
>> >>> Client/all.datagraph> &%20Cache%20Client/all.datagraph, 5, 22)
>> >>> at
>> >>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.
>> >>>
>> >>>
>> >>handleErrors(XMLLoadImpl.java:80)
>> >>
>> >>
>> >>> at
>> >>>
>> >>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java
>> >>>
>> >>>
>> >:189)
>> >
>> >
>> >>> at
>> >>> org.apache.tuscany.sdo.util.
>> >>>
>> >>>
>> >>DataGraphResourceFactoryImpl$DataGraphResourceIm
>> >>
>> >>
>> >>> pl$LoadImpl.load(DataGraphResourceFactoryImpl.java:452)
>> >>> at
>> >>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.
>> >>>
>> >>>
>> >>doLoad(XMLResourceImpl.java
>> >>
>> >>
>> >>> :1
>> >>> 79)
>> >>> at
>> >>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.
>> >>>
>> >>>
>> >>load(ResourceImpl.java:1089
>> >>
>> >>
>> >>> )
>> >>> at
>> >>> org.apache.tuscany.sdo.impl.
>> >>>
>> >>>
>> >>DataGraphImpl$EDataGraphExternalizable.readExter
>> >>
>> >>
>> >>> nal(DataGraphImpl.java:665)
>> >>> at
>> >>>
>> >>>
>> >>>
>> >java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
>> >58)
>> >
>> >
>> >>> at
>> >>> java.io.ObjectInputStream.
>> >>>
>> >>>
>> >>readOrdinaryObject(ObjectInputStream.java:1716)
>> >>
>> >>
>> >>> at
>> >>> java.io.ObjectInputStream.readObject0(ObjectInputStream.java
>> >>>
>> >>>
>> >:1304)
>> >
>> >
>> >>> at
>> >>>
>> >>>
>> >java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>> >
>> >
>> >>> at
>> >>> org.apache.tuscany.sdo.helper.
>> >>>
>> >>>
>> >>HelperProviderImpl$ResolvableImpl.readDataObje
>> >>
>> >>
>> >>> ct(HelperProviderImpl.java:205)
>> >>> at
>> >>> org.apache.tuscany.sdo.helper.
>> >>>
>> >>>
>> >>HelperProviderImpl$ResolvableImpl.readExternal
>> >>
>> >>
>> >>> (HelperProviderImpl.java:144)
>> >>> at
>> >>> commonj.sdo.impl.ExternalizableDelegator.
>> >>>
>> >>>
>> >>readExternal(ExternalizableDelegato
>> >>
>> >>
>> >>> r.java:80)
>> >>> at
>> >>>
>> >>>
>> >>>
>> >java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
>> >58)
>> >
>> >
>> >>> at
>> >>> java.io.ObjectInputStream.
>> >>>
>> >>>
>> >>readOrdinaryObject(ObjectInputStream.java:1716)
>> >>
>> >>
>> >>> at
>> >>>
>> >>>
>> >java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>> >
>> >
>> >>> at
>> >>>
>> >>>
>> >java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>> >
>> >
>> >>> at
>> >>>
>> >>>
>> >>>
>> >com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3
>> >200)
>>
>> >
>> >
>> >>> at
>> >>> com.gemstone.gemfire.internal.util.BlobHelper.
>> >>>
>> >>>
>> >>deserializeBlob(BlobHelper.jav
>> >>
>> >>
>> >>> a:55
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>--
>> >>>-----------------------------------------------------
>> >>>Luciano Resende
>> >>>SOA Opensource - Apache Tuscany
>> >>>-----------------------------------------------------
>> >>>
>> >>>
>> >>
>> >>
>> >>-------------------------------------------------------------------
>> >>-- 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
Re: DataObject/DataGraph Serialization & DataGraphRoot
Posted by Robbie Minshall <my...@gmail.com>.
Sounds like Frank's fix will fix your issue. It seems like this will be
sending the Type information along with the DataGraph ( good for dynamic env
but perhaps not great if your meta-data is pretty static )
If you write a simple SDO application to perform your current server side
reads then serialize the Types out as an XSD you then have your meta-data
which both the client and the server can have a copy and read in upon
initialization (or when needed) - this would just need to be done once. For
your real server side application you can then pass in the Type information
to the RDB DAS to avoid needing to dynamically create these types in the
future. If the client side inits SDO correctly, then reads in the types
defined in your XSD you should be fine.
Perhaps I have missed the point of the problem here - if so please feel free
to yell at me :-)
Robbie
On 9/5/06, Scott Kurinskas <sc...@gemstone.com> wrote:
>
> Hi All,
>
> I thought I'd check-in regarding the status of this request? Kevin was
> kind
> enough to log jira issue (http://issues.apache.org/jira/browse/TUSCANY-670
> ),
> but I'm blocked. Any chance there is a workaround available? I'd like to
> use the DAS for DB access, but would be willing to map to/from a XSD if
> that
> would eliminate the current problem.
>
> Thanks,
> Scott
>
> -----Original Message-----
> From: Kevin Williams [mailto:kevincbw@qwest.net]
> Sent: Friday, August 25, 2006 3:25 PM
> To: tuscany-user@ws.apache.org; tuscany-dev@ws.apache.org
> Subject: Re: DataObject/DataGraph Serialization & DataGraphRoot
>
> Hi Yang,
> Comments in line ...
>
> Yang ZHONG wrote:
>
> > You may need to serialize the generated SDO metadata. On the other
> > hand, I recommend the scenario design to be reconsidered.
> >
> > Thank Frank for suggesting a SDOUtil helper taking a list of Types for
> > DAS to serialize all generated Types along with DataGraph.
> > If you're willing to do that, I'll implement and send it out.
> >
> Yes. Please implement this method. If I understand correctly, the
> function
> exists today in EMF but we prefer to stay with SDO apis. Also, I am not
> sure why the method should take a list of generated Types since they exist
> in the graph already. So, why not a method something like
> this: serializeTypes() ?
>
> > At the same time, I have some thoughts on the scenario design.
> > DataBase schema is unlikely changed frequently, it's inefficient for
> > DAS to always generate same SDO metadata over and over again on every
> > single query, it's also inefficient to serialize same SDO metadata
> > over and over again on every single invocation back to client. A
> > typical customer scenario is, both client and server have SDO metadata
> > already, therefore SDO metadata serialization isn't really necessary,
> > and SDO metadata generation from DAS isn't really necessary. I know an
> > early version of DAS (it was under different name) can accept existing
> > SDO metadata and generate only SDO instances. My previous product
> > customers actually complained about the very poor performance caused
> > by repeating same SDO metadata generation and serialization.
> >
> > So, are you interested in trying such scenario so that you won't have
> > "type not found" problem?
> >
> > Solution 2-1 (typical real scenario):
> > 1. deploy SDO metadata to both client and server 2. instruct DAS to
> > accept the existing SDO metadata 3. do rest of whatever being done
> > right now
> >
> The DAS supports this scenario today and can accept Static Types from the
> client. But, the purely dynamic scenario is an important one so we must
> support both.
>
> Thanks!
>
> > Solution 2-2 (temporary if current DAS doesn't take any SDO metadata
> > yet) 1. deploy the generated SDO metadata from DAS to client, once 2.
> > do rest of whatever being done right now
> >
> > On 8/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> The RDB DAS creates the graph and corresponding Types dynamically
> >> from the database query results.
> >>
> >> Frank Budinsky wrote:
> >>
> >> >The problem seems to be that the metadata for class DataGraphRoot is
> >> not
> >> >registered on the client. Is that the only missing metadata? What
> >> >about the metadata for the rest of the model. I can't provide any
> >> >more help without more details about how the metadata is being
> defined.
> >> >
> >> >Frank.
> >> >
> >> >"Kevin Williams" <ke...@qwest.net> wrote on 08/25/2006 03:30:15 PM:
> >> >
> >> >
> >> >
> >> >>It may be that your remote client has not initialized the SDO/EMF
> >> >>environment properly and I think that we need some help from the
> >> >>SDO team. I have copied this to the dev list since not everyone
> >> >>has registered yet for the user list.
> >> >>
> >> >>--Kevin
> >> >>
> >> >>
> >> >>
> >> >>Luciano Resende wrote:
> >> >>
> >> >>
> >> >>
> >> >>>Hi Scott
> >> >>>
> >> >>> So, here is a quick example from our unit testings :
> >> >>>
> >> >>> /**
> >> >>> * Read a specific customer
> >> >>> */
> >> >>> public void testReadSingle() throws Exception {
> >> >>>
> >> >>> //Create and initialize command to read customers
> >> >>> DAS das = DAS.FACTORY.createDAS(getConnection());
> >> >>> Command readCustomers = das.createCommand("select * from
> >> >>>CUSTOMER where ID = 1");
> >> >>>
> >> >>> //Read
> >> >>> DataObject root = readCustomers.executeQuery();
> >> >>>
> >> >>> //Verify
> >> >>> assertEquals(1, root.getInt("CUSTOMER[1]/ID"));
> >> >>> }
> >> >>>
> >> >>>If you get a reference to root first, then try to access the
> >> >>>customer information, do you still have this problem ?
> >> >>>
> >> >>>Maybe something like this :
> >> >>>
> >> >>>DataObject root = readCust.executeQuery(); cust =
> >> >>>root.getDataObject("CUSTOMER")
> >> >>>
> >> >>>Please let me know if this helps...
> >> >>>
> >> >>>- Luciano
> >> >>>
> >> >>>
> >> >>>On 8/24/06, *Scott Kurinskas* <scott.kurinskas@gemstone.com
> >> >>><ma...@gemstone.com>> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> Now that my DAS example is up and running, I'm trying to move my
> >> >>> example to
> >> >>> a client/server environment and integrate it with my
> product. My
> >> >>> use-case
> >> >>> is very simple, a client makes a request to the server, the
> >> server
> >> >>> fetches
> >> >>> the result from the database and returns the DataObject back to
> >> >>> the client.
> >> >>> The server side code looks like the following:
> >> >>>
> >> >>> das = DAS.FACTORY.createDAS(getConfig("CompanyConfig.xml"),
> >> >>> connection);
> >> >>> String sql = "Select * from customers where
> >> >>> customers.customerNumber = " +
> >> >>> key;
> >> >>> Command readCust = das.createCommand(sql);
> >> >>> DataObject cust = readCust.executeQuery();
> >> >>> return cust;
> >> >>>
> >> >>> The code executes fine on the client but for some reason the
> >> >>> client is
> >> >>> throwing the exception below. The client should be
> >> >>> deserializing
> >> >>>
> >> >>>
> >> >the
> >> >
> >> >
> >> >>> response into a DataObject, but for some reason its complaining
> >> >>> about class
> >> >>> DataGraphRoot not found. The same code executing in a app works
> >> >>> great.
> >> >>>
> >> >>> Thoughts?
> >> >>>
> >> >>> Thanks again,
> >> >>> Scott
> >> >>>
> >> >>> Caught unexpected Exception
> >> >>> org.eclipse.emf.ecore.resource.Resource$IOWrappedException:Class
> >> >>> 'DataGraphRoot' not found.
> >> >>> (
> file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20
> >> >>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
> >> >>>
> >> >>>
> >> >>20&%20Cache%20
> >> >>
> >> >>
> >> >>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
> >> >>>
> >> >>>
> >> >>20&%20Cache%20>
> >> >>
> >> >>
> >> >>> Client/all.datagraph> &%20Cache%20Client/all.datagraph, 5, 22)
> >> >>> at
> >> >>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.
> >> >>>
> >> >>>
> >> >>handleErrors(XMLLoadImpl.java:80)
> >> >>
> >> >>
> >> >>> at
> >> >>>
> >> >>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java
> >> >>>
> >> >>>
> >> >:189)
> >> >
> >> >
> >> >>> at
> >> >>> org.apache.tuscany.sdo.util.
> >> >>>
> >> >>>
> >> >>DataGraphResourceFactoryImpl$DataGraphResourceIm
> >> >>
> >> >>
> >> >>> pl$LoadImpl.load(DataGraphResourceFactoryImpl.java:452)
> >> >>> at
> >> >>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.
> >> >>>
> >> >>>
> >> >>doLoad(XMLResourceImpl.java
> >> >>
> >> >>
> >> >>> :1
> >> >>> 79)
> >> >>> at
> >> >>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.
> >> >>>
> >> >>>
> >> >>load(ResourceImpl.java:1089
> >> >>
> >> >>
> >> >>> )
> >> >>> at
> >> >>> org.apache.tuscany.sdo.impl.
> >> >>>
> >> >>>
> >> >>DataGraphImpl$EDataGraphExternalizable.readExter
> >> >>
> >> >>
> >> >>> nal(DataGraphImpl.java:665)
> >> >>> at
> >> >>>
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
> >> >58)
> >> >
> >> >
> >> >>> at
> >> >>> java.io.ObjectInputStream.
> >> >>>
> >> >>>
> >> >>readOrdinaryObject(ObjectInputStream.java:1716)
> >> >>
> >> >>
> >> >>> at
> >> >>> java.io.ObjectInputStream.readObject0(ObjectInputStream.java
> >> >>>
> >> >>>
> >> >:1304)
> >> >
> >> >
> >> >>> at
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
> >> >
> >> >
> >> >>> at
> >> >>> org.apache.tuscany.sdo.helper.
> >> >>>
> >> >>>
> >> >>HelperProviderImpl$ResolvableImpl.readDataObje
> >> >>
> >> >>
> >> >>> ct(HelperProviderImpl.java:205)
> >> >>> at
> >> >>> org.apache.tuscany.sdo.helper.
> >> >>>
> >> >>>
> >> >>HelperProviderImpl$ResolvableImpl.readExternal
> >> >>
> >> >>
> >> >>> (HelperProviderImpl.java:144)
> >> >>> at
> >> >>> commonj.sdo.impl.ExternalizableDelegator.
> >> >>>
> >> >>>
> >> >>readExternal(ExternalizableDelegato
> >> >>
> >> >>
> >> >>> r.java:80)
> >> >>> at
> >> >>>
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
> >> >58)
> >> >
> >> >
> >> >>> at
> >> >>> java.io.ObjectInputStream.
> >> >>>
> >> >>>
> >> >>readOrdinaryObject(ObjectInputStream.java:1716)
> >> >>
> >> >>
> >> >>> at
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
> >> >
> >> >
> >> >>> at
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
> >> >
> >> >
> >> >>> at
> >> >>>
> >> >>>
> >> >>>
> >> >com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3
> >> >200)
> >>
> >> >
> >> >
> >> >>> at
> >> >>> com.gemstone.gemfire.internal.util.BlobHelper.
> >> >>>
> >> >>>
> >> >>deserializeBlob(BlobHelper.jav
> >> >>
> >> >>
> >> >>> a:55
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>--
> >> >>>-----------------------------------------------------
> >> >>>Luciano Resende
> >> >>>SOA Opensource - Apache Tuscany
> >> >>>-----------------------------------------------------
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>-------------------------------------------------------------------
> >> >>-- 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
>
>
--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/83388211@N00/sets/
* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517
* * * Number * * *
919-225-1553
Re: DataObject/DataGraph Serialization & DataGraphRoot
Posted by Kevin Williams <ke...@qwest.net>.
Hi Scott,
Brent just checked in RDB DAS changes to make use of the the new SDO
utility created for TUSCANY-670.
Can you try your app again with these latest changes and let us know how
it goes?
Thanks!
--Kevin
Scott Kurinskas wrote:
>Hi All,
>
>I thought I'd check-in regarding the status of this request? Kevin was kind
>enough to log jira issue (http://issues.apache.org/jira/browse/TUSCANY-670),
>but I'm blocked. Any chance there is a workaround available? I'd like to
>use the DAS for DB access, but would be willing to map to/from a XSD if that
>would eliminate the current problem.
>
>Thanks,
>Scott
>
>-----Original Message-----
>From: Kevin Williams [mailto:kevincbw@qwest.net]
>Sent: Friday, August 25, 2006 3:25 PM
>To: tuscany-user@ws.apache.org; tuscany-dev@ws.apache.org
>Subject: Re: DataObject/DataGraph Serialization & DataGraphRoot
>
>Hi Yang,
>Comments in line ...
>
>Yang ZHONG wrote:
>
>
>
>>You may need to serialize the generated SDO metadata. On the other
>>hand, I recommend the scenario design to be reconsidered.
>>
>>Thank Frank for suggesting a SDOUtil helper taking a list of Types for
>>DAS to serialize all generated Types along with DataGraph.
>>If you're willing to do that, I'll implement and send it out.
>>
>>
>>
>Yes. Please implement this method. If I understand correctly, the function
>exists today in EMF but we prefer to stay with SDO apis. Also, I am not
>sure why the method should take a list of generated Types since they exist
>in the graph already. So, why not a method something like
>this: serializeTypes() ?
>
>
>
>>At the same time, I have some thoughts on the scenario design.
>>DataBase schema is unlikely changed frequently, it's inefficient for
>>DAS to always generate same SDO metadata over and over again on every
>>single query, it's also inefficient to serialize same SDO metadata
>>over and over again on every single invocation back to client. A
>>typical customer scenario is, both client and server have SDO metadata
>>already, therefore SDO metadata serialization isn't really necessary,
>>and SDO metadata generation from DAS isn't really necessary. I know an
>>early version of DAS (it was under different name) can accept existing
>>SDO metadata and generate only SDO instances. My previous product
>>customers actually complained about the very poor performance caused
>>by repeating same SDO metadata generation and serialization.
>>
>>So, are you interested in trying such scenario so that you won't have
>>"type not found" problem?
>>
>>Solution 2-1 (typical real scenario):
>>1. deploy SDO metadata to both client and server 2. instruct DAS to
>>accept the existing SDO metadata 3. do rest of whatever being done
>>right now
>>
>>
>>
>The DAS supports this scenario today and can accept Static Types from the
>client. But, the purely dynamic scenario is an important one so we must
>support both.
>
>Thanks!
>
>
>
>>Solution 2-2 (temporary if current DAS doesn't take any SDO metadata
>>yet) 1. deploy the generated SDO metadata from DAS to client, once 2.
>>do rest of whatever being done right now
>>
>>On 8/25/06, Kevin Williams <ke...@qwest.net> wrote:
>>
>>
>>
>>>The RDB DAS creates the graph and corresponding Types dynamically
>>>from the database query results.
>>>
>>>Frank Budinsky wrote:
>>>
>>>
>>>
>>>>The problem seems to be that the metadata for class DataGraphRoot is
>>>>
>>>>
>>>not
>>>
>>>
>>>>registered on the client. Is that the only missing metadata? What
>>>>about the metadata for the rest of the model. I can't provide any
>>>>more help without more details about how the metadata is being defined.
>>>>
>>>>Frank.
>>>>
>>>>"Kevin Williams" <ke...@qwest.net> wrote on 08/25/2006 03:30:15 PM:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>It may be that your remote client has not initialized the SDO/EMF
>>>>>environment properly and I think that we need some help from the
>>>>>SDO team. I have copied this to the dev list since not everyone
>>>>>has registered yet for the user list.
>>>>>
>>>>>--Kevin
>>>>>
>>>>>
>>>>>
>>>>>Luciano Resende wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Scott
>>>>>>
>>>>>> So, here is a quick example from our unit testings :
>>>>>>
>>>>>> /**
>>>>>> * Read a specific customer
>>>>>> */
>>>>>> public void testReadSingle() throws Exception {
>>>>>>
>>>>>> //Create and initialize command to read customers
>>>>>> DAS das = DAS.FACTORY.createDAS(getConnection());
>>>>>> Command readCustomers = das.createCommand("select * from
>>>>>>CUSTOMER where ID = 1");
>>>>>>
>>>>>> //Read
>>>>>> DataObject root = readCustomers.executeQuery();
>>>>>>
>>>>>> //Verify
>>>>>> assertEquals(1, root.getInt("CUSTOMER[1]/ID"));
>>>>>> }
>>>>>>
>>>>>>If you get a reference to root first, then try to access the
>>>>>>customer information, do you still have this problem ?
>>>>>>
>>>>>>Maybe something like this :
>>>>>>
>>>>>>DataObject root = readCust.executeQuery(); cust =
>>>>>>root.getDataObject("CUSTOMER")
>>>>>>
>>>>>>Please let me know if this helps...
>>>>>>
>>>>>>- Luciano
>>>>>>
>>>>>>
>>>>>>On 8/24/06, *Scott Kurinskas* <scott.kurinskas@gemstone.com
>>>>>><ma...@gemstone.com>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Now that my DAS example is up and running, I'm trying to move my
>>>>>> example to
>>>>>> a client/server environment and integrate it with my product. My
>>>>>> use-case
>>>>>> is very simple, a client makes a request to the server, the
>>>>>>
>>>>>>
>>>server
>>>
>>>
>>>>>> fetches
>>>>>> the result from the database and returns the DataObject back to
>>>>>> the client.
>>>>>> The server side code looks like the following:
>>>>>>
>>>>>> das = DAS.FACTORY.createDAS(getConfig("CompanyConfig.xml"),
>>>>>> connection);
>>>>>> String sql = "Select * from customers where
>>>>>> customers.customerNumber = " +
>>>>>> key;
>>>>>> Command readCust = das.createCommand(sql);
>>>>>> DataObject cust = readCust.executeQuery();
>>>>>> return cust;
>>>>>>
>>>>>> The code executes fine on the client but for some reason the
>>>>>> client is
>>>>>> throwing the exception below. The client should be
>>>>>>deserializing
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>> response into a DataObject, but for some reason its complaining
>>>>>> about class
>>>>>> DataGraphRoot not found. The same code executing in a app works
>>>>>> great.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Thanks again,
>>>>>> Scott
>>>>>>
>>>>>> Caught unexpected Exception
>>>>>> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Class
>>>>>> 'DataGraphRoot' not found.
>>>>>> ( file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20
>>>>>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>20&%20Cache%20
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>20&%20Cache%20>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Client/all.datagraph> &%20Cache%20Client/all.datagraph, 5, 22)
>>>>>> at
>>>>>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>handleErrors(XMLLoadImpl.java:80)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> at
>>>>>>
>>>>>>org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>:189)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>> org.apache.tuscany.sdo.util.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>DataGraphResourceFactoryImpl$DataGraphResourceIm
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> pl$LoadImpl.load(DataGraphResourceFactoryImpl.java:452)
>>>>>> at
>>>>>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>doLoad(XMLResourceImpl.java
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> :1
>>>>>> 79)
>>>>>> at
>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>load(ResourceImpl.java:1089
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> )
>>>>>> at
>>>>>> org.apache.tuscany.sdo.impl.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>DataGraphImpl$EDataGraphExternalizable.readExter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> nal(DataGraphImpl.java:665)
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
>>>>58)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>> java.io.ObjectInputStream.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>readOrdinaryObject(ObjectInputStream.java:1716)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> at
>>>>>>java.io.ObjectInputStream.readObject0(ObjectInputStream.java
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>:1304)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>> org.apache.tuscany.sdo.helper.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>HelperProviderImpl$ResolvableImpl.readDataObje
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> ct(HelperProviderImpl.java:205)
>>>>>> at
>>>>>> org.apache.tuscany.sdo.helper.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>HelperProviderImpl$ResolvableImpl.readExternal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> (HelperProviderImpl.java:144)
>>>>>> at
>>>>>> commonj.sdo.impl.ExternalizableDelegator.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>readExternal(ExternalizableDelegato
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> r.java:80)
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
>>>>58)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>> java.io.ObjectInputStream.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>readOrdinaryObject(ObjectInputStream.java:1716)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3
>>>>200)
>>>>
>>>>
>>>>
>>>>
>>>>>> at
>>>>>> com.gemstone.gemfire.internal.util.BlobHelper.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>deserializeBlob(BlobHelper.jav
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> a:55
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>-----------------------------------------------------
>>>>>>Luciano Resende
>>>>>>SOA Opensource - Apache Tuscany
>>>>>>-----------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>-------------------------------------------------------------------
>>>>>-- 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
RE: DataObject/DataGraph Serialization & DataGraphRoot
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Scott,
We have an implementation that we're currently testing/debugging. We
should have it finished in the next couple of days.
Frank.
Scott Kurinskas <sc...@gemstone.com> wrote on 09/05/2006
09:40:06 PM:
> Hi All,
>
> I thought I'd check-in regarding the status of this request? Kevin was
kind
> enough to log jira issue
(http://issues.apache.org/jira/browse/TUSCANY-670),
> but I'm blocked. Any chance there is a workaround available? I'd like
to
> use the DAS for DB access, but would be willing to map to/from a XSD if
that
> would eliminate the current problem.
>
> Thanks,
> Scott
>
> -----Original Message-----
> From: Kevin Williams [mailto:kevincbw@qwest.net]
> Sent: Friday, August 25, 2006 3:25 PM
> To: tuscany-user@ws.apache.org; tuscany-dev@ws.apache.org
> Subject: Re: DataObject/DataGraph Serialization & DataGraphRoot
>
> Hi Yang,
> Comments in line ...
>
> Yang ZHONG wrote:
>
> > You may need to serialize the generated SDO metadata. On the other
> > hand, I recommend the scenario design to be reconsidered.
> >
> > Thank Frank for suggesting a SDOUtil helper taking a list of Types for
> > DAS to serialize all generated Types along with DataGraph.
> > If you're willing to do that, I'll implement and send it out.
> >
> Yes. Please implement this method. If I understand correctly, the
function
> exists today in EMF but we prefer to stay with SDO apis. Also, I am not
> sure why the method should take a list of generated Types since they
exist
> in the graph already. So, why not a method something like
> this: serializeTypes() ?
>
> > At the same time, I have some thoughts on the scenario design.
> > DataBase schema is unlikely changed frequently, it's inefficient for
> > DAS to always generate same SDO metadata over and over again on every
> > single query, it's also inefficient to serialize same SDO metadata
> > over and over again on every single invocation back to client. A
> > typical customer scenario is, both client and server have SDO metadata
> > already, therefore SDO metadata serialization isn't really necessary,
> > and SDO metadata generation from DAS isn't really necessary. I know an
> > early version of DAS (it was under different name) can accept existing
> > SDO metadata and generate only SDO instances. My previous product
> > customers actually complained about the very poor performance caused
> > by repeating same SDO metadata generation and serialization.
> >
> > So, are you interested in trying such scenario so that you won't have
> > "type not found" problem?
> >
> > Solution 2-1 (typical real scenario):
> > 1. deploy SDO metadata to both client and server 2. instruct DAS to
> > accept the existing SDO metadata 3. do rest of whatever being done
> > right now
> >
> The DAS supports this scenario today and can accept Static Types from
the
> client. But, the purely dynamic scenario is an important one so we must
> support both.
>
> Thanks!
>
> > Solution 2-2 (temporary if current DAS doesn't take any SDO metadata
> > yet) 1. deploy the generated SDO metadata from DAS to client, once 2.
> > do rest of whatever being done right now
> >
> > On 8/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> The RDB DAS creates the graph and corresponding Types dynamically
> >> from the database query results.
> >>
> >> Frank Budinsky wrote:
> >>
> >> >The problem seems to be that the metadata for class DataGraphRoot is
> >> not
> >> >registered on the client. Is that the only missing metadata? What
> >> >about the metadata for the rest of the model. I can't provide any
> >> >more help without more details about how the metadata is being
defined.
> >> >
> >> >Frank.
> >> >
> >> >"Kevin Williams" <ke...@qwest.net> wrote on 08/25/2006 03:30:15
PM:
> >> >
> >> >
> >> >
> >> >>It may be that your remote client has not initialized the SDO/EMF
> >> >>environment properly and I think that we need some help from the
> >> >>SDO team. I have copied this to the dev list since not everyone
> >> >>has registered yet for the user list.
> >> >>
> >> >>--Kevin
> >> >>
> >> >>
> >> >>
> >> >>Luciano Resende wrote:
> >> >>
> >> >>
> >> >>
> >> >>>Hi Scott
> >> >>>
> >> >>> So, here is a quick example from our unit testings :
> >> >>>
> >> >>> /**
> >> >>> * Read a specific customer
> >> >>> */
> >> >>> public void testReadSingle() throws Exception {
> >> >>>
> >> >>> //Create and initialize command to read customers
> >> >>> DAS das = DAS.FACTORY.createDAS(getConnection());
> >> >>> Command readCustomers = das.createCommand("select * from
> >> >>>CUSTOMER where ID = 1");
> >> >>>
> >> >>> //Read
> >> >>> DataObject root = readCustomers.executeQuery();
> >> >>>
> >> >>> //Verify
> >> >>> assertEquals(1, root.getInt("CUSTOMER[1]/ID"));
> >> >>> }
> >> >>>
> >> >>>If you get a reference to root first, then try to access the
> >> >>>customer information, do you still have this problem ?
> >> >>>
> >> >>>Maybe something like this :
> >> >>>
> >> >>>DataObject root = readCust.executeQuery(); cust =
> >> >>>root.getDataObject("CUSTOMER")
> >> >>>
> >> >>>Please let me know if this helps...
> >> >>>
> >> >>>- Luciano
> >> >>>
> >> >>>
> >> >>>On 8/24/06, *Scott Kurinskas* <scott.kurinskas@gemstone.com
> >> >>><ma...@gemstone.com>> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> Now that my DAS example is up and running, I'm trying to move
my
> >> >>> example to
> >> >>> a client/server environment and integrate it with my product.
My
> >> >>> use-case
> >> >>> is very simple, a client makes a request to the server, the
> >> server
> >> >>> fetches
> >> >>> the result from the database and returns the DataObject back
to
> >> >>> the client.
> >> >>> The server side code looks like the following:
> >> >>>
> >> >>> das = DAS.FACTORY.createDAS(getConfig("CompanyConfig.xml"),
> >> >>> connection);
> >> >>> String sql = "Select * from customers where
> >> >>> customers.customerNumber = " +
> >> >>> key;
> >> >>> Command readCust = das.createCommand(sql);
> >> >>> DataObject cust = readCust.executeQuery();
> >> >>> return cust;
> >> >>>
> >> >>> The code executes fine on the client but for some reason the
> >> >>> client is
> >> >>> throwing the exception below. The client should be
> >> >>> deserializing
> >> >>>
> >> >>>
> >> >the
> >> >
> >> >
> >> >>> response into a DataObject, but for some reason its
complaining
> >> >>> about class
> >> >>> DataGraphRoot not found. The same code executing in a app
works
> >> >>> great.
> >> >>>
> >> >>> Thoughts?
> >> >>>
> >> >>> Thanks again,
> >> >>> Scott
> >> >>>
> >> >>> Caught unexpected Exception
> >> >>> org.eclipse.emf.ecore.resource.Resource$IOWrappedException:
Class
> >> >>> 'DataGraphRoot' not found.
> >> >>> (
file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20
> >> >>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
> >> >>>
> >> >>>
> >> >>20&%20Cache%20
> >> >>
> >> >>
> >> >>> <file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
> >> >>>
> >> >>>
> >> >>20&%20Cache%20>
> >> >>
> >> >>
> >> >>> Client/all.datagraph> &%20Cache%20Client/all.datagraph, 5, 22)
> >> >>> at
> >> >>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.
> >> >>>
> >> >>>
> >> >>handleErrors(XMLLoadImpl.java:80)
> >> >>
> >> >>
> >> >>> at
> >> >>>
> >> >>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java
> >> >>>
> >> >>>
> >> >:189)
> >> >
> >> >
> >> >>> at
> >> >>> org.apache.tuscany.sdo.util.
> >> >>>
> >> >>>
> >> >>DataGraphResourceFactoryImpl$DataGraphResourceIm
> >> >>
> >> >>
> >> >>> pl$LoadImpl.load(DataGraphResourceFactoryImpl.java:452)
> >> >>> at
> >> >>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.
> >> >>>
> >> >>>
> >> >>doLoad(XMLResourceImpl.java
> >> >>
> >> >>
> >> >>> :1
> >> >>> 79)
> >> >>> at
> >> >>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.
> >> >>>
> >> >>>
> >> >>load(ResourceImpl.java:1089
> >> >>
> >> >>
> >> >>> )
> >> >>> at
> >> >>> org.apache.tuscany.sdo.impl.
> >> >>>
> >> >>>
> >> >>DataGraphImpl$EDataGraphExternalizable.readExter
> >> >>
> >> >>
> >> >>> nal(DataGraphImpl.java:665)
> >> >>> at
> >> >>>
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
> >> >58)
> >> >
> >> >
> >> >>> at
> >> >>> java.io.ObjectInputStream.
> >> >>>
> >> >>>
> >> >>readOrdinaryObject(ObjectInputStream.java:1716)
> >> >>
> >> >>
> >> >>> at
> >> >>> java.io.ObjectInputStream.readObject0(ObjectInputStream.java
> >> >>>
> >> >>>
> >> >:1304)
> >> >
> >> >
> >> >>> at
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
> >> >
> >> >
> >> >>> at
> >> >>> org.apache.tuscany.sdo.helper.
> >> >>>
> >> >>>
> >> >>HelperProviderImpl$ResolvableImpl.readDataObje
> >> >>
> >> >>
> >> >>> ct(HelperProviderImpl.java:205)
> >> >>> at
> >> >>> org.apache.tuscany.sdo.helper.
> >> >>>
> >> >>>
> >> >>HelperProviderImpl$ResolvableImpl.readExternal
> >> >>
> >> >>
> >> >>> (HelperProviderImpl.java:144)
> >> >>> at
> >> >>> commonj.sdo.impl.ExternalizableDelegator.
> >> >>>
> >> >>>
> >> >>readExternal(ExternalizableDelegato
> >> >>
> >> >>
> >> >>> r.java:80)
> >> >>> at
> >> >>>
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
> >> >58)
> >> >
> >> >
> >> >>> at
> >> >>> java.io.ObjectInputStream.
> >> >>>
> >> >>>
> >> >>readOrdinaryObject(ObjectInputStream.java:1716)
> >> >>
> >> >>
> >> >>> at
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
> >> >
> >> >
> >> >>> at
> >> >>>
> >> >>>
> >> >java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
> >> >
> >> >
> >> >>> at
> >> >>>
> >> >>>
> >> >>>
> >> >com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3
> >> >200)
> >>
> >> >
> >> >
> >> >>> at
> >> >>> com.gemstone.gemfire.internal.util.BlobHelper.
> >> >>>
> >> >>>
> >> >>deserializeBlob(BlobHelper.jav
> >> >>
> >> >>
> >> >>> a:55
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>--
> >> >>>-----------------------------------------------------
> >> >>>Luciano Resende
> >> >>>SOA Opensource - Apache Tuscany
> >> >>>-----------------------------------------------------
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>-------------------------------------------------------------------
> >> >>-- 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