dawidwys edited a comment on pull request #12475:
URL: https://github.com/apache/flink/pull/12475#issuecomment-638692230
@leonardBang Have you verified the fix? Unfortunately it does not work.
@godfreyhe I am not exactly sure what is your suggested solution, so sorry
if I am wrong here. However, it is not enough to wrap instance of the parser
with the `wrapClassloader`. The actual call to a method that requires the
classloader must be wrapped.
I think the quickest though, dirty solution would be that:
```
@Override
public Parser getSqlParser(String sessionId) {
final ExecutionContext<?> context = getExecutionContext(sessionId);
final TableEnvironment tableEnv = context.getTableEnvironment();
final Parser parser = ((TableEnvironmentInternal) tableEnv).getParser();
return new Parser() {
@Override
public List<Operation> parse(String statement) {
return context.wrapClassLoader(() ->
parser.parse(statement));
}
@Override
public UnresolvedIdentifier parseIdentifier(String identifier) {
return context.wrapClassLoader(() ->
parser.parseIdentifier(identifier));
}
};
}
```
Better solutions I could think of are:
1. Do not instantiate the sources during parsing. I don't see a reason for
that. IMO the logical plan could have just the CatalogTable, it does not
necessary need to have an instantiated DynamicTableSource already. This is very
demanding solution that requires lots of changes in the planner.
2. Wrap the call to `sqlParser.parse` in
`org.apache.flink.table.client.cli.SqlCommandParser`. This is tricky as we do
not have access to the user classloader there.
----------------------------------------------------------------
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
