[hibernate-dev] [feature request][discuss] smoother serializers integration?

Romain Manni-Bucau rmannibucau at gmail.com
Wed Apr 19 04:51:07 EDT 2017

Hi guys,

Short sumarry: Wonder if hibernate could get a feature to kind of either
unproxy or freeze the entities once leaving the managed context to avoid
uncontrolled lazy loading on one side and serialization issues on another

Use case example: a common example is a REST service exposing directly
hibernate entities (which is more and more common with microservice

Objective: the goal is to not need any step - or reduce them a lot -
between the hibernate interaction and a potential serialization to avoid
issues with lazy loading and unexpected loading. Today it requires some
custom and hibernate specific logic in the serializer which kind of breaks
the transversality of the two concerns (serialization and object

Implementation options I see:

1. a callback requesting if the lazy relationship should be fetched,
something like

public interface GraphVisitor {
    boolean shouldLoad(Object rootEntity, Property property);

2. An utility to remove any proxy potentially throwing an exception and
replacing the value by null or an empty collection, something like

MyEntity e = Hibernate.deepUnproxy(entity);

3. A switch of the proxy implementation, this is close to 2 but wouldn't
require a call to any utility, just a configuration in the persistence unit.

Side note: of course all 3 options can be mixed to create a single solution
like having 3 implemented based on 1 for instance.

Configuration proposal: this would be activated through a property in the
persistence unit (this shouldn't be only global IMHO cause otherwise you
can't mix 2 kind of units, like one for JSF and one for JAX-RS to be
concrete). This should also be activable as a query hint i think - but more
a nice to have.

What this feature wouldn't be responsible for: cycles. If relationships are
bidirectional then the unproxied entity would still "loop" if you browse
the object graph - this responsability would stay in the consumer since it
doesn't depend on hibernate directly but more on a plain object handling.

What do you think?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory

More information about the hibernate-dev mailing list