kotwal-itpro commented on issue #8868: URL: https://github.com/apache/hop/issues/8868#issuecomment-6129059720
I think this comes from an old passwords plugin jar, not from 2.19 itself, which would explain why a clean 2.19 works for @hansva and @bamaer. The stack trace points at `Aes2TwoWayPasswordEncoder.init`, line 60, calling `org.apache.commons.lang.StringUtils`. In 2.19.0 (and already in 2.18) that class imports `org.apache.commons.lang3.StringUtils`, and line 60 isn't a `StringUtils` call. In 2.17.0 the class imported `org.apache.commons.lang.StringUtils`, and line 60 is exactly `if (StringUtils.isEmpty(aesKey))`. So the JVM is loading the 2.17-era `hop-misc-passwords` jar, and since 2.19 no longer ships `commons-lang.jar`, it can't find the class. It also only shows up with the AES2 password encoder: Hop loads that class only when `HOP_PASSWORD_ENCODER_PLUGIN=AES2` is set. The default encoder never touches it. @awesomeossdataengineer, could you check: 1. whether `plugins/misc/passwords/` in your 2.19 folder contains more than one `hop-misc-passwords-*.jar` (for example a 2.17 jar left over from an upgrade in place), or whether `HOP_PLUGIN_BASE_FOLDERS` points at an older Hop installation (as @bamaer suggested); 2. `echo $HOP_PASSWORD_ENCODER_PLUGIN`, which I'd expect to be `AES2`. If that's it, removing the old jar (or extracting 2.19 into a fresh folder and copying only your config) should fix it. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
