Skip to content
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

Configuration map does not handle certain special characters correctly #3438

Closed
rbeckman-nextgen opened this issue May 11, 2020 · 8 comments
Closed
Milestone

Comments

@rbeckman-nextgen
Copy link
Collaborator

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

put a long text into a configuration map and save.
all goes well and the map value can be used.

go to linux shell and :

sudo service mcservice restart

the map value is now trimmed to 77 chars...

In my case I am using config maps to save a json formated text.

Imported Issue. Original Details:
Jira Issue Key: MIRTH-3542
Reporter: hugosoares2
Created: 2014-12-05T10:50:35.000-0800

@rbeckman-nextgen rbeckman-nextgen added this to the 3.2.0 milestone May 11, 2020
@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

I don't think a character limit is causing this. The configuration map is stored in a properties file when it is saved. Therefore there are limitations on what content can be stored in it. If there is a line break in your string it will most likely not be saved into the configuration file. The reason it works initially is because we load it directly into memory when saving before saving it to the properties file. So when you restart MC it then loads from the properties file.

Can you check what is the 78th character in your string. If it is a line break or something weird then that would explain it.

Imported Comment. Original Details:
Author: wayneh
Created: 2014-12-05T13:25:46.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

We should probably be loading the map from the file after saving, rather than injecting directly from what's sent to the server. This way these types of issues would be found upon saving and testing rather than after a restart.

Imported Comment. Original Details:
Author: wayneh
Created: 2014-12-05T13:35:38.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

The 78th char is a comma (basically I putting json formated text in a config map).
Why would you save this map in a properties file?! You have reduced its use a lot...

Imported Comment. Original Details:
Author: hugosoares2
Created: 2014-12-09T02:15:35.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

[http://www.mirthcorp.com/community/forums/showthread.php?t=11891]

Imported Comment. Original Details:
Author: narupley
Created: 2014-12-09T11:32:20.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

It appears that commas and other special characters are not being escaped properly.

As far as the rationale behind using a properties file, the (current) intent of the configuration map is to facilitate users that share the same channels between multiple instance of Mirth Connect. For instance if you have a test/prod server with a TCP sender and the only difference between servers is the ip/port. By using the configuration map, when you make changes to the channel on test you no longer need to remember to change the ip/port before pushing it to prod. The same can apply for code templates as well. Also the configuration map is tied to a server regardless of database. If you point that server to a new database, the configuration map settings will remain. For these reasons it is not feasible to store it in the database. To support these use cases others may need to be sacrificed.

Perhaps if you describe what your use case is for storing a JSON string in the configuration map, we can evaluate it in the future.

Imported Comment. Original Details:
Author: wayneh
Created: 2014-12-09T12:01:30.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Our JSON string baically contains information about the current environment PROD,DEV, QC... (various default values)
This information is then used by a a channel wich is responsible for the overall "environment configuration", basically it is a config channel.
We have config channels for prod, dev, qual, etc and each of them reads a config map value with key = channel name.
Before 3.1.1 we used a file stored in the mirth server (also with the same name as the config channel).
This way we centralize all configuration loading in a single channel.
The only problem we have with this aproach is that this config channel "should" preced the deploy of all others (currently not possible to set channel dependencies). We need to sort that out by possibly developing a custom extension to manage our configurations(unfortunatly you guys dont's make it very easy to extend mirth with plugins :) ).

We found that simply using a lot of spread out map keys all around mirth was not manageable and found a way of managing configurations in a way that makes sense for our platform.

Imported Comment. Original Details:
Author: hugosoares2
Created: 2014-12-10T07:31:13.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Disabled delimiter parsing when loading the configuration map.

Not doing this caused values saved with commas to be read only up to the first comma.

Imported Comment. Original Details:
Author: wayneh
Created: 2014-12-22T16:16:06.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Verified this issue existed in 3.1.1 but no longer exists in 3.2.

Imported Comment. Original Details:
Author: jaysenp
Created: 2015-01-19T17:53:50.000-0800

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.