Well you have several options:

1) Wait until 1.12.5 is released
2) Install the latest RPM snapshot of 1.12.5-SNAPSHOT from http://yum.opennms.org/testing/common/opennms/
3) Download the source code of OpenNMS from GitHub, checkout the tag for 1.12.1, then cherry pick the solution (3f75b490051484300d32cf359c19763ae23c4006), recompile protocols/xml, then copy protocols/xml/target/org.opennms.protocols.xml-1.12.1.jar

About the upgrade process, the must complicated thing is to do the merge of the configuration files. Sometimes, from one version to another, some files are changed, but if you also changed those files, the RPM upgrade operation is not going to replace the file. Instead, it will create a .rpmnew and you must do the merge manually.

Thanks. I have 1.12.1 version running. Is there a patch which I can apply to 1.12.1 for this fix ? Or upgrade to 1.12.5 is the only way to get the fix.

If it is to be upgraded, does the following url provide steps to upgrade?
http://www.opennms.org/documentation/installguide.html#upgrading

Fixed on revision 3f75b490051484300d32cf359c19763ae23c4006 for 1.12.

I've found the problem on the code, and I'm going to commit a fix for it soon.

I've renamed the issue because the real problem here was the "resource label".

The original question related with this issue was not a bug, was a configuration problem (i.e., you must use Sftp3gppXmlCollectionHandler).

Let's analyze your 3GPP Data:

According with the 3gpp-pmgroups.properties, the format expected for "dns|dns" is:

Your resources look like this:

So, the format is different, and that's why it is not possible to parse the information.

In your specific 3GPP Format, the PM Group information should be:

If you have the PM Group information for your 3GPP File format, I can make a tool to generate 3gpp-pmgroups.properties and modify the code to use an external file if provided.

BTW, here is how the DNS resources looks on the sample files that I've used to generate the 3GPP Collector:

Of course, not only the 3gpp-pmgroups.properties must be updated. Also the resourceType definitions must be updated as well, because they relies on the custom fields generated based on the PM Groups.

When the PM Groups information doesn't exist or it is not on the correct format, the "label" field is going to be equal to the "instance" field, and the "instance" field will always be equal to measObjLdn. The "label" field is what you're going to see on the WebUI.

So, OpenNMS provides a reasonable defaults when the PM Group information cannot be parsed (which depends on your 3GPP Implementation).

Now, that explains the cases on which you "see" some labels on the WebUI (based on the screenshot you sent). But, there are other cases on which the "label" is blank, I'm going to create a JUnit test for that to see if I can figure it out what is confusing the parser.