OsgiRegistry classToBundleMapping does not store classes for packages containing .class correctly

[wb459]

We are running Jersey in an OSGi environment and we are experiencing the following error at startup:

Could not start the servlet context for context path [] - username= - trace-id=
javax.servlet.ServletException: org.ops4j.pax.web.service.spi.model.ServletModel-106@84178cbf==org.glassfish.jersey.servlet.ServletContainer,0,false
	at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:661) ~[214:org.ops4j.pax.web.pax-web-jetty-bundle:6.0.7]
...
Caused by: java.lang.RuntimeException: A class file of the class name, org.example.classification.rest.internal.MyClassificationResource, is identified but the class could not be found.
	at org.glassfish.jersey.server.internal.scanning.AnnotationAcceptingListener$AnnotatedClassVisitor.getClassForName(AnnotationAcceptingListener.java:265) ~[?:?]

...
Caused by: java.lang.ClassNotFoundException: org.example.classification.rest.internal.MyClassificationResource
	at org.glassfish.jersey.internal.OsgiRegistry.classForNameWithException(OsgiRegistry.java:477) ~[?:?]

When looking into this issue the OsgiRegistry seems to have stored the following class in its classToBundleMapping:
org.exampleification.rest.internal.MyClassificationResource

This is caused by the incorrect replacement at https://github.com/eclipse-ee4j/jersey/blob/2.29-RC1-BRANCH/core-common/src/main/java/org/glassfish/jersey/internal/OsgiRegistry.java#L421

Affected versions
2.27+ (and possibly earlier versions)

[jansupol]

That particular line is there since 2.0, and it was working well so far. Can you provide us your test case?

[wb459]

@jansupol I time-boxed tried to provide a test case but the tests for OSGi seem to be in a non-working state for me? (And ignored in Java 11)

I'm expecting the error to appear in the test suit if you rename for example org.glassfish.jersey.examples.osgi.helloworld.additional.resource to org.glassfish.jersey.examples.osgi.helloworld.classification.additional.resource.

Regardless, it's clear that the line of code will replace all occurrences of ".class" in the jarEntryName by an empty string while it should only replace the final ".class" if it's the end of the jarEntryName.

[jansupol]

Yes, we have experienced some issues with JDK11 and OSGi frameworks. In Jersey, we have excluded OSGi tests for now, so they are ignored at the moment in master branch.

It is a funny bug with ".classification", and noone seems to hit that till now :)

[senivam]

fixed