PR: https://github.com/hibernate/hibernate-orm/pull/2825
On Thu, Mar 28, 2019 at 1:49 PM Gail Badner wrote:
> Hi Guillaume,
>
> I've confirmed that my fix gets the WildFly tests to pass. I've created
> https://hibernate.atlassian.net/browse/HHH-13343.
>
> I'm not sure I understand what you are s
Hi Guillaume,
I've confirmed that my fix gets the WildFly tests to pass. I've created
https://hibernate.atlassian.net/browse/HHH-13343.
I'm not sure I understand what you are suggesting by "default behavior".
My proposed fix implements a ClassFileLocator checks if the bytecode
Hibernate is attem
Hi Gail,
Thanks for looking into this.
Your commit is interesting as we had people in Quarkus complaining about
the fact that it was not possible to chain the ORM enhancer after other
enhancers as it didn't consider the provided bytes as the "source" to
consider.
I wonder if what you did (i.e. c
Hi Guillaume,
Unfortunately, it is not so easy.
typeDescription is of type
TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get
completely resolved until later.
I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here is
the commit [2].
I haven't had a cha
Guillaume, thanks for the suggestion. I'll give it a try...
On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet
wrote:
> I would try changing the start of EnhancerImpl#enhance() to:
> ===
> public byte[] enhance(String className, byte[] originalBytes) throws
> EnhancementException {
>
I would try changing the start of EnhancerImpl#enhance() to:
===
public byte[] enhance(String className, byte[] originalBytes) throws
EnhancementException {
//Classpool#describe does not accept '/' in the description name as
it expects a class name. See HHH-12545
final Strin
Thinking more about this, I don't think that ByteBuddy should be able to
do a classloader.getResource() on the class that is being defined
(SLSBPersistenceContexts$$$view5.class). It might be correct for the
getResource call to return null, until after the class is completely
defined.
Would i
Hi Tomek,
I think the pending question now is why ByteBuddy is getting a null
result from the
classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
call.
We have also seen failures for
org.jboss.as.ejb3.SerializationProxyHackImplemen
Adding Tomek + Cheng, as they have been working on the WildFly EJB layer
recently, which seems to use
https://github.com/jbossas/jboss-classfilewriter for generating the EJB
stub classes like
org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
Perhaps Tomek or Cheng,
>
>
> >
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57
We should try to recreate without WildFly, perhaps hacking the
SerializationHackProxy code into a Hibernate unit test or ByteBuddy test,
could be our next step
Actually, the generated SerializationProxyHackImplementation class looks
to be generated with the application classloader. I assume the same is
true for the $$$view5.class.
On 3/22/19 4:01 PM, Gail Badner wrote:
> Should dynamically generated classes be possible to load from a
> ClassLoader by
Should dynamically generated classes be possible to load from a ClassLoader
by a name like
org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class
?
On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow wrote:
>
> On 3/22/19 1:53 PM, Gail Badner wrote:
> > I just wanted to clarify
On 3/22/19 1:53 PM, Gail Badner wrote:
> I just wanted to clarify that sometimes I was seeing problems with
> SerializationProxyHackImplementation. When debugging, I usually saw a
> failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1
> and 9.
I'm guessing that the SLSBPers
I just wanted to clarify that sometimes I was seeing problems with
SerializationProxyHackImplementation. When debugging, I usually saw a
failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1
and 9.
On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow wrote:
>
>
> On 3/22/19 10:08 AM,
On 3/22/19 10:08 AM, Scott Marlow wrote:
>
>
> On 3/22/19 9:24 AM, Scott Marlow wrote:
>>
>>
>> On 3/22/19 9:11 AM, Scott Marlow wrote:
>>>
>>>
>>> On 3/22/19 7:49 AM, Guillaume Smet wrote:
Hi Gail,
Do we have any idea of what this class is supposed to be:
org.jboss.as.test.
On 3/22/19 9:24 AM, Scott Marlow wrote:
>
>
> On 3/22/19 9:11 AM, Scott Marlow wrote:
>>
>>
>> On 3/22/19 7:49 AM, Guillaume Smet wrote:
>>> Hi Gail,
>>>
>>> Do we have any idea of what this class is supposed to be:
>>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5
>>
On 3/22/19 9:11 AM, Scott Marlow wrote:
>
>
> On 3/22/19 7:49 AM, Guillaume Smet wrote:
>> Hi Gail,
>>
>> Do we have any idea of what this class is supposed to be:
>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ?
>
> This is a unit test class that is not an entity c
On 3/22/19 7:49 AM, Guillaume Smet wrote:
> Hi Gail,
>
> Do we have any idea of what this class is supposed to be:
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ?
This is a unit test class that is not an entity class, but instead it
happens to be an EJB stateless s
Hi Gail,
Do we have any idea of what this class is supposed to be:
org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ?
Scott, any idea?
Because it doesn't ring a bell on my side.
I suspect it's a class we shouldn't access or touch. And we should probably
add a condition som
Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1],
which are failing.
Here is Scott's PR with the updated tests: [2]
When I stepped into
org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
I can see that they are failing in ByteBuddy cod
20 matches
Mail list logo
