pax-web is not discovering jakarta annotations

[nicolasbron]

I'm currently in process of migrating application to pax 11 with jetty 12. We are using new jakarta 6.1. But unfortunately it looks as the osgi bundles containg Web-ContextPath are not scanned for those annotations and servlets/filters are not registered. If everything is defined in web.xml then it works as expected. I assume I'm missing something in my osgi server. Those are the pax-web libraries together with jetty ones:
org.ops4j.pax.web.pax-web-api-11.0.0.jar
org.ops4j.pax.web.pax-web-compatibility-annotation-11.0.0.jar
org.ops4j.pax.web.pax-web-compatibility-servlet-11.0.0.jar
org.ops4j.pax.web.pax-web-extender-war-11.0.0.jar
org.ops4j.pax.web.pax-web-extender-whiteboard-11.0.0.jar
org.ops4j.pax.web.pax-web-jetty-11.0.0.jar
org.ops4j.pax.web.pax-web-jsp-11.0.0.jar
org.ops4j.pax.web.pax-web-runtime-11.0.0.jar
org.ops4j.pax.web.pax-web-spi-11.0.0.jar
org.ops4j.pax.web.pax-web-tomcat-common-11.0.0.jar
org.ops4j.pax.web.pax-web-websocket-11.0.0.jar

org.eclipse.jetty-xml-12.0.22.jar
org.eclipse.jetty.ee10.jetty-ee10-annotations-12.0.22.jar
org.eclipse.jetty.ee10.jetty-ee10-apache-jsp-12.0.22.jar
org.eclipse.jetty.ee10.jetty-ee10-plus-12.0.22.jar
org.eclipse.jetty.ee10.jetty-ee10-servlet-12.0.22.jar
org.eclipse.jetty.ee10.jetty-ee10-servlets-12.0.22.jar
org.eclipse.jetty.ee10.jetty-ee10-webapp-12.0.22.jar
org.eclipse.jetty.ee10.jetty-ee10-websocket-jetty-server-12.0.22.jar
org.eclipse.jetty.ee10.jetty-plus-12.0.22.jar
org.eclipse.jetty.http-12.0.22.jar
org.eclipse.jetty.io-12.0.22.jar
org.eclipse.jetty.jetty-ee-12.0.22.jar
org.eclipse.jetty.security-12.0.22.jar
org.eclipse.jetty.server-12.0.22.jar
org.eclipse.jetty.session-12.0.22.jar
org.eclipse.jetty.util-12.0.22.jar
org.eclipse.jetty.util.ajax-12.0.22.jar

Am I missing something?

[grgrzybek]

Hmm, we have annotated servlet example here: https://github.com/ops4j/org.ops4j.pax.web/blob/pax-web-11.0.x/samples/samples-war/war-security/src/main/java/org/ops4j/pax/web/samples/war/security/FullyAnnotatedServlet.java

And the integration tests using this WAR/WAB sample is here: https://github.com/ops4j/org.ops4j.pax.web/blob/pax-web-11.0.x/pax-web-itest/pax-web-itest-container/pax-web-itest-container-common/src/main/java/org/ops4j/pax/web/itest/container/war/AbstractWarSecurityIntegrationTest.java

So in theory it should work

There should be something in the logs you could check...

[grgrzybek]

Usually, in OSGi runtimes such error may be caused by multiple bundles exporting jakarta.servlet.annotation package...

[nicolasbron]

I just discovered if I wrap my classes into WEB-INF/classes and add Bundle-ClassPath: WEB-INF/classes then everything is working wcorrectly. But if my classes resides in root dir with Bundle-ClassPath: . then nothing is discovered. Is it required to include classes in WEB-INF directory?

[grgrzybek]

In theory it should. There's special code for checking Bundle-ClassPath entries - jars and directories:

org.ops4j.pax.web/pax-web-extender-war/src/main/java/org/ops4j/pax/web/extender/war/internal/model/BundleWebApplicationClassSpace.java

Lines 918 to 941 in 54b1aa1

	// 1. scan classes in non-JAR entries from WAB's Bundle-ClassPath
	// - always for types from @HandlesTypes
	// - possibly for other annotated types if metadata-complete="false" on this.mainWebXml
	LOG.trace("Scanning classes in WAB directory entries");
	URL[] urls = ClassPathUtil.getClassPathNonJars(wabBundle);
	boolean htOnly = mainWebXml.isMetadataComplete();
	Set<String> processedRoots = new HashSet<>();
	for (URL url : urls) {
	LOG.trace(" Scanning embedded directory: {}", url);
	List<URL> classes = ClassPathUtil.findEntries(wabBundle, new URL[] { url }, "/", "*.class", true);
	for (URL u : classes) {
	processedRoots.add(u.toExternalForm());
	if (!u.getPath().endsWith(".class")) {
	// skip entries like
	// "jar:bundle://40.0:0/WEB-INF/lib/spring-core-5.3.6.jar!/org/springframework/core/type/classreading/"
	continue;
	}
	LOG.trace(" Scanning {}", u);
	processClass(u, mainWebXml, wabBundle, htOnly, htToSci, sciToHt, javaClassCache,
	thereAreHTClasses, thereAreHTAnnotations);
	}
	}

There's a sample using Bundle-ClassPath, but not with . entry:

org.ops4j.pax.web/samples/samples-war/war-most-complex/the-wab-itself-jar2/pom.xml

Lines 92 to 107 in 54b1aa1

	<!--
	<_wab> is a handy replacement for Include-Resource, but we explicitly want /WEB-INF/lib-not-javaee
	as a directory for libraries and we don't want to have additional /WEB-INF/lib. Also
	we want classes to ba available from a directory different than /WEB-INF/classes (which is always
	added by default by <_wab>).
	This also means we need explicit Bundle-ClassPath
	-->
	<!-- <_wab>${project.build.directory}/${project.build.finalName}</_wab>-->
	<Web-ContextPath>/wab-complex</Web-ContextPath>
	<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
	<Embed-Directory>WEB-INF/lib-not-javaee</Embed-Directory>
	<!--
	Bundle-ClassPath will contain entries (besides the one specified explicitly) calculated
	using Embed-Directory and Embed-Dependency
	-->
	<Bundle-ClassPath>/WEB-INF/classes-not-javaee</Bundle-ClassPath>

So there may be an issue with . entry.

You can increase logging level for org.ops4j.pax.web.extender.war logger to TRACE to see a lot of information about scanning - maybe you can spot something?

I'll check later if this works, but rather later next week.

Mind that the root of the WAB is supposed to contain web resources, so you will be able to retrieve them using HTTP! You should rather not allow users to get your http://localhost:8080/context/com/example/MyClass.class...

[nicolasbron]

It doesn't work. And you are right, the problem is the "." in the Bundle-ClassPath. It looks like this code for ClassPathUtil:
https://github.com/ops4j/org.ops4j.pax.web/blob/pax-web-11.0.x/pax-web-api/src/main/java/org/ops4j/pax/web/utils/ClassPathUtil.java#L165

        final String bundleClasspath = bundle.getHeaders() == null ? null
				: bundle.getHeaders().get(Constants.BUNDLE_CLASSPATH);
		if (bundleClasspath == null) {
			// fallback to just root directory of the bundle
			return new URL[] { bundle.getEntry("/") };
		} else {
			String[] segments = bundleClasspath.split("\\s*,\\s*");
			for (String segment : segments) {
				final URL url = bundle.getEntry(segment);
				if (url == null) {
					continue;
				}

When the segment is equal "." the bundle.getEntry(".") returns null. It has to be "/" instead probably. I believe that there should be a check. If segment == "." then use "/" instead. If I replace the
Bundle-ClassPath: .
with
Bundle-ClassPath: /
Then the Apache Felix doesn't want to start up as it's not able to resolve the classpath.

[nicolasbron]

I believe there is an issue in the code. Created a ticket:
#2106

And a pull request:
#2107

If it could be merged and a new artifact produced that would be great as this is blocking us from moving forward with migration.

[grgrzybek]

Thanks! I'll review at earliest on Monday, but you can expect a release the same week.

[grgrzybek]

Check out this: https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.war.html#i3096883

128.3.5 Static Content

It is the responsibility of the author of the WAB to ensure that confidential information remains confidential by placing it in one of the protected directories. WAB bundles should be constructed in such a way that they do not accidentally expose code or confidential information. The simplest way to achieve this is to follow the WAR model where code is placed in the WEB-INF/classes directory and this directory is placed on the Bundle's class path as the first entry. For example:

Bundle-ClassPath: WEB-INF/classes, WEB-INF/lib/acme.jar

So in practice this obvious issue was by accident a protection, because root content of the bundle could not be exposed as web resources even if Bundle-ClassPath contains ..

There's nothing in the spec that say it should be prevented, so I suggest fixing this (with your PR), but with a WARNING that it makes the classes available to external users.

[grgrzybek]

Also you you have Bundle-ClassPath: .,WEB-INF/classes and have a class, say, WEB-INF/classes/com/example/MyClass.class, this class would be loadable using WAB classloader with these:

cl.getResource('com/example/MyClass.class');
cl.getResource('WEB-INF/classes/com/example/MyClass.class');

which may be a bit confusing.

[nicolasbron]

If you are using both then yes it will be loaded twice. But the '.' should never be used together with 'WEB-INF/classes'. And we are not using it. It might be a security issue I agree but nothing prevents end user from using it like this.

[grgrzybek]

Sorry for no responses - I was super busy with my daily job.
I will have a look at this issue soon, together with some other session-related issues in Pax Web.

[grgrzybek]

#2106 is now fixed.