Hi Markus, commented inline
Le dim. 6 avr. 2025 à 18:49, Markus Jung <ju...@apache.org> a écrit : > Hi Romain, > > > > 1. will fix it, must admit I remember you mentioned this before but I > forgot to change it before releasing > > 2. I relied so heavily on reflection because the annotatedtypes did not > provide what I wanted (specifically walking up the type hierarchy). How > would I do this with plain CDI annotatedTypes? Only method I could think of > would be introspecting the java class and calling > BeanManager#createAnnotatedType for superclass/interfaces > It is not clear for me since annotated type should provide the hierarchy in types (and if not it is because the user "cuts" the hierarchy with @Typed or alike intentionally), no? > > 3. This confuses me - A child can not omit bean validation on a method if > a parent enabled it, similarly defining other validation annotations at the > child level is illegal if already defined by the parent. (See 5.6.5 in > validation spec) Afterall, this is what the whole fix was about: The CDI > Interceptor was not activated if validation annotations are only present on > the parent class > Right but cdi integration must not trust the java model but rather the cdi model, so if I'm doing an extension adding/removing bval annotations on the parent/child/whatever, it must still respect CDI model. Know most cdi extensions are lazy but bval one was right on that so it shouldn't break it nor prevent the user to adjust it using CDI otherwise our cdi integration would be broken by construction. > > > > Thanks so much for your feedback! > > Markus > > > > On 19.03.25 09:12, Romain Manni-Bucau wrote: > > +1 to fix it properly, I noted three important changes (one which is a > > mistake of last release and one ): > > > > 1. make back DEFAULT_ANNOTATED_TYPE_FILTER private (making it public was > > likely an error and shouldn't be used since it is wrong for all apps > except > > bval project itself) > > 2. we should not use so much reflection in the extension but the > Annotated > > model of CDI (we already have it partially with annotatedType and it has > > all we need in terms of reflection - concretely java.lang.reflect > shouldn't > > be in favor of CDI API and Reflection class usage is 100% useless for > type > > hierarchy but even more for annotations to enable other extensions to > > change the annotations programmatically and comply to CDI and > > disable/enable bean validation programmatically) > > 3. i'm not sure the change respects the overriding of methods (once 2 is > > done it shouldn't be an issue) but this can enable bean validation in a > > child which would have omitted it > > > > Romain Manni-Bucau > > @rmannibucau <https://x.com/rmannibucau> <https://x.com/rmannibucau> | > .NET Blog > > <https://dotnetbirdie.github.io/> <https://dotnetbirdie.github.io/> | > Blog <https://rmannibucau.github.io/> <https://rmannibucau.github.io/> | > Old > > Blog <http://rmannibucau.wordpress.com> < > http://rmannibucau.wordpress.com/> | Github > > <https://github.com/rmannibucau> <https://github.com/rmannibucau> | > LinkedIn > > <https://www.linkedin.com/in/rmannibucau> < > https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> > < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > > Le mer. 19 mars 2025 à 08:45, Markus Jung <ju...@apache.org> <mailto: > ju...@apache.org> a écrit : > > > >> Hey all, > >> > >> > >> unfortunately the fix for BVAL-222 (and thus 3.0.2) was incomplete and > >> contained a regression I noticed when testing the recent TomEE release > >> candidate, for more context see BVAL-223. WDYT about rolling another > >> release? I'll of course offer myself again to act as the release > manager. > >> > >> > >> Thanks > >> > >> Markus > >> > >> >
