[SLING-11220] Feature launcher loads from repository even if artifact is in FAR

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: Feature Model Launcher 1.1.26
• Fix Version/s: Feature Model Launcher 1.2.2
• Component/s: Feature Model, Starter
• Environment: MacOS, Java 17 or 11
• Assignee: Carsten Ziegeler
• Reporter: Hans-Peter Stoerr
• Created: 24/Mar/22 11:37
• Updated: 09/Dec/22 05:58
• Resolved: 28/Mar/22 06:07

Description

If the feature launcher is provided with a FAR, which contains all the artifacts for the features that should be launched, then it still tries to find the artifact in $HOME/.m2/repository and, if that fails, in https://repo.maven.apache.org/maven2 . If it cannot find it there, it logs a INFO log containing a stacktrace, and only then takes the artifact from the FAR. I think that's troublesome for several reasons:

• First in intranets or in a DMZ it's not guaranteed that you have internet access. Even worse: on production systems you don't want the starter to access the network or getting files from $HOME/.m2/repository, since that offers various attack avenues for injecting code into the system. So this behaviour is not exactly desirable.
• For the Sling Starter 12 there are are about 2900 lines with more than 245 stacktraces logged (see below).

It is currently possible to avoid those network / $HOME/.m2/repository accesses by explicitly specifying repository urls, so that the default entries aren't active. In a no network setting, it is currently even necessary to add at least one repository url that contains the felix framework. For this purpose I created a felixcontainer.jar that contains it in a repository like structure, so that the starter can be run like this, even without the stacktraces:

    java -jar org.apache.sling.feature.launcher.jar -f org.apache.sling.starter-12-oak_tar_far.far -u 'jar:file:org.apache.sling.starter-12-oak_tar_far.far!' -u 'jar:file:felixcontainer.zip!'

But this looks unpleasantly complicated. So I'm proposing several points:

1. The feature launcher should just take the artifacts from the FAR if they are there, and only consult any repositories if it isn't found there. This could be the default behaviour, or it should be configurable via a switch. (Please note that the current behaviour could be actually desirable in one setting: when started in a development setting, each restart of the feature launcher takes the newest artifacts from the local maven repository. So you wouldn't have to recreate the whole FAR to redeploy changes.)
2. When the behaviour is "FAR last", then at least the log message could log a message on INFO level and that stacktrace only DEBUG level, if it's required at all. (That's less confusing - initially I thought that's an error message and the FAR artifacts were completely ignored.)

This is the stacktrace that's logged 245 times:

[INFO] Artifact not found in one repository
java.io.FileNotFoundException: JAR entry commons-codec/commons-codec/1.15/commons-codec-1.15.jar not found in felixcontainer.zip
at java.base/sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:147)
at org.apache.sling.feature.io.artifacts.ArtifactManager$DefaultArtifactHandler.getArtifact(ArtifactManager.java:424)
at org.apache.sling.feature.io.artifacts.ArtifactManager.getArtifactHandler(ArtifactManager.java:248)
at org.apache.sling.feature.launcher.impl.FeatureProcessor$1.provide(FeatureProcessor.java:86)
at org.apache.sling.feature.launcher.impl.FeatureProcessor.lambda$createApplication$4(FeatureProcessor.java:120)
at org.apache.sling.feature.io.archive.ArchiveReader.read(ArchiveReader.java:121)
at org.apache.sling.feature.launcher.impl.FeatureProcessor.createApplication(FeatureProcessor.java:118)
at org.apache.sling.feature.launcher.impl.Bootstrap.assemble(Bootstrap.java:208)
at org.apache.sling.feature.launcher.impl.Bootstrap.run(Bootstrap.java:123)
at org.apache.sling.feature.launcher.impl.Main.main(Main.java:402)

 

Issue Links

• links to: conversation at [e-mail] about that