CODEWITHSUNDEEP
apache-karafvaadin8vaadin-flowapache-karaf-feature
Enver Haase
Enver Haase

Reputation: 74

How to run a Vaadin 8 or 20 application on Karaf 4.3.2 with Pax-Web?

I thought I read somewhere that one can switch between:

Jetty
Tomcat
Wildfly

for use with the feature:install war, however, neither can I find that place anymore, nor do I have an idea of what to enter on the Karaf CLI to switch between the three.

As if this was not enough, I've had little success with Jetty (version 9.4.40v20210413 seems to be in Karaf 4.3.2 which is reasonably recent so should in principle work).

I tried to deploy a Vaadin 8.5.2 application (I read from 8.6 something could be broken, which I do not want to investigate as the first thing).

karaf@root()> web:list
ID  │ State       │ Web-State   │ Level │ Web-ContextPath │ Name
────┼─────────────┼─────────────┼───────┼─────────────────┼────────────────────────────────
110 │ Active      │ Failed      │ 80    │ /learningfusion │ 
learningfusion (1.0.0.SNAPSHOT)
111 │ Active      │ Deployed    │ 80    │ /connect4       │ connect4 (1.0.0)

So the connect4 application should be working fine, but browsing localhost:8181/connect4 gives me a 403 error.

How can I fix this? (Commands are more appreciated over the 'what to do', as I may currently not understand 'how to' achieve that being the beginner in this regard that I am).

And the other application in the list is a Vaadin20 production mode application, which gives me an NPE when starting up, so I would first like to try the other two application containers to aid debugging.

Could someone maybe point me to the relevant documentation if there is any?

Upvotes: 1

Views: 179

Answers (1)

Grzegorz Grzybek
Grzegorz Grzybek

Reputation: 6237

I checked https://github.com/enver-haase/Playground/tree/master/connect4 with Karaf 4.3.2 + Pax Web 7.3.16 and the problem is with org.springframework.web.SpringServletContainerInitializer#onStartup() method. Or rather with the way it's handled by Pax Web (pax-web-extender-war).

SpringServletContainerInitializer is annotated with:

@HandlesTypes(WebApplicationInitializer.class)

Which means (according to JavaEE Servlets specification) give me all the classes implementing WebApplicationInitializer interface.

But Pax Web 7 (though I've fixed it in still-not-released Pax Web 8) is simply passing WebApplicationInitializer.class itself.

This leads to situation, where Spring Web simply calls:

servletContext.log("No Spring WebApplicationInitializer types detected on classpath");

While (when checking on Tomcat), the list of classes is (as expected):

webAppInitializerClasses: java.util.Set  = {java.util.HashSet@2416}  size = 6
 0 = {@2419} "class com.infraleap.connect4.Connect4Application"
 1 = {@2420} "class org.springframework.web.context.AbstractContextLoaderInitializer"
 2 = {@2421} "class org.springframework.boot.web.support.SpringBootServletInitializer"
 3 = {@2422} "class org.springframework.boot.autoconfigure.jersey.JerseyAutoConfiguration$JerseyWebApplicationInitializer"
 4 = {@2423} "class org.springframework.web.servlet.support.AbstractDispatcherServletInitializer"
 5 = {@2424} "class org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer"

and Vaadin can start successfully.

I checked on Pax Web 8 (not released yet) and the set is correct:

webAppInitializerClasses = {java.util.LinkedHashSet@7795}  size = 6
 0 = {@7798} "class org.springframework.web.context.AbstractContextLoaderInitializer"
 1 = {@7799} "class org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer"
 2 = {@7800} "class com.infraleap.connect4.Connect4Application"
 3 = {@7801} "class org.springframework.web.servlet.support.AbstractDispatcherServletInitializer"
 4 = {@7802} "class org.springframework.boot.web.support.SpringBootServletInitializer"
 5 = {@7803} "class org.springframework.boot.autoconfigure.jersey.JerseyAutoConfiguration$JerseyWebApplicationInitializer"

And I found I have to change default implementation of org.ops4j.pax.web.service.spi.servlet.OsgiDynamicServletContext#setInitParameter() (it's supposed to throw UnsupportedOperationException according to OSGi CMPN 140 Whiteboard specification...) - I fixed it.

But now, the state is that when spring-boot-web tries to configure (I see it's called properly) the dispatcher servlet, it fails to map it under '/' path, as there's default servlet mapped already. According to Servlets specification it's not possible, but Tomcat marks servlets from conf/web.xml (default and jsp) as override'able and I have to do the same in Pax Web 8...

The point is - thanks for very complex example and I'll definitely turn it into Pax Web 8's integration test. Soon(ish).

Upvotes: 1

Related Questions