-
Notifications
You must be signed in to change notification settings - Fork 23
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
Unable to construct the decryptor due to lack of decryption password #314
Comments
Someone has reported this issue right after the 1.6.2 release. I debugged into it and found that the issue is the parameterization updates all config files unless it is in the exclude list of the config.json file. The workaround is to update the existing config.json to add config.yml into the exclude list; however, this is only a temp solution. I have listed this issue as part of #307 |
I think the problem lies in codegen's own configuration file config.json. Because config.yml in the framework is the configuration file of the configuration module, its function is to control the injection of parameters, and it should not be an injectable mode itself. So if we set config.json to the following: "generateEnvVars": {
"generate": true,
"skipArray": true,
"skipMap": true,
"exclude": [
"handler.yml",
"values.yml"
]
} Then the generated config.yml will be like this, decryptorClass: ${config.decryptorClass:com.networknt.decrypt.AESDecryptor} this is not correct, so we need to update the config.json to exclude config.yml from being a injection mode: "generateEnvVars": {
"generate": true,
"skipArray": true,
"skipMap": true,
"exclude": [
"handler.yml",
"values.yml",
"config.yml"
]
} The config.yml generated in this way is correct. decryptorClass: com.networknt.decrypt.AESDecryptor If you agree with this, I will document it soon. Thanks |
Hi @jiachen1120 : The documentation for this change is missing, and it was not added to the release notes either at the time of the release of this change. You can document it as such, while clearly indicating that the codegen is not backwards compatible, until we are rationalizing the light-codegen a bit. This can be done in a couple of steps |
@ddobrin Yes, I agree. I think the |
@jiachen1120 We can do it for config.yml but there might be other files in the future. The problem with the exclude list is that there is no way we can make it backward compatible with new config files added to the system. At this stage, I am thinking to remove the parameterization and move the config files into the template so that we can control it very easily. |
@stevehu Hello, I am not very understanding |
@jiachen: I see this as a series of small steps:
I am looking at the first one for my client (they have customized some of the files, as they have some defaults working well for them) and will update all of you with client fedback |
@ddobrin: Agreed. After having a discussion with Steve, a possible solution would be:
Look forward to your client feedback, then, we can RFC it. |
@jiachen1120 @stevehu : Parameterization by individual file name is not going to be sufficient; we must support also one for a folder, where we allow people to specify "param everything in this folder" or separately allow them to provide a list of "param the entire list from here". this, in addition to what you mention as -p . |
@ddobrin Yes, I think to provide a folder path after the -p make more sense! Thanks |
…to fix/#314-config-parameterization
Maybe you forget to add fixes #314 in the release 1.6.5 ? https://github.com/networknt/light-codegen/releases |
@NicolasFCO #314 is in the 1.6.5 release; however, the default branch is not updated after the release. We need to think about how to provide the command line jar files to the end-users as we have multiple versions released at the same time. Let's have a chat offline. |
The source code for the release is attached in each release. You can download and unzip into the networknt workspace and compile it. I am trying to find a way to automatically upload the final jar file to our portal site so that you can download it from there. Also, you can try the light-codegen website to see if it works for you. https://codegen.lightapi.net/form/codeGenSingleForm |
The codegen sets the decryptor in the config.json:
decryptorClass: ${config.decryptorClass:com.networknt.decrypt.AESDecryptor}
The service skeleton, after build, fails to start.
Resetting it to:
decryptorClass: com.networknt.decrypt.AESDecryptor, works.
This change is backwards incompatible with existing API code generation.
Is it documented somewhere, as I see an PR was addressed in the last release?
The text was updated successfully, but these errors were encountered: