Re: XSD2Java-generated interfaces are not Serializable
Hi Ron, OK, I just made your suggested change (revision 436855). We'll see if anyone complains :-) Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 08/23/2006 07:36:31 PM: Hi Frank, Yes, that would solve the problem. My only concern is that -interfaceDataObject is proposed as an optional flag. If it isn't specified, I think the generated interfaces should extend Serializable nevertheless. All types of Data Transfer Objects, including SDO DataObjects, should be Serializable. - Ron Frank Budinsky wrote: Hi Ron, Would the feature described in TUSCANY-254 be acceptable, or is that more than you want. Frank. Ron Gavlin [EMAIL PROTECTED] wrote on 08/23/2006 03:32:52 PM: Hi Frank, Now that you have returned from vacation, do you have any thoughts on this issue? FYI, the session bean in question is a remote session bean. Thanks in advance, - Ron - Original Message From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user tuscany-user tuscany-user@ws.apache.org Sent: Monday, August 14, 2006 12:44:08 PM Subject: XSD2Java-generated interfaces are not Serializable Greetings, I have a session bean that includes XSD2Java-generated interfaces as return types and method parameters. My appserver complains that these interfaces are not Serializable. The XSD2Java-generated implementation classes are indeed serializable. How should this problem be solved...should XSD2Java make these interfaces extend Serializable or do I need to specify the implementation classes as return types and method parameters? - Ron - 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]
Re: DataObject/DataGraph Serialization DataGraphRoot
Hi Scott, It seems the Types are not available to the deserializer on the client. I think one of the options for SDO is to include the Types as part of the serialized graph. I will check into this and get back to you soon. --Kevin Scott Kurinskas wrote: Hi Luciano, I implemented the following and it continues to complain about the Class 'DataGraphRoot' not found. DataObject cust = readCust.executeQuery(); DataObject inst = cust.getDataObject(customers[1]); logger.info(LOADER::--:: custName = + inst.getString(customerName)); return inst; The customer name attribute is printing out in my server's log files and to the best of my ability the server is serializing the DataObject and delivering it to the client. The problem seems to be on my client when its trying to deserialize it back to a DataObject (at least this is what I'm thinking the problem is). I'll check with my engineering team to see if they can see if our code is causing any issues, but since DataObject implementes Serializable, I do not see I'd be having issues. I've run similar tests with sreializable pojos without issue. Thanks for the help! Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DataObject/DataGraph Serialization DataGraphRoot
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 [EMAIL PROTECTED] 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* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 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:1758)
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:1758)
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
