You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The deploy will, by default, just go into dropins/spring unlike the deployment of regular (non-SB) WAR/EAR packages, in which the default path is calculated based on whether there is any app deployment configuration detected in server.xml config.
If I explicitly configure liberty-maven-plugin to use the 'apps' directory for deploy:
<appsDirectory>apps</appsDirectory>
it will always generate a config dropin. It will likewise not look for a springBootApplication at a matching location.
Though we have tests for each type of generated config, I don't think we test with explicitly-provided config in server.xml.
CONSEQUENCE
Depending on the values specified, this could surface with messages like:
[WARNING] CWWKM2179W: ...
OR
[INFO] [ERROR ] CWWKZ0013E: It is not possible to start two applications called ...
Do a mvn package liberty:create liberty:deploy just to generate the deployment configDropin.
Take the generated config dropin and look at the contents, e.g. cat configDropins/defaults/install_apps_configuration_1491924271.xml to see something like:
Copy this element into server.xml and expand to add an end tag as well:
<springBootApplicationid="spring-web-ee"location="thin-spring-web-ee-0.0.1-SNAPSHOT.war"name="spring-web-ee">
<!-- Now you can add the app args here -->
</springBootApplication>
By matching the generated id, location and name in the explicit config in server.xml, we can cleanly merge over the config dropin-generated app config, and use what's specified in server.xml
PROPOSAL
It seems the most obvious thing is to follow the same pattern used for WAR/EAR deployment, as mentioned previously.
A couple other notes:
we should consider honoring the liberty-maven-plugin <stripVersion>true</stripVersion> config.
This issue to me suggests an idea I've considered now and again, which is to give 'deploy' its own special skipDeploy parm.
Besides perhaps working around this issue... it might be more generally useful dealing with SpringBoot since we have both the original WAR and SB plugin-repackaged WAR.
In the meantime we can always configure our own skip in the dev/run goals with:
For a deployment of a SpringBoot packaged app, with liberty-maven-plugin config:
I can't specify server.xml config like:
The deploy will, by default, just go into dropins/spring unlike the deployment of regular (non-SB) WAR/EAR packages, in which the default path is calculated based on whether there is any app deployment configuration detected in server.xml config.
If I explicitly configure liberty-maven-plugin to use the 'apps' directory for deploy:
it will always generate a config dropin. It will likewise not look for a springBootApplication at a matching location.
Though we have tests for each type of generated config, I don't think we test with explicitly-provided config in server.xml.
CONSEQUENCE
Depending on the values specified, this could surface with messages like:
OR
More directly, the config the user intends to set from the
<springBootApplication>
element https://openliberty.io/docs/latest/reference/config/springBootApplication.html won't take effect.WORKAROUND
Do a
mvn package liberty:create liberty:deploy
just to generate the deployment configDropin.Take the generated config dropin and look at the contents, e.g.
cat configDropins/defaults/install_apps_configuration_1491924271.xml
to see something like:By matching the generated id, location and name in the explicit config in server.xml, we can cleanly merge over the config dropin-generated app config, and use what's specified in server.xml
PROPOSAL
It seems the most obvious thing is to follow the same pattern used for WAR/EAR deployment, as mentioned previously.
A couple other notes:
<stripVersion>true</stripVersion>
config.The text was updated successfully, but these errors were encountered: