jakarta-web relax the import package constraints

[jcompagner]

If you work in an osgi environment where it used import an export packages
then the log4j-jakarta-web is to restrictive:

Import-Package: jakarta.servlet;version="[5.0,6)",jakarta.servlet.http;v
ersion="[5.0,6)",

so it says as a from 5.0 but not 6 (not including 6) so until 5.999

This is annoying if you are building with a 6.1 (tomcat 11) jakarta specification.

you don't need an upper bound i think, because i guess you just have a lower bound where you build on and that should work fine in a 6 or even 7 jakarta servlet spec right?

so please just do:

Import-Package: jakarta.servlet;version="[5.0,7)",jakarta.servlet.http;v
ersion="[5.0,7)",

so that you support all the version that are currently released (because you do run fine on a tomcat 11 right?)

[ppkarwasz]

Hi @jcompagner,

Thanks for pointing that out!

you don't need an upper bound i think, because i guess you just have a lower bound where you build on and that should work fine in a 6 or even 7 jakarta servlet spec right?

We don’t explicitly specify import version ranges in our bundles—those are determined by our tooling (BND) using its default import version policy, which sets the upper bound to the next major version.

While we’d prefer to stick with the automatic import policy, the Servlet API doesn’t follow OSGi semantic versioning at the package level. So even if version 6.0 is compatible from a consumer perspective, OSGi treats it as a breaking change due to the major version bump.

I agree that we should override the computed range to explicitly allow all 6.x versions. As for 7.x, we’d prefer to wait until it’s released before including it.

Our build script maps the bnd-extra-package-options Maven property to BND's Import-Package directive, as shown here:

logging-log4j2/log4j-to-slf4j/pom.xml

Lines 42 to 47 in ff03364

	<bnd-extra-package-options>
	<!-- Annotations only -->
	org.jspecify.*;resolution:=optional,
	<!-- This bridge also support SLF4J 2.x -->
	org.slf4j.*;version="${slf4j.support.range}"
	</bnd-extra-package-options>

Feel free to submit a PR to address this—we’d be happy to review it!

[jcompagner]

ok i added this: Servoy@8c5ac44
is it easy to quickly test this somehow?

[ppkarwasz]

Hi @jcompagner,

Is it easy to quickly test this somehow?

We do have some OSGi tests using Pax Exam in the log4j-osgi-test module. For example, I recently added a test to verify that Disruptor works correctly in 69b3058.

That said, writing a meaningful automated test for this particular case isn’t easy. If you’re able to test it within your application and confirm that it works as expected, that should be enough.

[jcompagner]

i was not directly talking about the actual jar in a production setup, that already works i already patched the jar outself and use that one for our own stuff:

https://developer.servoy.com/mvn_repository/com/servoy/log4j-jakarta-web/2.25.0.s1/log4j-jakarta-web-2.25.0.s1.jar

Else i can't get it to work correctly in our OSGi (eclipse) setup.

but more will my change correctly work when building? i can try to do a full checkout and try to build it fully not sure if that works quickly

[ppkarwasz]

but more will my change correctly work when building? i can try to do a full checkout and try to build it fully not sure if that works quickly

The change looks good to me, if you add a changelog file (see Changelog entry file guide) and submit your change as PR, we can use our CI to generate a snapshot.