-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not discover properties resource in the classpath to avoid missing resources registration in native mode #44910
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
… resources registration in native mode
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
package io.quarkus.runtime.configuration; | ||
|
||
import static io.smallrye.config.PropertiesConfigSourceLoader.inFileSystem; | ||
|
||
import java.nio.file.Paths; | ||
|
||
import io.smallrye.config.SmallRyeConfigBuilder; | ||
|
||
/** | ||
* Do not register classpath resources lookup in native mode to avoid missing resources registration errors, which | ||
* became a strict check during native image execution. | ||
* <p> | ||
* Configuration coming from classpath resources is recoded during build time in a low ordinal source, so the | ||
* configuration will still be available. If the users change the ordinals of the sources in runtime, it may | ||
* cause unexpected values to be returned by the config, but this has always been the case. The classpath configuration | ||
* resources were never registered in the native image. | ||
*/ | ||
public class NativeConfigBuilder implements ConfigBuilder { | ||
@Override | ||
public SmallRyeConfigBuilder configBuilder(final SmallRyeConfigBuilder builder) { | ||
builder | ||
.setAddDefaultSources(false) | ||
.setAddSystemSources(true) | ||
.setAddPropertiesSources(false); | ||
|
||
builder.withSources(inFileSystem( | ||
Paths.get(System.getProperty("user.dir"), "config", "application.properties").toUri().toString(), 260, | ||
builder.getClassLoader())); | ||
|
||
return builder; | ||
} | ||
|
||
@Override | ||
public int priority() { | ||
return Integer.MIN_VALUE + 100; | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,11 @@ | ||
package io.quarkus.runtime.configuration; | ||
|
||
import java.net.URI; | ||
import java.util.Collections; | ||
import java.util.List; | ||
|
||
import org.eclipse.microprofile.config.spi.ConfigProviderResolver; | ||
import org.eclipse.microprofile.config.spi.ConfigSource; | ||
|
||
import com.oracle.svm.core.annotate.Alias; | ||
import com.oracle.svm.core.annotate.RecomputeFieldValue; | ||
|
@@ -9,6 +14,7 @@ | |
import com.oracle.svm.core.annotate.TargetElement; | ||
|
||
import io.smallrye.common.constraint.Assert; | ||
import io.smallrye.config.AbstractLocationConfigSourceLoader; | ||
import io.smallrye.config.ConfigMappingInterface; | ||
import io.smallrye.config.ConfigMappingLoader; | ||
import io.smallrye.config.ConfigMappingMetadata; | ||
|
@@ -99,4 +105,12 @@ public byte[] getClassBytes() { | |
return null; | ||
} | ||
} | ||
|
||
@TargetClass(value = AbstractLocationConfigSourceLoader.class) | ||
static final class Target_AbstractLocationConfigSourceLoader { | ||
@Substitute | ||
protected List<ConfigSource> tryClassPath(final URI uri, final int ordinal, final ClassLoader classLoader) { | ||
return Collections.emptyList(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If what my previous comment is right, this is a breaking (for quite a corner case I admit) change, no? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, this could be a breaking change if a user has a custom source with a custom resource. If they are registering the resource manually they would need to process the file and generate some sort of representation (like us) for runtime. Unfortunately, I don't see any good alternative. Having to forcely register all the resources is going to throw away all of our optimizations. If we leave it as is, you get the error that we are trying to prevent. (Well I guess we could add a try / catch there instead). I still think it doesn't make sense to apply that validation to an API like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I am personally fine with this, since it's a corner case. I am not even sure we need to document this kind of "breakage". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @radcortez I went on with adding a try/catch. Please have a look. |
||
} | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
package io.quarkus.config.yaml.runtime; | ||
|
||
import java.util.ArrayList; | ||
import java.util.List; | ||
|
||
import org.eclipse.microprofile.config.spi.ConfigSourceProvider; | ||
|
||
import io.quarkus.runtime.configuration.ConfigBuilder; | ||
import io.smallrye.config.SmallRyeConfigBuilder; | ||
import io.smallrye.config.source.yaml.YamlConfigSourceLoader; | ||
|
||
public class YamlInFileSystemConfigBuilder implements ConfigBuilder { | ||
@Override | ||
public SmallRyeConfigBuilder configBuilder(final SmallRyeConfigBuilder builder) { | ||
// Removes Yaml source providers added by the ServiceLoader to avoid double registration | ||
List<ConfigSourceProvider> toRemove = new ArrayList<>(); | ||
for (ConfigSourceProvider sourceProvider : builder.getSourceProviders()) { | ||
if (sourceProvider instanceof YamlConfigSourceLoader) { | ||
toRemove.add(sourceProvider); | ||
} | ||
} | ||
builder.getSourceProviders().removeAll(toRemove); | ||
return builder.withSources(new YamlConfigSourceLoader.InFileSystem()); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this true?
In oracle/graal#10264 (reply in thread) we describe a scenario were using the classpath would work fine (assuming the user registers the resource for reflection and sets the ordinals accordingly).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With our stuff yes, we never registered the resources. The configuration is just included in a class file and we discard the resources, which may cause the issue described in #44652 (comment), but this has been an issue since day one and until now we never got any complaints about it.