[ 
https://issues.apache.org/jira/browse/TUSCANY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531727
 ] 

Kelvin Goodson commented on TUSCANY-1493:
-----------------------------------------

I've been going through the files in preparation for putting them into the code 
base somewhere,  and have been adding apache license headers to the files that 
have no headers,  on the basis of the license you granted when attaching the 
zip files.  There are about 10 files in the archives which have Agfa copyright 
headers in them (e.g. ExtendablePropertyAccessBuilder.java), saying that . ...
//       THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF
//                    Agfa-Gevaert Group

 I don't feel it's right for me to remove those headers,  although I guess that 
would be in the spirit of the submission.  Could you please search for files 
with similar headers to that file, fix the headers as you see fit, and resubmit 
any files you wish to be included in the submission.

> Snapshot mapping framework to convert DataObjects to and from Java objects
> --------------------------------------------------------------------------
>
>                 Key: TUSCANY-1493
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1493
>             Project: Tuscany
>          Issue Type: New Feature
>          Components: Java SDO Implementation
>            Reporter: bert.robben
>             Fix For: Java-SDO-Next
>
>         Attachments: sdo-snapshot.zip, sdo.zip
>
>
> We're developing 3-tier applications with a  swing client, JBoss app server 
> and a couple of databases in the back-end. We use sdo as mechanism to 
> exchange data between our client and our server. On the server side we have a 
> fairly complex implementation based partially on Hibernate pojo's, partially 
> on an inhouse legacy persistency system. The legacy part (although written in 
> Java) is very hard to change. In this environment we often need to convert 
> between data objects and server side objects (typically, but not always at a 
> transition from server to client or vice versa). 
> To support this we developed a mapping framework that allows us to convert 
> data between SDO and ordinary Java objects. This framework defines a number 
> of important concepts.
> - A snapshot is an opaque collection of structured data at a given moment in 
> time. It is opaque in the sense that the data inside can't be accessed 
> directly.
> - A Mapper is an interface that defined how data can be accessed from an 
> object. We have implementations for SDO DataObjects, normal Java POJO's 
> (following java beans convention). hibernate pojos, and support for 
> customizing this to access any kind of object (as we need for instance for 
> our legacy objects).
> - We defined a DataAccessService (sorry for the confusing name) that given a 
> mapper and some objects can create a snapshot. Given a snapshot and a mapper 
> it can instantiate new objects. As such we can convert data to and from data 
> objects very easily.
> This framework is part of our in-house developed implementation of the SDO 
> spec. We want to share our code and experience with the open-source 
> community. As such, Frank Budinsky proposed that we make JIRA request for 
> this to start the discussion. 
> I'll attach the core classes for this feature to this JIRA. At this moment 
> I'm not making the entire code available because we implemented more than one 
> additional feature (I'll add some more JIRA over the next days) and I'd like 
> to have a more focussed discussion. Also, at this moment in time some smaller 
> parts of implementation (for instance the hibernate integration) are still 
> implemented as a specialization of our SDO implementation. As such they can't 
> be built outside of the rest of our application (which is not open-sourced). 
> However this is just a matter of finding enough time to move them to our sdo 
> component.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to