felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Leangen <o...@leangen.net>
Subject Re: [jira] [Commented] (FELIX-5325) Patch for embedded DTO (in DTO)
Date Thu, 18 Aug 2016 12:26:14 GMT

David D.,

No! You just need to copy the DTO. Let the client do whatever it wants with the DTO; it won’t
mess up the system. If the client is “stupid” enough to change the value of the DTO, then
that’s the client’s problem.

There is no more worry about immutability / value object. There are only copies of objects.

BTW, that is why I suggested that we add a copy() method.

It does take a change of mindset. I also came from the School of Immutable Objects. But copying
objects works, too.


> On Aug 18, 2016, at 9:16 PM, David Daniel <david.daniel.1979@gmail.com> wrote:
> 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 <david.daniel.1979@gmail.com>
> 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 <
>> david.bosschaert@gmail.com> 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 <osgi@leangen.net> 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 <
>>> david.daniel.1979@gmail.com>
>>>> 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) <
>>> jira@apache.org>
>>>>> 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)

View raw message