WildFly consuming ORM 5.0 is still hitting one last TCCL issue with HCANN. It happens in the org.hibernate.annotations.common.annotationfactory.AnnotationFactory#create method trying to build the "annotation proxy class". There are a few possible approaches to resolve this... The simplest potentially effects other HCANN consumers, so we'd obviously all need to agree. Anyway, the simplest approach is to use the ClassLoader for annotation @interface Class rather than the TCCL. I do not see a problem with that, but it would change some semantic.

The only other workable approach (without redesign of HCANN) I could think of is to basically make a copy of AnnotationFactory and copy it into ORM. Sure I could overload AnnotationFactory#create to optionally accept a ClassLoader, but that introduces a hard dependency on new specific version of HCANN.

Open to other suggestions. Thoughts? _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Ok, then everyone seems to be on board with the simple approach. Awesome! FWIW I'd have to imagine this is close to what the VM does for annotations anyway. So that's an extra win in my book. On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > With that TCCL trick in place it seems it was possible to have the > module actually use a set of annotations provided by the user, to > override those (with same name) already provided by ORM. If that was > meant as a "feature" I'd be glad to see it killed. I think the "intent" was just non-intent tbh. It just used TCCL rather than allowing for specifying which ClassLoader to use because it was "easier". Any expectation beyond that *should* break imho. > The above approach seems nicer as you already have the Class, > otherwise I'd prefer to see such helpers to always allow an explicit > ClassLoader. > I don't think you have to worry about ORM requiring new versions of > HCANN occasionally, we all have to make changes to keep up anyway and > a version upgrade is easy enough. Well especially if we are bumping the release family from 4.0 to 4.1 > > We did have a problem with recent "planet alignment" efforts of > versions on other platforms though, which was caused by a significant > semantic change of a similar classloader improvement, and some people > had upgraded the micro version of HCANN without enough testing. As far > as I remember the dangerous upgrade was the upgrade from HCANN > 4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the > app server. > > In retrospective we should have increased the minor version of HCANN, > so maybe you could do that now when fixing the TCCL issue? Yep, I probably should have done that back when. I will do it now. 4.1?

Sold! https://hibernate.atlassian.net/browse/HCANN/fixforversion/20151 On Thu, May 28, 2015 at 9:32 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > What about making it 5.0 to align them all? > > Search would soon need a 6.0, I'm resisting as much as possible as we > had several signs that people mostly ignore our reminders and expect > the components to be aligned on the major number. Therefore we expect > Search to upgrade to ORM 5 in a minor version. > > On 28 May 2015 at 15:23, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > Ok, then everyone seems to be on board with the simple approach. > Awesome! > > FWIW I'd have to imagine this is close to what the VM does for > annotations > > anyway. So that's an extra win in my book. > > > > On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; > > wrote: > > > >> With that TCCL trick in place it seems it was possible to have the > >> module actually use a set of annotations provided by the user, to > >> override those (with same name) already provided by ORM. If that was > >> meant as a "feature" I'd be glad to see it killed. > > > > > > I think the "intent" was just non-intent tbh. It just used TCCL rather > than > > allowing for specifying which ClassLoader to use because it was > "easier". > > Any expectation beyond that *should* break imho. > > > > > >> The above approach seems nicer as you already have the Class, > >> otherwise I'd prefer to see such helpers to always allow an explicit > >> ClassLoader. > >> I don't think you have to worry about ORM requiring new versions of > >> HCANN occasionally, we all have to make changes to keep up anyway and > >> a version upgrade is easy enough. > > > > > > Well especially if we are bumping the release family from 4.0 to 4.1 > > > >> > >> We did have a problem with recent "planet alignment" efforts of > >> versions on other platforms though, which was caused by a significant > >> semantic change of a similar classloader improvement, and some people > >> had upgraded the micro version of HCANN without enough testing. As far > >> as I remember the dangerous upgrade was the upgrade from HCANN > >> 4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the > >> app server. > >> > >> In retrospective we should have increased the minor version of HCANN, > >> so maybe you could do that now when fixing the TCCL issue? > > > > > > Yep, I probably should have done that back when. I will do it now. > 4.1? > > >