So for the article above what I am struggling with is how to do immutability/mutability with the DTO spec. With java beans there is a get and set method for each attribute. If DTO's had this the way I would do it is as follows. I would have an attribute for mutability that is either true or false. If false I would put an aspect around the get function that returns a clone of the attribute value. I would put an aspect around the set function that throws an exception. For mutable DTO's my converter would delegate deserialization to a CRDT service that would put aspects around set that watches for changes and aspects around get/set that throws an exception if called when the DTO is in a conflicted state. The CRDT service would then return the DTO to the converter. On update it modifies the CRDT structure as above. In the converter if the DTO is watched then when serializing it delegate serialization to the CRDT service. I am not sure how to model immutability with the current DTO standard because there are no get or set functions that I can put aspects around.
On Thu, Aug 18, 2016 at 6:40 AM, David Daniel <[email protected]> wrote: > For me helps by having the schema that allows for something some other > service uses to do the automatic merging using the tools available in > dosgi, but I understand that nothing can be really automatic because it can > require merges and there is garbage collection that will need to happen on > the objects during reconciliation. If the DTO's are just public fields > they do not offer anything over using a pojo. Where they start to be > useful to me is by defining in a standard way how the data can be turned > into an object. Examples would be a way to define a key so that indexes > and equality can be determined, or defining relationships between sub > objects so when doing a deep clone the user can decide how many links to > traverse. Scoping rules could also be defined so the converter has > information that could be used in determining which type of object to > serialize to in different situations. The standard can choose not to > define these things and let the application decide in order to be more > flexible or it can try to define some of these things in order to make > services or tools around DTO's more standardized. I think I am trying to > follow what schema elements will be in DTO's and make sure that I take > advantage of them rather than writing my own. As of right now that I am > just using them as pojo's though so I don't have any feelings or advice on > the way to go and what types of schema things I would be able to take > advantage of. > > On Thu, Aug 18, 2016 at 4:23 AM, David Bosschaert < > [email protected]> wrote: > >> Hi Davids, >> >> What is it exactly from that article that you think would make sense in >> the >> context of OSGi? The automatic merging of concurrent data updates? >> >> Thanks, >> >> David >> >> On 18 August 2016 at 07:50, David Leangen <[email protected]> wrote: >> >> > >> > That is interesting, indeed! I only quickly skimmed through the article, >> > but it does indeed appear to be a potentially interesting property for >> > dosgi. >> > >> > If I believe what the authors write in the abstract, it provides a >> > relatively simple and deterministic method that could be implemented in >> > code. >> > >> > Cheers, >> > =David >> > >> > >> > > On Aug 17, 2016, at 10:21 PM, David Daniel < >> [email protected]> >> > wrote: >> > > >> > > read an interesting article this morning >> http://arxiv.org/abs/1608.03960 >> > > Something like this would be an interesting property to have for dosgi >> > > which is one of the use cases for DTO's >> > > >> > > On Wed, Aug 17, 2016 at 6:47 AM, David Leangen (JIRA) < >> [email protected]> >> > > wrote: >> > > >> > >> >> > >> [ https://issues.apache.org/jira/browse/FELIX-5325?page= >> > >> com.atlassian.jira.plugin.system.issuetabpanels:comment- >> > >> tabpanel&focusedCommentId=15424288#comment-15424288 ] >> > >> >> > >> David Leangen commented on FELIX-5325: >> > >> -------------------------------------- >> > >> >> > >> Awesome. Thank you! :-) >> > >> >> > >>> Patch for embedded DTO (in DTO) >> > >>> ------------------------------- >> > >>> >> > >>> Key: FELIX-5325 >> > >>> URL: https://issues.apache.org/jira >> /browse/FELIX-5325 >> > >>> Project: Felix >> > >>> Issue Type: Improvement >> > >>> Components: Converter >> > >>> Reporter: David Leangen >> > >>> Assignee: David Bosschaert >> > >>> Priority: Minor >> > >>> Attachments: patch.diff >> > >>> >> > >>> >> > >>> This patch adds support for converting a DTO that contains an >> embedded >> > >> DTO. It uses recursive calls to Converter.convert() to accomplish >> this. >> > >> >> > >> >> > >> >> > >> -- >> > >> This message was sent by Atlassian JIRA >> > >> (v6.3.4#6332) >> > >> >> > >> > >> > >
