We are using log4j.properties file instead of ‘Log4JLogConfigInitializer’ for metadata sync logging purpose. The FILE parameter of FileAppender in log4j.properties needs the value of DHIS2_HOME environment variable to save the metadata sync log in the same folder location as that of the other logs. We are creating a system property specified in VM options when starting the DHIS server to get the value of environment variable and log4j.properties file can use that property.
We would be mentioning this in the documentation as well. Would like to hear your thoughts regarding this.
okay. It would be great if we do not introduce another way of doing logging. The problem is that resolving the DHIS2_HOME directory is a bit complex - the system looks for the system property dhis2.home, the env variable DHIS2_HOME, then falls back to opt/dhis2. log4j 1 does not support this type of custom logic directly. Perhaps log4j 2 does it, not exactly sure, but the upgrade path is a bit tricky.
Could you instead add a new logger in Log4JLogConfigInitializer for metadata sync? I.e.:
<DHIS2_HOME>/logs/dhis-metadata-sync.log
If you need to set a custom location for your log4j properties for testing purposes you can already set a custom log4j.properties location, see docs here:
We are using log4j.properties file instead of ‘Log4JLogConfigInitializer’ for metadata sync logging purpose. The FILE parameter of FileAppender in log4j.properties needs the value of DHIS2_HOME environment variable to save the metadata sync log in the same folder location as that of the other logs. We are creating a system property specified in VM options when starting the DHIS server to get the value of environment variable and log4j.properties file can use that property.
We would be mentioning this in the documentation as well. Would like to hear your thoughts regarding this.
The metadata versioning and sync is an optional feature. It totally depends on the deployment strategy that we want to adopt and given that whether we choose to do metadata sync or not.
For these reasons adding the metadata sync log as a first class citizen to the Log4JLogConfigInitializer does not sound like a good idea.
Let me know your thoughts?
Regards
Vanya
···
On Wed, Jun 15, 2016 at 12:41 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi there,
okay. It would be great if we do not introduce another way of doing logging. The problem is that resolving the DHIS2_HOME directory is a bit complex - the system looks for the system property dhis2.home, the env variable DHIS2_HOME, then falls back to opt/dhis2. log4j 1 does not support this type of custom logic directly. Perhaps log4j 2 does it, not exactly sure, but the upgrade path is a bit tricky.
Could you instead add a new logger in Log4JLogConfigInitializer for metadata sync? I.e.:
<DHIS2_HOME>/logs/dhis-metadata-sync.log
If you need to set a custom location for your log4j properties for testing purposes you can already set a custom log4j.properties location, see docs here:
We are using log4j.properties file instead of ‘Log4JLogConfigInitializer’ for metadata sync logging purpose. The FILE parameter of FileAppender in log4j.properties needs the value of DHIS2_HOME environment variable to save the metadata sync log in the same folder location as that of the other logs. We are creating a system property specified in VM options when starting the DHIS server to get the value of environment variable and log4j.properties file can use that property.
We would be mentioning this in the documentation as well. Would like to hear your thoughts regarding this.
However this is fine with me - this logging is not visible to users and there won’t even be produced a log file if the sync isn’t enabled, so I’m fine with you adding a new logger to Log4JLogConfigInitializer. Let me know what you think.
The metadata versioning and sync is an optional feature. It totally depends on the deployment strategy that we want to adopt and given that whether we choose to do metadata sync or not.
For these reasons adding the metadata sync log as a first class citizen to the Log4JLogConfigInitializer does not sound like a good idea.
Let me know your thoughts?
Regards
Vanya
–
On Wed, Jun 15, 2016 at 12:41 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi there,
okay. It would be great if we do not introduce another way of doing logging. The problem is that resolving the DHIS2_HOME directory is a bit complex - the system looks for the system property dhis2.home, the env variable DHIS2_HOME, then falls back to opt/dhis2. log4j 1 does not support this type of custom logic directly. Perhaps log4j 2 does it, not exactly sure, but the upgrade path is a bit tricky.
Could you instead add a new logger in Log4JLogConfigInitializer for metadata sync? I.e.:
<DHIS2_HOME>/logs/dhis-metadata-sync.log
If you need to set a custom location for your log4j properties for testing purposes you can already set a custom log4j.properties location, see docs here:
We are using log4j.properties file instead of ‘Log4JLogConfigInitializer’ for metadata sync logging purpose. The FILE parameter of FileAppender in log4j.properties needs the value of DHIS2_HOME environment variable to save the metadata sync log in the same folder location as that of the other logs. We are creating a system property specified in VM options when starting the DHIS server to get the value of environment variable and log4j.properties file can use that property.
We would be mentioning this in the documentation as well. Would like to hear your thoughts regarding this.
On Wed, Jun 15, 2016 at 2:37 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Vanya,
I understand your concerns here.
However this is fine with me - this logging is not visible to users and there won’t even be produced a log file if the sync isn’t enabled, so I’m fine with you adding a new logger to Log4JLogConfigInitializer. Let me know what you think.
The metadata versioning and sync is an optional feature. It totally depends on the deployment strategy that we want to adopt and given that whether we choose to do metadata sync or not.
For these reasons adding the metadata sync log as a first class citizen to the Log4JLogConfigInitializer does not sound like a good idea.
On Wed, Jun 15, 2016 at 12:41 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi there,
okay. It would be great if we do not introduce another way of doing logging. The problem is that resolving the DHIS2_HOME directory is a bit complex - the system looks for the system property dhis2.home, the env variable DHIS2_HOME, then falls back to opt/dhis2. log4j 1 does not support this type of custom logic directly. Perhaps log4j 2 does it, not exactly sure, but the upgrade path is a bit tricky.
Could you instead add a new logger in Log4JLogConfigInitializer for metadata sync? I.e.:
<DHIS2_HOME>/logs/dhis-metadata-sync.log
If you need to set a custom location for your log4j properties for testing purposes you can already set a custom log4j.properties location, see docs here:
We are using log4j.properties file instead of ‘Log4JLogConfigInitializer’ for metadata sync logging purpose. The FILE parameter of FileAppender in log4j.properties needs the value of DHIS2_HOME environment variable to save the metadata sync log in the same folder location as that of the other logs. We are creating a system property specified in VM options when starting the DHIS server to get the value of environment variable and log4j.properties file can use that property.
We would be mentioning this in the documentation as well. Would like to hear your thoughts regarding this.
On Wed, Jun 15, 2016 at 2:37 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Vanya,
I understand your concerns here.
However this is fine with me - this logging is not visible to users and there won’t even be produced a log file if the sync isn’t enabled, so I’m fine with you adding a new logger to Log4JLogConfigInitializer. Let me know what you think.
The metadata versioning and sync is an optional feature. It totally depends on the deployment strategy that we want to adopt and given that whether we choose to do metadata sync or not.
For these reasons adding the metadata sync log as a first class citizen to the Log4JLogConfigInitializer does not sound like a good idea.
On Wed, Jun 15, 2016 at 12:41 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi there,
okay. It would be great if we do not introduce another way of doing logging. The problem is that resolving the DHIS2_HOME directory is a bit complex - the system looks for the system property dhis2.home, the env variable DHIS2_HOME, then falls back to opt/dhis2. log4j 1 does not support this type of custom logic directly. Perhaps log4j 2 does it, not exactly sure, but the upgrade path is a bit tricky.
Could you instead add a new logger in Log4JLogConfigInitializer for metadata sync? I.e.:
<DHIS2_HOME>/logs/dhis-metadata-sync.log
If you need to set a custom location for your log4j properties for testing purposes you can already set a custom log4j.properties location, see docs here:
We are using log4j.properties file instead of ‘Log4JLogConfigInitializer’ for metadata sync logging purpose. The FILE parameter of FileAppender in log4j.properties needs the value of DHIS2_HOME environment variable to save the metadata sync log in the same folder location as that of the other logs. We are creating a system property specified in VM options when starting the DHIS server to get the value of environment variable and log4j.properties file can use that property.
We would be mentioning this in the documentation as well. Would like to hear your thoughts regarding this.
Please advise how can I export metadata from 2.18 and import to 2.23. The error i get is:
Caused by: com.fasterxml.jackson.databind.exc.InvalidFormatException: Can not construct instance of org.hisp.dhis.organisationunit.FeatureType from String value ‘Polygon’: value not one of declared Enum instance names: [SYMBOL, POLYGON, MULTI_POLYGON, NONE, POINT]
at [Source: java.util.zip.ZipInputStream@29899aa7; line: 1, column: 1062] (through reference chain: org.hisp.dhis.dxf2.metadata.Metadata[“organisationUnits”]->java.util.ArrayList[1]->org.hisp.dhis.organisationunit.OrganisationUnit[“featureType”])
From 2.18 to 2.23 there have been quite a large number of changes. For your exact issue, it is related to the fact that organisation unit feature type was changed from a simple string, to a set of pre-defined constants.
In the particular case you have here, you need to change Polygon to POLYGON, but if you are importing a large payload of metadata, you will probably see lots of other issues.
···
On Thu, Jun 16, 2016 at 12:28 AM, Juma Lungo jlungo@yahoo.com wrote:
Hi
Please advise how can I export metadata from 2.18 and import to 2.23. The error i get is:
Caused by: com.fasterxml.jackson.databind.exc.InvalidFormatException: Can not construct instance of org.hisp.dhis.organisationunit.FeatureType from String value ‘Polygon’: value not one of declared Enum instance names: [SYMBOL, POLYGON, MULTI_POLYGON, NONE, POINT]
at [Source: java.util.zip.ZipInputStream@29899aa7; line: 1, column: 1062] (through reference chain: org.hisp.dhis.dxf2.metadata.Metadata[“organisationUnits”]->java.util.ArrayList[1]->org.hisp.dhis.organisationunit.OrganisationUnit[“featureType”])
From 2.18 to 2.23 there have been quite a large number of changes. For your exact issue, it is related to the fact that organisation unit feature type was changed from a simple string, to a set of pre-defined constants.
In the particular case you have here, you need to change Polygon to POLYGON, but if you are importing a large payload of metadata, you will probably see lots of other issues.
On Thu, Jun 16, 2016 at 12:28 AM, Juma Lungo jlungo@yahoo.com wrote:
Hi
Please advise how can I export metadata from 2.18 and import to 2.23. The error i get is:
Caused by: com.fasterxml.jackson.databind.exc.InvalidFormatException: Can not construct instance of org.hisp.dhis.organisationunit.FeatureType from String value ‘Polygon’: value not one of declared Enum instance names: [SYMBOL, POLYGON, MULTI_POLYGON, NONE, POINT]
at [Source: java.util.zip.ZipInputStream@29899aa7; line: 1, column: 1062] (through reference chain: org.hisp.dhis.dxf2.metadata.Metadata[“organisationUnits”]->java.util.ArrayList[1]->org.hisp.dhis.organisationunit.OrganisationUnit[“featureType”])