Mirth Connect
  1. Mirth Connect
  2. MIRTH-3542

Configuration map does not handle certain special characters correctly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0, 3.1.1
    • Fix Version/s: 3.2.0
    • Component/s: Administrator, Server
    • Labels:
      None
    • Environment:
      Linux red hat 5.1 , Postgres 1.9
    • Operating System:
      Linux
    • Database:
      PostgreSQL

      Description

      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.

        Activity

        Hide
        Wayne Huang (Inactive) added a comment -

        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.

        Show
        Wayne Huang (Inactive) added a comment - 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.
        Hide
        Wayne Huang (Inactive) added a comment -

        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.

        Show
        Wayne Huang (Inactive) added a comment - 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.
        Hide
        Hugo Soares added a comment -

        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...

        Show
        Hugo Soares added a comment - 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...
        Show
        Nick Rupley added a comment - http://www.mirthcorp.com/community/forums/showthread.php?t=11891
        Hide
        Wayne Huang (Inactive) added a comment -

        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.

        Show
        Wayne Huang (Inactive) added a comment - 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.
        Hide
        Hugo Soares added a comment -

        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.

        Show
        Hugo Soares added a comment - 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.
        Hide
        Wayne Huang (Inactive) added a comment -

        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.

        Show
        Wayne Huang (Inactive) added a comment - 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.
        Hide
        Jaysen Patton added a comment -

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

        Show
        Jaysen Patton added a comment - Verified this issue existed in 3.1.1 but no longer exists in 3.2.

          People

          • Assignee:
            Wayne Huang (Inactive)
            Reporter:
            Hugo Soares
          • Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development