-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
HHH-16058 Removing Environment#getBytecodeProvider #5977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@yrodiere would you like to review this one? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well that does looks dangerous, but I guess we like to live dangerously :) A few comments below.
By the way, does this also solve https://hibernate.atlassian.net/browse/HHH-12193 ?
| public EnhancingClassTransformerImpl(EnhancementContext enhancementContext) { | ||
| Objects.requireNonNull( enhancementContext ); | ||
| this.enhancementContext = enhancementContext; | ||
| this.bytecodeProvider = BytecodeProviderInitiator.buildDefaultBytecodeProvider(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't that possibly introducing another problem? You won't be using the same bytecode provider as Hibernate ORM...
But I must admit I don't know what this class is used for anyway :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is used by JPA's "enhance at deployment time" capability, used on EE servers.
And yes I'd like to make the BytecodeProvider implementation pluggable, but it really isn't today: choices are exclusively bytebuddy or none. Clearly this use case can't use none.
(there are other areas too in which it's implied that it needs to be the ByteBuddy one - I'd certainly like to improve that but I'm considering that a different issue)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And yes I'd like to make the BytecodeProvider implementation pluggable
I was thinking more that you're not using the same instance of BytecodeProvider, whereas before this patch, you were. I have no idea what kind of impact this can have, but since the bytecode provider is stateful, it might be a problem?
| private final EnhancementContext enhancementContext; | ||
| private final BytecodeProvider bytecodeProvider; | ||
|
|
||
| public EnhancingClassTransformerImpl(EnhancementContext enhancementContext) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is something weird going on.
This constructor is only ever called from here:
Lines 111 to 114 in a986a38
| @Override | |
| public void pushClassTransformer(EnhancementContext enhancementContext) { | |
| persistenceUnitInfo.addTransformer( new EnhancingClassTransformerImpl( enhancementContext ) ); | |
| } |
But then all implementations of PersistenceUnitInfo#addTransformer are no-ops...
This component is probably not being tested. I'd suggest trying your patch in WildFly before merging?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, yes WildFly has a similar implementation but it's a different one.
| //we're going to need the UUID even if we the SessionFactory configuration doesn't | ||
| // allow any operations on it, as we need it to match deserialized objects with | ||
| // the originating SessionFactory: at very least it's useful to actually get | ||
| // such configuration, so to know if such operation isn't allowed or configured otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you've changed the purpose of this method; maybe it should be renamed?
I don't know if this class is API or "looks like API but actually is not", though...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I've amended the javadoc to clarify.
| } | ||
|
|
||
| private static SessionFactoryImplementor retrieveMatchingSessionFactory(final String sessionFactoryUuid) { | ||
| Objects.requireNonNull( sessionFactoryUuid ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We won't be able to deserialize entities serialized before this patch, since the uuid will be missing.
Not sure what the backwards compatibility expectations of serialization are, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The UUID was always supposed to be there in practice - I only noticed this wasn't happening consistently because we have some proxy serialization tests which were performing this while in the odd configuration of not having set the sessionFactoryUuid first.
However in a "real" scenario this would have failed as the proxy can't be initialized.
hibernate-core/src/main/java/org/hibernate/proxy/pojo/bytebuddy/SerializableProxy.java
Outdated
Show resolved
Hide resolved
...testing/src/main/java/org/hibernate/testing/bytecode/enhancement/BytecodeEnhancerRunner.java
Show resolved
Hide resolved
Right, thanks for finding that one. |
|
Thanks for your pull request! This pull request appears to follow the contribution rules. › This message was automatically generated. |
|
pushed a reviewed version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. LGTM as long as you're confident about the impact on EnhancingClassTransformerImpl.java and WildFly.
EDIT: And serialization :)
|
👍 still checking WildFly, will merge if I spot no issues there. |
|
All good on the WildFly side - if we bypass the lack of an upodated Infinispan 2LC module. Merging |
https://hibernate.atlassian.net/browse/HHH-16058
cc/ @sebersole and @DavideD for awareness