Cannot find class javax.servlet.descriptor.JspPropertyGroupDescriptor

[Bengt Rodehav]

I seemed to have written to the wrong mailing list - perhaps that is the reason why I got no reply :-)

I wrote to org.ops4...@noreply.github.com but I guess it's not active anymore. 

I'll recap what I wrote on the other list...

---

I am using Karaf 4.4.4 with Pax-Web 8.0.22.

I get the following error in the log:

2023-11-30T17:55:19,274 | ERROR | [iPOJO] pool-1-thread-1 | web-console                      | 108 - se.digia.seco.web.web-console - 3.1.0.SNAPSHOT | [ERROR]  : Cannot create the proxy object
java.lang.NoClassDefFoundError: javax/servlet/descriptor/JspPropertyGroupDescriptor
at java.lang.Class.getDeclaredMethods0(Native Method) ~[?:?]
at java.lang.Class.privateGetDeclaredMethods(Class.java:3402) ~[?:?]
at java.lang.Class.privateGetPublicMethods(Class.java:3427) ~[?:?]
at java.lang.Class.getMethods(Class.java:2019) ~[?:?]
at org.apache.felix.ipojo.handlers.dependency.ProxyGenerator.dumpProxy(ProxyGenerator.java:89) ~[!/:?]
at org.apache.felix.ipojo.handlers.dependency.Dependency$SmartProxyFactory.getProxyClass(Dependency.java:1133) ~[!/:?]
at org.apache.felix.ipojo.handlers.dependency.Dependency$SmartProxyFactory.getProxy(Dependency.java:1151) [!/:?]
at org.apache.felix.ipojo.handlers.dependency.Dependency.start(Dependency.java:516) [!/:?]
at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.__M_start(DependencyHandler.java:496) [!/:?]
at org.apache.felix.ipojo.handlers.dependency.DependencyHandler.start(DependencyHandler.java) [!/:?]
at org.apache.felix.ipojo.HandlerManager.start(HandlerManager.java:136) [!/:?]
at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:421) [!/:?]
at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:179) [!/:?]
at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:319) [!/:?]
at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240) [!/:?]
at org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:312) [!/:?]
at org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:306) [!/:?]
at org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:114) [!/:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
Caused by: java.lang.ClassNotFoundException: javax.servlet.descriptor.JspPropertyGroupDescriptor not found by org.ops4j.pax.web.pax-web-api [94]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1591) ~[?:?]
at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79) ~[?:?]
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1976) ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
... 22 more

In Pax-Web 7.3.23 (used in Karaf 4.3.3) the following bundle was included:

  javax.servlet-api/3.1.0

In Pax-Web 8.0.22 (used in Karaf 4.4.4) it has been replaced by the following pair:

  jakarta.servlet-api/4.0.4
  pax-web-compatibility-servlet31/8.0.22

I am using Servlet 3.1 which was provided cleanly in Pax-Web 7.3.23. But in 8.0.22 it is instead provided by the Servlet 4.0 bundle in combination with a fragment that (if I understand correctly) re-exports that code as version 3.1. Correct me if I am wrong.

This setup doesn't seem to work with iPojo.

Looking at the bundle org.ops4j.pax.web/pax-web-api/8.0.22, it seems like it only imports the following javax.servlet packages:

  javax.servlet; version="[3.1, 5)",
  javax.servlet.annotation; version="[3.1, 5)",
  javax.servlet.http; version="[3.1, 5)"

...but not

  javax.servlet.descriptor

If I add the following:

  javax.servlet.descriptor;version="[3.1,5)"

To the Import-Package section of the MANIFEST.MF of the pax-we-api jar, then it works. It makes me wonder if this import is missing in pax-web-api. 

I created a fragment that adds the above import to pax-web-api. It seems to work but is only a quickfix. I would appreciate it if someone more OSGi savy could explain what is actually happening.

/Bengt

[Grzegorz Grzybek]

Hello

Thanks for the report - please create an issue at https://github.com/ops4j/org.ops4j.pax.web/issues and we can have a fix soon (before Christmas).

Indeed - pax-web-api doesn't import this package, because it doesn't need/use it - I didn't expect other bundle (ipojo) will use this bundle to load the javax/servlet/descriptor/JspPropertyGroupDescriptor class - it should rather use the bundle wiring and use reachable bundles to load the class it needs...

Are you aware what ipojo is doing with classloaders? I never used ipojo tbh...

regards

Grzegorz Grzybek

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAJ0TPGJc8onoMjDr3RDPaWQRWXWryLiXyVEHD6gSmseZ934bxg%40mail.gmail.com.

[Bengt Rodehav]

Hello  Grzegorz - thanks for your reply.

I'm a bit puzzled as well regarding this. It's a bit strange why iPojo needs this class. However, iPojo is not actively being maintained anymore (although a version is on the way to support Java 21) so maybe it's easier to fix this in pax-web-api.

I created the following JIRA:

https://github.com/ops4j/org.ops4j.pax.web/issues/1921

/Bengt

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhp0NB6%2BU730QgxS2dW7g59VWSgv5dQ%2BcvEAjRQE07c%2BAQ%40mail.gmail.com.

[Grzegorz Grzybek]

Thanks

Please give me some time (end of year is crazy as always)

regards

Grzegorz Grzybek

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAJ0TPGJfRC9O3L_Vs6XN3x3xOneyBb1asE77MT32yuwBr1F%2BBA%40mail.gmail.com.

[Bengt Rodehav]

Of course. Appreciate your help.

I also cross posted this on the Felix mailing list in case this is an iPojo problem.

In general, I wonder if a bundle both imports and exports packages, is it a problem that it does not include "all" packages?

/Bengt

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhowEsnx%2B80wJtVdJpO56YYJYnLypLv4rxan3LH2EXmjKw%40mail.gmail.com.

[Grzegorz Grzybek]

Hi

śr., 6 gru 2023 o 14:25 Bengt Rodehav <be...@rodehav.com> napisał(a):

Of course. Appreciate your help.

I also cross posted this on the Felix mailing list in case this is an iPojo problem.

In general, I wonder if a bundle both imports and exports packages, is it a problem that it does not include "all" packages?

imported packages are generally generated by tools like maven-bundle-plugin after analyzing your code. So by default only the used packages are imported.

regards

Grzegorz Grzybek

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAJ0TPGLLHkEJ19vzK33oF-PFp8B72iE%3Df6jQYo5O0LTELNqcJg%40mail.gmail.com.

[Bengt Rodehav]

Yes, you're right about that. I have however noticed that some bundles both import and export the same package. I was just wondering if this could complicate things for iPojo. I see now that pax-web-api only imports the javax.servlet classes without also exporting it so I was thinking in the wrong direction.

In this case I think it's a bit strange that iPojo tries to find this class in pax-web-api and doesn't look for it in the right place. I suspect that the javax.servlet.descriptor package is not used directly but iPojo tries to find all supported classes (using reflection) which probably causes it to need this package as well but it is not a declared dependency.

/Bengt

To view this discussion on the web visit https://groups.google.com/d/msgid/ops4j/CAAdXmhoAh_zWCASp%2BmyYGFQ_5fF2EhpM0PFnSKVV%2BL8U7kvODw%40mail.gmail.com.