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
