Re: [jetty-dev] servlet-api repackaging

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Mon, Apr 24, 2023 at 10:55 AM Eirik Bjørsnøs <eirbjo@xxxxxxxxx> wrote:
>
> Hi,
>
> I notice that Jetty repackages the jakarta (and javax) servlet api into a module jetty.servlet.api. This module is then required by modules such as org.eclipse.jetty.server.
>
> This repackaging makes it hard (impossible?) to create a reliable configuration with modules which require jakarta.servlet. If some module sees both the standard jakarta module and Jetty's, then you'll get compilation failures like:
>
>> [ERROR] COMPILATION ERROR :
>> [ERROR] the unnamed module reads package jakarta.servlet from both jetty.servlet.api and jakarta.servlet
>
>
> If I exclude the Jetty servlet module, I get the following error:
>
>> [ERROR] module not found: jetty.servlet.api
>
>
> Based on my current knowledge of the Java Modules System, I'm not sure how to go about creating a reliable module configuration which includes both Jetty and 'jakarta.servlet'.

You cannot.
You have to exclude jakarta.servlet for versions < 6 because they
don't have a module-info.class, and use the Jetty jar instead (which
has the module-info.class).

> Would it be possible to rework Jetty's servlet API to depend on and require the standard API?

No, as the standard jar does not have module-info.class.

> In my particular case, jakarta.servlet is in a parent Layer / classloader, which is seen by servlets in separate modules and by my Jetty module.
>
> This scenario worked fine using Jetty 9.4.27.v20200227, which I'm now upgrading from.

To what Jetty version exactly?

Note that if you upgrade to Jetty 12, you can use the Jakarta jar.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.