In my case, I think a more selective filtering than an all or nothing
approach would be preferable, perhaps by annotating fields to follow/not to
follow, similar to @XmlTransient in JAXB. But that wouldn't solve the case
where you don't have control over the source of the classes. I'm guessing
this could quickly lead to a fairly elaborate schema, like Jackson's
serialize/deserialize solution, where you have very fine grained control
even over 3rd party classes. I haven't started using this seriously yet, so
I'm hesitant to have a firm opinion yet, but it is quite convenient to use
entity beans as results of @GET methods to avoid repeating properties.
2011/7/11 Jakub Podlesak <jakub.podlesak_at_oracle.com>
> Hi Daniel,
>
> You are right. Currently there is no way to disable member field
> reference processing. But that should be easy to implement using a special
> resource configuration feature in an "all or nothing manner".
>
> Would that be something helpful for your use-case?
> Or if what you need is a "smarter" approach, could you please
> try to elaborate on how to distinguish the "to be followed" references
> from the rest?
>
> ~Jakub
>
>
> On 07/06/2011 03:39 PM, Daniel Larsson wrote:
>
>> Tried out jersey-server-linking a bit, and noticed the RefProcessor
>> recursively chases object references in the entity object, trying to find
>> @Link annotations. This is causing a bit of a problem for me. Part of the
>> returned entity is a JPA entity bean, where I've filtered out certain
>> properties (don't want to send the transitive closure of the object graph
>> back as JSON, so I'm typically marking object references with @XmlTransient,
>> and adding properties returning URIs instead, which are included in the JSON
>> output). But since the JPA entity is part of the Jersey Response entity,
>> *every* object reference is chased, causing tons of SQL queries to be
>> performed, to bring in those objects into memory. Not fun. I couldn't see a
>> way to influence the reference chasing, is this correct? In other words, I
>> will need to make a proxy for the JPA entity, only exposing the subset of
>> the JPA bean properties I actually want to serialize, yes?
>>
>> Thanks in advance,
>>
>> Daniel Larsson
>>
>
>