ppalaga commented on a change in pull request #647: Fix #518 Rely on
configurers for Configuration classes instead of using
URL: https://github.com/apache/camel-quarkus/pull/647#discussion_r370116321
##########
File path:
extensions/core/deployment/src/main/java/org/apache/camel/quarkus/core/deployment/NativeImageProcessor.java
##########
@@ -68,6 +71,66 @@
PropertiesComponent.class,
DataFormat.class);
+ /**
+ * A list of classes annotated with <code>@UriParams</code> which we
accept to be registered for reflection
+ * mostly because there are errors when they are removed. TODO: solve
the underlying problems and remove as
+ * many entries as possible from the list.
+ */
+ private static final Set<String> URI_PARAMS_WHITELIST = new
HashSet<>(Arrays.asList(
+ "org.apache.camel.support.processor.DefaultExchangeFormatter",
+ "org.apache.camel.component.pdf.PdfConfiguration",
+ "org.apache.camel.component.netty.NettyConfiguration",
+
"org.apache.camel.component.netty.NettyServerBootstrapConfiguration",
+
"org.apache.camel.component.fhir.FhirUpdateEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirOperationEndpointConfiguration",
+ "org.apache.camel.component.fhir.FhirConfiguration",
+
"org.apache.camel.component.fhir.FhirLoadPageEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirSearchEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirTransactionEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirCreateEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirValidateEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirReadEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirCapabilitiesEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirHistoryEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirMetaEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirPatchEndpointConfiguration",
+
"org.apache.camel.component.fhir.FhirDeleteEndpointConfiguration",
Review comment:
> I really do not like to have to touch core to make an extension working so
if it were me to decide, I'd go for a simple build item.
I still think policy definitions are better to keep centrally, but OK, let
me try to implement this with a build item.
> also, I do not know it it really make sense to put such enforcement
Well, I think this is the most effective, scalable (and sustainable) way to
reduce the use of reflection. I do not think it is possible to be able to keep
control once we will have 100+ extensions.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
