In order to take benefit from galleon layers feature, the servlet and full galleon feature-packs should define layers that could then be used to build custom installation. The layers are not intended to be exposed as a public contract, they are an implementation detail allowing for internal custom provisioning.
Only standalone configurations are impacted by layers.
We are proposing:
1) Define a set of servlet layers:
web-server (complete servlet container)
2) Express the servlet default standalone configurations by a set of layers. The default configuration based on layers would be identical to the current one (based on feature-groups). feature-groups are the place where feature configuration occurs, layers are referencing feature-groups. The default configuration extends layers with legacy security aspects and undertow welcome content.
3) Define a first set of full layers that target standalone kind of configurations.
List of layers, layers defined in this feature-pack depend at least on web-server servlet layer.
4) Some servlet layers are extended to include packages present in full feature-pack:
5) Cloud profile layer
cloud-profile (aggregation layer of cdi, jaxrs, jms-activemq,jpa,microprofile,resource-adapters)
6) Resource management API is used to advertise modules injected in deployment units. Impacted subsystems: ee, security, connector, microprofile, jpa, jaxrs, weld, bean-validation.