Quarkus: HibernateProxy at runtime is not allowed when the configured BytecodeProvider

[rafaelkloss]

Describe the bug
When run the native image, the hibernate can't load the proxy

Expected behavior
Load proxy of all collections and lazy relations

Actual behavior
Throw exception -> HibernateProxy instances at runtime is not allowed when the configured BytecodeProvider is 'none'; your model requires a more advanced BytecodeProvider to be enabled.

To Reproduce
Steps to reproduce the behavior:

1. Get the reproducer project https://github.com/rafaelkloss/quarkus-many-to-one-error
2. config the application resources (database postgres)
3. generate native image -> docker build --build-arg version=homolog -t bug-proxy .
4. docker run image -> docker run -it --rm --name bug-proxy -p 8080:8080 bug-proxy
5. make a get to http://localhost:8080/v1/feedback/create-project (create a project with a lot of relations)
6. make a get to http://localhost:8080/v1/feedback/error-proxy to get project above, the error throw

Additional context
This is a recurrent issue after quarkus 0.22.0

[rafaelkloss]

The stacktrace

[gsmet]

/cc @Sanne

[deejcheeze]

Experiencing the same issue when I attempt to fetch a parent class of an Inheritance (JOINED) strategy. Works fine when I run outside native mode, but once I build my native image and test the issue resurfaces.

I've read Quarkus already configures all bytecode enhancement options, so why does the error say _BytecodeProvider is 'none'_ ?

Using Quarkus ver 0.28.1

[rafaelkloss]

Hi Diyan, thanks for your contribution, in my case also works fine outside native mode.
We have similar models, using inheritance joined strategy.
About error, i feel stack is incorrectly.
=x=
If you rollback to Quarkus 0.21, works fine even in native mode.

[deejcheeze]

Wow! Thanks for the heads-up.
Unfortunately we updated to 28.1 due to an issue with CORS headers not returned on authorization exceptions which was only fixed in more recent versions.

It's funny how this seems to be the only report of this on the web from my search. Any idea on a timeline for getting this fixed?

[gsmet]

@dreab8 @Davide would anyone of you be able to check why we need the proxy and how we could solve this?

FTR, proxies are completely disabled in Quarkus but if some features really need them, we might have to reconsider.

Thanks.

[dreab8]

Hi @gsmet , that are one case where we create a proxy and it is when we have an association and the target entity has subclasses this to avoid an extra query which would be necessary to determine the exact subclass to instantiate.

[gsmet]

@Sanne how should we handle that?

This is the second time we see a need for proxies in valid use cases (Envers being the other one). Should we relax this and allow proxies somehow now that we understand a bit more how they can be used in GraalVM?

[rafaelkloss]

The issue is the "main" issue of other serious bugs in my api today (i think).
All business rules that depends of this point of model, doesn't work.

[rafaelkloss]

Like this -> https://github.com/quarkusio/quarkus/issues/4377 where existent object is like a "new" object

[Sanne]

@gsmet :

This is the second time we see a need for proxies in valid use cases (Envers being the other one). Should we relax this and allow proxies somehow now that we understand a bit more how they can be used in GraalVM?

We can not "relax" much as the usage of Byte Buddy within native-image is impossible. If it's "just" a normal proxy then we could relax it - as long as the need for it is identified at build time, both of these are unclear to me now (I couldn't debug this one yet).

I guess it's possible that ORM throws this error related to BytecodeProvider is 'none' even though it's not really needing to use a bytecode provider.

@deejcheeze :

I've read Quarkus already configures all bytecode enhancement options, so why does the error say _BytecodeProvider is 'none'_ ?

Quarkus differentiates the "augmentation" phase from the bootstrap phase. The augmentation happens during the build, it's one of the transformation phases applied by the Quarkus build plugins: in this phase the BytecodeProvider is enabled (and enforced) using ByteBuddy so to generate the enhanced bytecode, but then at actual bootstrap the BytecodeProvider is disabled as supposedly there is no more need for it (apparently I forgot some cases, hence the bug).

More importantly, we really need to make sure that everything works without the dynamic bytecode as otherwise we wouldn't be able to generate valid native-images. It's also nice for non-native deploymens: dependencies such as Byte Buddy become "build time only" and don't need to be shipped into production images, that saves memory, bootstrap times, and make security people happy for less things to monitor as one ships less libraries.

[deejcheeze]

@Sanne ok this makes a lot of sense and explains alot.
Though I doubt it could be this simple, but is the solution then to generate the enhanced bytecode for the forgotten use-cases?

Is there a known work-around? I found out that declaring join column relationships with the protected access modifier helped in some cases, but not in this specific example I cited above. Are there other known _hacks_ ??..

[rafaelkloss]

Hi @deejcheeze do you found any other workaround for this, while wait for solve ?

[rafaelkloss]

Hi guys, any update on this ?

[Sanne]

hi @rafaelkloss , didn't forget about this one but I won't be able to work on this for a couple of weeks yet: just back from holidays, and need to catch up with other things first.

@deejcheeze :

@Sanne ok this makes a lot of sense and explains alot.
Though I doubt it could be this simple, but is the solution then to generate the enhanced bytecode for the forgotten use-cases?

Yes I suspect it might be simple, I just need to trace back which enhancer is failing and make sure it's run upfront.

Is there a known work-around? I found out that declaring join column relationships with the protected access modifier helped in some cases, but not in this specific example I cited above. Are there other known _hacks_ ??..

I don't know :)

[rafaelkloss]

Tks @Sanne :)

[Sanne]

Thanks for the reproducer, I managed to see what is going on in native-image and opened https://hibernate.atlassian.net/browse/HHH-13804

[rafaelkloss]

any chance to fix this on 1.3.0 ?

[Sanne]

yes I hope so. I had to put this on hold for a while, but I'm back working on it now.

It's rather complex, I'm trying to not have to revisit the whole boot of the ORM :)

[Sanne]

I have a solution for this, we'll release Hibernate ORM 5.4.11.Final soon and then need to send a PR for Quarkus.

[rafaelkloss]

Tanks a lot @Sanne !