Isn't it stable enough to use bcel or asm to write it? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 2 avr. 2021 à 16:41, Mark Thomas <ma...@apache.org> a écrit : > On 02/04/2021 13:58, Raymond Augé wrote: > > I just wanted to make a note that removing the annotation will also mean > > that the module-info.java will need to be manually managed since bnd also > > generated that based on the annotations. > > That might be more problematic. Sigh. I'll look into that next week. > > Mark > > > > > > Just FYI, > > - Ray > > > > On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <jeano...@gmail.com> > > wrote: > > > >> That's awesome news. > >> > >> I'm glad it's something that can be achieved without too much effort. > >> I understand and buy the pragmatic approach. > >> > >> But at the same time, if we can do a step forward and get even closer to > >> being certified, that'd be great. > >> > >> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <ma...@apache.org> a écrit : > >> > >>> I've been playing with this a bit more and it appears we can simply > >>> hard-code the "Require-Capability" header in el-api.jar.bnd > >>> > >>> Having taken the time to look at the actual values generated for these > >>> API JARs, this does look like something that would be simple to > maintain > >>> manually - especially for the API JARs where adding a new use of > >>> ServiceLoader is likely to happen fairly rarely. > >>> > >>> We should be able to remove the Bnd annotation in > >>> - 10.0.x for 10.0.6 onwards > >>> - 9.0.x for 9.0.46 onwards > >>> > >>> We'll certainly do this for the API JARs. I think we'll leave it in > >>> place for the implementation JARs > >>> > >>> I have a few things on my TODO list at the moment but I don't see why I > >>> shouldn't be able to get this done for the May set of releases. > >>> > >>> Mark > >>> > >>> > >>> On 01/04/2021 08:24, Romain Manni-Bucau wrote: > >>>> Hi, > >>>> > >>>> AFAIK TomEE will try to be certified and will try to not fork as much > >> as > >>>> possible Tomcat code so can be neat to solve it in particular when > >>>> relatively easy: > >>>> > >>>> 1. compile tomcat classes with bnd as of today > >>>> 2. run bnd to get the manifest.mf ( > >>>> 3. post process tomcat classes to remove bnd from the .class > >>>> 4. jar it > >>>> > >>>> should solve the process and does not look crazy compared to what > >> tomcat > >>>> already does, no? > >>>> > >>>> Alternative is indeed to drop bnd since the manifest is quite easy to > >>> write > >>>> manually or with an ant task to filter the version for tomcat case, at > >>>> least for spec jars (it is harder for the impl but here bnd is fine). > >>>> > >>>> Romain Manni-Bucau > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>>> <https://rmannibucau.metawerx.net/> | Old Blog > >>>> <http://rmannibucau.wordpress.com> | Github < > >>> https://github.com/rmannibucau> | > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >>>> < > >>> > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >>>> > >>>> > >>>> > >>>> Le jeu. 1 avr. 2021 à 09:19, Mark Thomas <ma...@apache.org> a écrit : > >>>> > >>>>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote: > >>>>>> Hello, > >>>>>> > >>>>>> It appears the TCK Signature tests will not be relaxed (see 1 & 2), > >>>>>> and I'm wondering how Tomcat will proceed with the bnd annotation in > >>>>>> the EL API? Will it be removed in the next release? > >>>>> > >>>>> Currently, there are no plans to change the Tomcat code. > >>>>> > >>>>> We do run the TCKs but take a pragmatic view of any failures. For > >>>>> example, the Servlet TCK test that tests setting a context path in > >>>>> web.xml always fails because Tomcat always overrides any such > setting. > >>>>> The Servlet spec allows this setting to be overridden but the TCK > test > >>>>> doesn't consider the possibility that a container will always do > this. > >>>>> Therefore we simply treat this as an expected failure. Full details > >> for > >>>>> all the TCKs we run can be found on the Wiki: > >>>>> > >>>>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs > >>>>> > >>>>> The EL signature test failure is another example of a failure that we > >>>>> consider can be safely ignored. > >>>>> > >>>>> Tomcat does not, and has not for many, many years, formally certified > >>>>> against the Jakarta EE / Java EE TCKs. I am not aware of any user > >>>>> request at any point in that time to complete formal certification. > >>>>> Therefore, I expect that Tomcat will continue following its current > >>>>> pragmatic approach to the TCKs. > >>>>> > >>>>> Mark > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org > >>>>> > >>>>> > >>>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: dev-h...@tomcat.apache.org > >>> > >>> > >> > >> -- > >> Jean-Louis > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
