David,
Great question. I made zero code changes to ESAPI other than changing our pom.xml. I suppose if we are calling a dependency somewhere along the line which is using javax.servlet namespace, it may eventually result in a separate sort of runtime error at some point, but to my knowledge we don't call any dependencies with any class in the javax.servlet namespace. (And if we did, I am relying on all you folks using Jakarta EE Servlet API to let us know where we need to address it. 😁)
But the Eclipse Transformer plugin operates by rewriting the byte code which is why ESAPI didn't have to change anything.
Do please let us know if you find anything wrong with the Jakarta version of ESAPI though.
Thanks,
-kevin
Glad to see this release.
I have a related, but technically tangential question about this. In implementing this classifier-based solution, did you end up with a lot of duplicated code, or were you able to engineer the code and build to avoid that? If the latter, can you describe some techniques you used to achieve that? There's an in-house library in my organization that may need to produce a similar classifier-based solution for the same problem, and I'd like to give them some advice to avoid some duplication pain.