NPE during import when import mapping and ruleset do not match #5217
Comments
|
Same problem last week but i did not report as issue. 😓 Problem seams the IllegalStateException in ProcessFieldedMetadata line 346. In my case this exception is more meaningful. "Got complex metadata entry with key "ContributorCorporation" which isn't declared as substructured key in the rule set." So we should log this exception, improve or reconsider error handling. Cause after this exception is catched a fallback mechanism handle missing field using metadata.createUndefinedMetadataTable and null is passed as parameter which then leads to the npe. |
|
Root cause is #3762. |
|
@matthias-ronge : A 2 years old issue - which is referring to the meta data editor and not to the import dialog - is the root cause for a new introduced bug caused by latest changes in this area? This did work before latest changes by you was merged or at least you get an information about this not declared meta data fields on import. |
|
Yes, the root cause is in that issue. The error just moved to a different place where it shows. The problem is that the ruleset module isn’t yet capable to detect if an undefined metadata entry is a group. I added a better explanation of the problem in the issue description a minute ago. |
|
Would it help to just check whether I understand this wouldn't solve the underlying problem but at least the NPE during import could be prevented in cases that might occur pretty often. |
|
Ok, I see now that there are many more parts in the code where subsequent exceptions would have to be handled, so fixing the core issue might be more feasible. |
|
This seems to create a lot more trouble than expected, so the "blocking" label is warranted, I think. |
|
The NPE is now handled in the code and shows an error message instead of an error page with stack trace, so the |
|
You still receive a Nullpointer-Exception when an In my case i got there when i search in the K10-Plus by title and then select a record. The problem is that the When doing that the "real" exception is shown In addition to that the Catalog Exception has to be catched when public void getSelectedRecord() {
try {
getRecordById(Helper.getRequestParameter(ID_PARAMETER_NAME));
} catch (CatalogException e) {
this.opacErrorMessage = e.getMessage();
PrimeFaces.current().ajax().update("opacErrorDialog");
PrimeFaces.current().executeScript("PF('opacErrorDialog').show();");
}
}This prevents the Exception and prints an error message. |
|
In my example the metadata entry from K10plus is returning a complex "person" key. There is no "person" defined in my ruleset, so the This is catched in the |
|
A stack trace showing is bad, but: It is still an operators’ mistake if a key—including a grouped key—is not defined in the ruleset. You should not edit any data that you don’t know it exists. Especially, metadata groups shouldn’t appear so randomly in your data that you cannot predict and define them in the ruleset. Production tries to handle this issue some way better then in version 2 and doesn’t crash anymore for unknown simple keys, but for historic reasons, it had to guess for a key if it is grouped or not before it knew the data, and so assuming “it is not” was the better trade-off. General explaination (taken from #3762, which is a different exception, but caused by the very same problem): The assumption behind this behaviour was that, if ever there is an entry in the metadata which is missing in the ruleset, this is likely to be a value; because metadata groups are unlikely to appear “by accident”, but maybe an entry does, if it was removed from the ruleset in belief that it had never been used, but it was used in one single process that the editor of the ruleset didn’t know about. Unlike 2.x, this shouldn’t crash the metadata editor anymore, which it did in thie past. |
I have a more general question because i just stumbled over that: If a) This key is defined in the ruleset, but not marked as allowed for monographs and only for periodicals for example no indication is given that this key is not in the list of allowed keys for that division (monograph). There is also no validation warning or error. The user can just save the process without any indication that there might be a key which is not explicitely allowed by the ruleset. If b) The key is not defined in the ruleset the user gets at least an indication, that this key is not defined in the ruleset at all. No validation warning or error here. I am just wondering: Is this intended behaviour? It is clear that there should be no crash of the application when data not defined in the ruleset is imported. But should this data not be considered as invalid by the application? |
|
I think the case is simply not implemented. I think the XSLT should distinguish by doctype in such cases and only map the value when it is desired. It would be inconvenient for the user to have to manually delete the value for each import. But that's just my opinion. If you want this functionality, you can open a ticket for it. Question: Does this have to do with the bug described in this ticket, i.e. throwing a null pointer exception? |
|
Thank you. It was not only about this specific behaviour, but the whole intended behaviour around undefined fields seemed underspecified/undecided to me, so i was looking for clarification. I will check wether to open an issue or maybe a discussion as well. |
|
@BartChris : I think a discussion is appropriate to work out the issue. Perhaps we need to consider two things 1 The behavior when importing processes with undefined elements 2 The validation during import in general |
|
@BartChris & @andre-hohmann I agree that we should discuss that question in a dedicated discussion instead of an issue! @matthias-ronge while I agree that it's the operators or administrators fault if a ruleset and accompanying XSLT mapping are not configured correctly, this is an error that's unfortunately all to easy to make. In my opinion, the system should be sturdier when it comes to such configuration problems and offer some kind of graceful degradation. Displaying an error dialog about problems with the configuration instead of the unfiltered stack trace would already be a significant step up and would allow the user to at least continue using the current page (instead of dealing with a seemingly broken system). For configuration debugging purposes the stack trace could still be written to the log files (with a note in the popup dialog informing the user that the log files might contain additional information), but displaying it to the user will not do any good. |
solth
added
import
solth
added
the
development fund 2024
|
Votes: 0 |
solth
removed
the
development fund 2024
I got a NullPointerException when trying to import some data using a mapping file that creates metadata groups and metadata entries within the group that are both unknown to the ruleset:
The text was updated successfully, but these errors were encountered: