KARAF-6207, bootFeatures sometimes being ignored#791
KARAF-6207, bootFeatures sometimes being ignored#791jbonofre merged 1 commit intoapache:karaf-4.2.xfrom
Conversation
According to the documentation, the maven-karaf-plugin will install
features listed in the installedFeatures in the "system" internal
repository. Features listed in bootFeatures are additionally added to
the boot-features in the features service configuration file.
Hence, the configuration options do not conflict and a configuration
like this should result in the features being installed and added to the
boot-features configuration:
<configuration>
<bootFeatures>
<feature>foo</feature>
</bootFeatures>
<installedFeatures>
<feature>foo</feature>
</installedFeatures>
</configuration>
In fact, the configuration should be equivalent to `foo` being listed
just as a bootFeature.
But what actually happens is that the installedFeature will overwrite
the bootFeature and the feature is not added to the boot-features
configuration.
This patch switches the handling of bootFeatures and installedFeatures
which makes a feature configured in both sections a bootFeature,
adhering to the specifications of both configurations.
This patch extracts some core features into separate Karaf features. These features are installed by default, but not started by default. This means that they can be easily enabled but will not launch regardless of users needing those features or not. The idea behind this is to extract modules used by just a few users to minimize the code which is running by default, needing less resources, booting up faster and also minimizing the risk for security vulnerabilities. This patch extracts the Moodle and Sakai user provider as an example. More modules may follow. Long-term, it may make sense to still boot all features in the development distribution to ensure they are not easily broken without someone noticing. That will be easier once KARAF-6207 is fixed: - apache/karaf#791
|
It's one or the other: it doesn't makes sense to have the |
|
I consider that you configuration is not correct as it's "exclusive": the feature should be ONLY in boot, installed or startup. |
|
Hi @jbonofre, The configuration makes sense for a use case where you have a parent pom specifying all features which should be installed and then different child poms specifying specific features to boot up (but leaving the option to start the others): That makes sense because the documentation I found specified a bootFeature as an installedFeature which also gets an entry in the boot-features configuration. I didn't find any documentation of your claim that the feature configuration is meant to be exclusive. In any case, if you decide to make this exclusive, can you document that and (probably more important) make the maven-karaf-plugin throw an error and fail in such a case? Because right now the feature configurations are also not exclusive in the code. In the code, the behavior is that the installedFeature configuration takes precedence over the bootFeature configuration. |
This patch extracts some core features into separate Karaf features. These features are installed by default, but not started by default. This means that they can be easily enabled but will not launch regardless of users needing those features or not. The idea behind this is to extract modules used by just a few users to minimize the code which is running by default, needing less resources, booting up faster and also minimizing the risk for security vulnerabilities. This patch extracts the Moodle and Sakai user provider as an example. More modules may follow. Long-term, it may make sense to still boot all features in the development distribution to ensure they are not easily broken without someone noticing. That will be easier once KARAF-6207 is fixed: - apache/karaf#791
|
Yes, that's an implicit assertion. We should check that a feature doesn't appear in installed, boot, startup (it's only one). I will do the change. |
|
Waiting for the "exclusive" check, I'm merging your PR. |
This patch extracts some core features into separate Karaf features. These features are installed by default, but not started by default. This means that they can be easily enabled but will not launch regardless of users needing those features or not. The idea behind this is to extract modules used by just a few users to minimize the code which is running by default, needing less resources, booting up faster and also minimizing the risk for security vulnerabilities. This patch extracts the Moodle and Sakai user provider as an example. More modules may follow. Long-term, it may make sense to still boot all features in the development distribution to ensure they are not easily broken without someone noticing. That will be easier once KARAF-6207 is fixed: - apache/karaf#791
2 participants
According to the documentation, the maven-karaf-plugin will install
features listed in the installedFeatures in the "system" internal
repository. Features listed in bootFeatures are additionally added to
the boot-features in the features service configuration file.
Hence, the configuration options do not conflict and a configuration
like this should result in the features being installed and added to the
boot-features configuration:
In fact, the configuration should be equivalent to
foobeing listedjust as a bootFeature.
But what actually happens is that the installedFeature will overwrite
the bootFeature and the feature is not added to the boot-features
configuration.
This patch switches the handling of bootFeatures and installedFeatures
which makes a feature configured in both sections a bootFeature,
adhering to the specifications of both configurations.