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...
>>
>>