What is your opinion on using the ConfigAdmin for a declarative connector definition?
We could make use of the newly refactored constants from `WebContainerConstants`. A `ManagedServiceFactory` could transform the individual configuration to a ServerConnector (e.g. in Jetty) and register it as service in the OSGi registry. When it is possible that the Jetty, Tomcat and Undertow container run simultaneously, then we must equip each container bundle with an individual `ManagedServiceFactory` implementaion each having its own PID. This solution would require an optional dependencies to the ConfigAdmin packages.
Another solution would be to use SCR for connector creation. When we plan things correctly from scratch the container bundles would have only the SCR component definition files in place. The component implementation themselves would have no compile-time dependency to SCR or the ConfigAdmin packages.
It could be a solution, though that would lead us to two configuration files for pax-web.
One point can already be declined, Jetty, Tomcat and Undertow will never run simultaneously. So it'll be one Manager for the runtime.
The last paragraph I don't quite get. SCR (If your talking of DeclarativeServices) is just another way of creating Services (actually it's just another xml file parsed at runtime, just like blueprint). It makes it easier in using services, certain bundles already use DS, other still have their own trackers.
Yes, I am sorry I actually mean Apache SCR (Declarative Services). DS offers the possibilty with configuration-policy=“required“ to have a one-to-one correspondance between a configuration provided by the ConfigAdmin and a corresponding service. That means that the creation of a configuration results in a service creation and registration. I like this pattern very much, because the service's lifecycle now depends on the configuration, which means that you can update and delete the configuration resulting either in a service update or deregistration.
Do you prefer a "real" API for connector creation?
It's good to know that the containers should not run simultaneously. Thanks!
actually it's no big deal if it's ds or plain old OSGi, nevertheless this will lead us to two separate configuration files, which I rather avoid.
As one PID is always bound to one service.
Then we have to decide if the user gets the possibility to create, register, update and delete (Jetty) connector instances directly using ServerConnector or if we offer him another API. It think we should try to hide as many details about the underlying container implementation as possible. The user should not get a server reference and should not have to import any (Jetty) packages for connector management. The solution provided by Felix (https://github.com/apache/felix/blob/trunk/http/jetty/src/main/java/org/apache/felix/http/jetty/ConnectorFactory.java) is one option, but it publishes too many internal Jetty implementation details.