[PAYARA-3909] - Can't Use Any of the Variable Types in JDBC Connection Pool Settings #4075
Conversation
|
Jenkins test please |
...c-config/src/main/java/org/glassfish/jdbc/config/validators/JdbcConnectionPoolValidator.java
Show resolved
Hide resolved
...c-config/src/main/java/org/glassfish/jdbc/config/validators/JdbcConnectionPoolValidator.java
Show resolved
Hide resolved
|
Jenkins test please |
| * | ||
| * @return possible object is | ||
| * {@link String } | ||
| */ | ||
| @Attribute (defaultValue="32") | ||
| @Min(value=1) | ||
| @Max(value=Integer.MAX_VALUE) | ||
| String getMaxPoolSize(); |
There was a problem hiding this comment.
Isn't removing the min/max value begging for illegal values to be configured? Shouldn't they be at least checked for in code somewhere? Or rather keep them and extend validation to allow for variables whose value may be validated as well.
There was a problem hiding this comment.
I agree it is a rather risky move, although as far as I'm aware these annotations will always cause a validation exception in the event that a user tries to input a string that cannot be parsed to an Integer (as would be the case with a system variable name) I've altered the basic check in the implementation of JdbcConnectionPool so as to prevent the value from being below 1 but I do agree that it isn't the safest situation
There was a problem hiding this comment.
I think @svendiedrichsen has a good point here. Surely extending the mechanism isn't part of the task as originally requested but if we don't include this or make it a precondition of this PR we introduce room for error that might never be closed again even when we would like to see this happen in the near future.
|
How about supporting the existing variable mechanism and its different types here: https://docs.payara.fish/documentation/payara-server/server-configuration/var-substitution/ Would thus automatically support MicroProfile config. |
|
Jenkins test please |
|
|
||
| //By this point it should be the case that the value is always castable | ||
| //to an integer | ||
| maxPoolSizeValue = Integer.parseInt(maxPoolSize); |
There was a problem hiding this comment.
This will cause NumberFormatException if the string does not have the appropriate numeric value.
| default: | ||
| //We got a system variable as no split occured | ||
| if (systemProps.getProperty(variableReference[0]) != null && !systemProps.getProperty(variableReference[0]).isEmpty()) { | ||
| return systemProps.getProperty(variableReference[0]); |
There was a problem hiding this comment.
Can't you just simply use System.getProperty(variableToRetrieve) here.
|
Jenkins Test Please |
| switch(variableReference[0]) { | ||
| case "ENV": | ||
| //Check environment variables for requested value | ||
| if (System.getenv(variableReference[1]) != null && !System.getenv(variableReference[1]).isEmpty()) { |
There was a problem hiding this comment.
System.getenv(variableReference[1]) should be extracted to local var
| case "MPCONFIG": | ||
| //Check microprofile config for requested value | ||
| Config config = ConfigProvider.getConfig(); | ||
| if (config.getValue(variableReference[1], String.class) != null && !config.getValue(variableReference[1], String.class).isEmpty()) { |
There was a problem hiding this comment.
config.getValue(variableReference[1], String.class) should be extracted to local var
| break; | ||
| default: | ||
| //We got a system variable as no split occured | ||
| if (System.getProperty(variableReference[0]) != null && !System.getProperty(variableReference[0]).isEmpty()) { |
| if(steadyPoolSize == null) { | ||
|
|
||
| int maxPoolSizeValue = 0; | ||
| int steadyPoolSizeValue = 0; |
There was a problem hiding this comment.
It should be possible to add a helper function where the min/max/default and actual value go in and the successfully parsed or resolved value comes out that can be used for both of these. Essentially making a method that does the extended version of that the annotations did semantically.
|
Jenkins Test Please |
It is desired that variable types can be used in place of set values in JDBC connection pool settings (i.e. set maxPoolSize = ${MAX_POOL_SIZE_PROPERTY}) - this was previously not possible due to the validation process of JDBC connection pool properties (results in a NumberFormatException trying to parse an incorrect format string to an Integer) - the changes in this PR get around that