Some of the modules in the release vote, e.g. engine, servlets post have
such API as well - and for all of those I duplicated the API to be able
to write code using those APIs which does not rely on anything deprecated.
The implementation (and same is true for the implementation of the API)
directly implements the Jakarta variant. The javax variant is usually
implemented by using wrappers and then invoking the Jakarta variant.
In most cases this is very straight forward, but I agree that its not
the nicest.
Regards
Carsten
On 26.06.2025 09:46, Stefan Seifert wrote:
with the release of Sling API 3.0.0 we have deprecated all API interfaces based
on the old servlet API, although they are still fully working.
i suppose most of our other Sling modules' APIs have some reference to
SlingHttpServletRequest and similar baked in their own API (i'm thinking e.g.
of Sling Models, Context-Aware configuration). although still working, they are
all now referencing deprecated parts of the API, and should give users the
opportunity to switch to latest Jakarta Servlet API.
does this mean we have to go through all of these modules, deprecated all APIs which are
"tainted" with old Servlet API references and create a new parallel interface
with Jakarta servlet API and release a new major version of the bundle; same as in the
Sling API itself? that seems to be quite a lot of work, esp. keeping old and new versions
of the interfaces running in parallel.
maybe it would be helpful to create a wiki page with recommendation how to
create such a dual-faced API in the best-compatible way?
(most of the models in the correct voting process that are released together
with the API 3.0.0 do not have their own API, so we don't have much blueprints
except the Sling AIP 3.0.0 itself)
stefan
--
Carsten Ziegeler
Adobe
cziege...@apache.org
