universAAL / remote

Remote Interoperability Managers that interconnect universAAL across networks
2 stars 1 forks source link

REST API mixing up Turtle and JSON-LD serializers #500

Closed Alfiva closed 4 years ago

Alfiva commented 4 years ago

After the latest updates, it seems the inclusion of JSON-LD serializater/parser is incomplete. I get JSON-LD parsing exceptions in various situations, like publishing an event or restoring the previous state from the database when the REST API re-starts. For instance in this last case:

com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 10
        at com.google.gson.JsonParser.parse(JsonParser.java:65)
        at com.google.gson.JsonParser.parse(JsonParser.java:45)
        at org.universAAL.middleware.serialization.json.grammar.JSONLDDocument.<init>(JSONLDDocument.java:77)
        at org.universAAL.middleware.serialization.json.JSONLDSerialization.deserialize(JSONLDSerialization.java:41)
        at org.universAAL.middleware.serialization.json.JSONLDSerialization.deserialize(JSONLDSerialization.java:59)
        at org.universAAL.ri.rest.manager.server.persistence.PersistenceDerby.restore(PersistenceDerby.java:424)
        at org.universAAL.ri.rest.manager.Activator.start(Activator.java:102)

I have checked the code and it's like the migration to including JSON-LD serializer is incomplete. This stems from the fact that in some cases it uses .getTurtleParser(), getJsonParser() and getParser() not consistently. For instance I think getParser() should no longer be used used because it returns an arbitrary serializer without discriminating type. In the case of the exceptions caused, it returns a JSON-LD serializer (I guess it's the first in the list) while being used in a Turtle context. Also, there is a "serializerJSONLDListener" in Activator that is not used anywhere... I don't know if that means there is some missing code...

buhideduardo commented 4 years ago

Thanks for your advice. I created a branch fixing the mentioned issues. I think gonna be a good idea detect which serializer is using (to avoid some hardcode), keep it and use it en getParser(). Im working on it

buhideduardo commented 4 years ago

@Alfiva can you test the code in issue_500 branch?

Alfiva commented 4 years ago

The core issue is solved but there are new issues: For instance, when posting a new Publisher, the response is server error 500. This is because Activator.hasRegisteredParsers() in Publishers:118 returns false. That method seems "upside down", returning serializerListener.parsers.isEmpty(). Also, remember to remove the System.out.println()s before the final merge.

buhideduardo commented 4 years ago

I found the error and fixed it. Additionally i added some debug lines to easy debuging. Please, test it.

Alfiva commented 4 years ago

OK now it seems it works OK. However, while in this topic... Does this all mean taht every module that imports the serializer service has to be checked now for whehter it is the JSON serializer or Turtle serializer? Because this breaks the CHe, and I don't know how many modules more.

amedranogil commented 4 years ago

Serializer can be selected, if not, Turtle serializer is selected by default; we put thought in retrocompatibility. However, test it any way there may be issues.

Alfiva commented 4 years ago

Because of how serializer is discovered in CHE, JSONLD serializer could arbitrarily be chosen. I had to go in and check serializer type, it is updated now.