Hi all,
I'm finding several issues around this subject. While I tried several
workarounds, I'd like us to agree on a strategy to address the root
problem which is that Hibernate ORM might not necessarily want to use
the Javassist version provided by WildFly, yet this is currently being
forced on us
On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero wrote:
> Hi all,
> I'm finding several issues around this subject. While I tried several
> workarounds, I'd like us to agree on a strategy to address the root
> problem which is that Hibernate ORM might not necessarily want to use
> the Javassist ve
Didn't we want to migrate off of Javassist for ORM 6, going for
ByteBuddy exclusively?
https://hibernate.atlassian.net/browse/HHH-11253 discusses that.
2017-01-11 15:59 GMT+01:00 Scott Marlow :
> On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero wrote:
>> Hi all,
>> I'm finding several issues aro
On 11 January 2017 at 15:09, Gunnar Morling wrote:
> Didn't we want to migrate off of Javassist for ORM 6, going for
> ByteBuddy exclusively?
> https://hibernate.atlassian.net/browse/HHH-11253 discusses that.
Sure Byte Buddy looks great but we'll still need to support existing
users for a while.
On 11 January 2017 at 14:59, Scott Marlow wrote:
> On Wed, Jan 11, 2017 at 5:52 AM, Sanne Grinovero wrote:
>> Hi all,
>> I'm finding several issues around this subject. While I tried several
>> workarounds, I'd like us to agree on a strategy to address the root
>> problem which is that Hibernate
>> ## Suggestions?
>> I'm stuck again on Hibernate Search upgrading to latest ORM so I'll
>> see to apply the workaround without waiting for the proper solution.
>> Not sure which actions I should take on ORM?
>>
>> Personally I think I'd just patch the modules to use the older
>> Javassist when ru
Ahh, I was confused then, your talking about the WildFly ORM static
module definition [1], which is not controlled by the JPA container or
JipiJapa.
>>
>> We talked about this not long ago and possible solutions, the only
>> agreed on solution was to eliminate the ORM requirement for Javassist
>>
I think the best option in terms of supporting legacy ORM version users
would be to incorporate a change in those branches to shade/shadow
Javassist into ORM specific packages (in hibernate-core).
As I understand it, it is always ORM that does the enhancement, right
Scott?
On Wed, Jan 11, 2017 at
On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote:
> I think the best option in terms of supporting legacy ORM version users
> would be to incorporate a change in those branches to shade/shadow Javassist
> into ORM specific packages (in hibernate-core).
+1
>
> As I understand it, it is alwa
The one small issue is that if the user enhanced the classes at build time
(i,e. not via the ClassTransformer), then shading in a newer version of Wildfly
means that the same app using the later version will fail unless you rebuild
the app.
BTW is Javassist Shadable, some of these libs can’t due
On 11 January 2017 at 16:35, Scott Marlow wrote:
> On Wed, Jan 11, 2017 at 11:19 AM, Steve Ebersole wrote:
>> I think the best option in terms of supporting legacy ORM version users
>> would be to incorporate a change in those branches to shade/shadow Javassist
>> into ORM specific packages (in h
I'm not really sure but did notice that HikariCP [1] shaded the
Javassist runtime classes in 2015 and still seems to be shading
Javassist.
Good point about about the compatibility impact, as build time
instrumentation with the non-shaded Javassist will produce a Java
archive that doesn't work with
12 matches
Mail list logo
