On Fri, Dec 29, 2017 at 2:34 PM Steve Ebersole <st...@hibernate.org> wrote:
> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <st...@hibernate.org> > wrote: > >> >> * When using ByteBuddy as the byte code provider, I still needed to have >>> Javassist around, as it's used in ClassFileArchiveEntryHandler. I >>> understand that eventually this should be using Jandex, but I'm wondering >>> whether we could (temporarily) change it to use ASM instead of Javassist >>> (at least when using ByteBuddy as byte code provider, which is based on >>> ASM), so people don't need to have Javassist *and* ByteBuddy when using >>> the >>> latter as byte code provider? This seems desirable esp. once we move to >>> ByteBuddy by default. >>> >> >> Yes, Sanne brought this up in Paris and it is something I will look at >> prior to a 5.3.0.Final >> > > Actually this is different than what Sanne brought up. I actually cannot > reproduce what Sanne is reporting. If I had to guess he was not specifying > the bytecode provider to use "globally". This is a special kind of setting > (we used to have a few) that can only be specified per-VM : either as a > root `hibernate.properties` or as a System property. It has to do with how > Hibernate builds its mapping model, specifically > `org.hibernate.mapping.Component`. Given the redesign of the bootstrap > process we may actually be able to remove that "VM wide" requirement. I'll > look into that for 5.3. BTW Sanne, I created a repo[1] showing that this > does indeed work when specified "properly". > Rafael, does Byte Buddy have such a capability? Maybe we should leverage Jandex for this particular part? _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
