I agree
On Mon, Apr 13, 2015 at 9:27 AM, Martin Vojtek <voytoo_at_gmail.com> wrote:
> I think that in terms of XmlAccessType, JSON-B should support
> PUBLIC_MEMBER by default. According to discussion in this thread, I suppose
> it is choice we could agree upon. The behavior will be customizable.
>
> MartinV
>
> On Mon, Apr 13, 2015 at 8:50 AM, Przemyslaw Bielicki <pbielicki_at_gmail.com>
> wrote:
>
>> Not sure it's a good use case. On the one hand avoiding unnecessary
>> adapters and data copying is always good, on the other hand mixing aspects
>> may cause issues. In JPA, having parent-child relationship is common and
>> this can easily lead to "com.sun.istack.SAXException2: A cycle is detected
>> in the object graph. This will cause infinitely deep XML". More so, JPA
>> objects are proxied, so the only way to access class' data is using
>> accessor methods.
>>
>> Anyway, I agree that a discussion in this thread became a bit religious ;)
>>
>> I would assume that each application uses separate layer for accessing
>> database, sending/receiving data over the wire, yet another for displaying
>> info in the UI, etc.
>>
>> I also dare to say that encapsulation, coding practices is not the
>> business of this JSR. Don't get me wrong I agree with most comments about
>> advantages of immutable classes, encapsulation etc., however it's not
>> JSON-B's job to enforce this. We must fit into existing ecosystem
>> seamlessly whether developers use private fields with setters/getters, or
>> just public/protected/default scope fields. That's why I like
>> https://docs.oracle.com/javaee/6/api/javax/xml/bind/annotation/XmlAccessType.html
>> - it's completely flexible with reasonable default.
>>
>>
>> 11 kwi 2015 9:16 PM "Romain Manni-Bucau" <rmannibucau_at_tomitribe.com>
>> napisał(a):
>>
>>> Forgot to mention something super important: what will be the first
>>> usage at EE level? Retirning a JPA entity in a JAX-RS service IMO so being
>>> super close to JPA can be nice - wonder about lazy relationships btw...
>>>
>>>
>