WebContainer Configuration

[garpinc]

I noticed that the pax-web activator is a managed service that will restart the webcontainer when finding a configuration file.

My issue is that if I have a bundle dependent on the webcontainer how do I know if it's the default one vs my one?

In org.ops4j.pax.web.service.internal.Activator.determineServiceProperties(Configuration) it filters out all my properties so I can't look for a custom property that I set.

Ideally it would pass any of the properties i set onto server properties so they stay with the webcontainer service reference no?

[grgrzybek]

Well - Pax URL and Pax Logging use a bundle context property called requireConfigAdminConfig which allows us to proceed only when the configuration comes from the PID and not from default properties (system, bundle context, metatype).

This is however not a case in Pax Web. All the tests run stable (or at least stable from configuration perspective) because of correct usage of ServiceListeners/ServiceTrackers.

I noticed that the pax-web activator is a managed service that will restart the webcontainer when finding a configuration file.

Not only that - it'll restart also when you stop pax-web-jetty bundle and start pax-web-tomcat for example ;)

My issue is that if I have a bundle dependent on the webcontainer how do I know if it's the default one vs my one?

The point is - you generally don't and you don't even have to.

Default configuration is taken from this metatype file: https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.32/pax-web-runtime/src/main/resources/OSGI-INF/metatype/metatype.xml

One of the defaults is org.osgi.service.http.port=8080, while in Karaf we ship (through PID) org.osgi.service.http.port=8181. That's how you may detect the kind of configuration used.

But I'd recommend something different - you're in OSGi, which is awesome technology and provides the level of dynamism no one really needs /s.

The point is that you should register a service tracker for HttpService/WebContainer which may be called with adding|modified|removedService and you should register/unregister servlets in these methods.

This is how ancient Pax Web HttpService samples are built: https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.32/samples/samples-httpservice

In org.ops4j.pax.web.service.internal.Activator.determineServiceProperties(Configuration) it filters out all my properties so I can't look for a custom property that I set.

Ideally it would pass any of the properties i set onto server properties so they stay with the webcontainer service reference no?

Actually no - this would be a hack into how OSGi was designed back in late 1990s.

You should treat services being registered/unregistered as something natural for OSGi, not something you should fight with.

[grgrzybek]

Adding separate comment for clarity.

You should rather switch from really ancient HttpService/WebContainer approach to more modern Whiteboard approach.

Instead of waiting for dynamically registered HttpService/WebContainer service to register your servlet using API of these interfaces, you should register your servlet as OSGi service and let Pax Web do its work.

With Whiteboard approach you register a servlet only once - you can use:

• org.osgi.framework.BundleContext#registerService()
• Blueprint
• DS

and Pax Web will use its own Servlet (and Filter and Listener and WelcomeFile and ErrorPage and JSP and Websocket and ServletContainerInitializer and ...) trackers to pick up your service and register/unregister it in dynamically created Servers (Jetty, Tomcat, Undertow - whatever the configuration).

There are many Whiteboard samples you could check: https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.32/samples/samples-whiteboard