#252 Added new serializer based on GSon library

[svarcheg]

First implementation of a GSon-based Serializer

[rhuss]

Thanks for submitting the PR ! Could you please check it, it seem that there are compilation errors in the CI.

[rhuss]

Yust pulled this branch on top of #255 , but still get a compilation error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:testCompile (default-testCompile) on project jolokia-service-serializer: Compilation failure
[ERROR] /Users/roland/Development/jolokia/jolokia-2.0/service/serializer/src/test/java/org/jolokia/service/serializer/GSonSerializerTest.java:[90,143] cannot find symbol
[ERROR] symbol:   method getUpdatedValue()
[ERROR] location: class org.jolokia.server.core.service.serializer.WriteRequestValues
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.

changed it to getNewValue() for now.

[rhuss]

The important point here is that pOuterObject is updated inline. It's not about getting an updated JSON structure but the object itself needs to be updated. That is what the JMX write operation is for, you update an JMX attribute. In that case not the attribute itself but at a deeper level (this is a feature of Jolokia). Afaiu do you only upate a JSON representation of the object here which you then is returned.

It probably arguable whether this feature really belongs into a serializer. Maybe we should move this setInnerValue() completely out of this interface and make it an intrinsic feature of Jolokia. I remember that I tried that sometimes ago, but failed.

The more I think about it, this method really doesn't belong here as it does have to do with serialization only marginally. I'll try to move this out of the serializer, though not sure wheter I suceed.

Any idea welcome here ;-)

[rhuss]

I tried to get rid of the setInnerValue() method in the interface. Unortunately its quite involved since the (recursive) internal JSON serialization is highly interwoven with the data extraction part needed to extract the object on which to set the value.

For the moment I can see two solutions:

• Allow for an 'UnsupportedOperation' exception when a serializer doesn't support setting an inner value with a write operation. I don't know how often this functionality is used in the wild, but I have the feeling its a too small feature to justify the amount of work needed to restructure this whole module. An implementation can still decide whether it wants to support this, but need todo its own reflection to obtain an inner Java object.
• Move the extractor part from the Jolokia serializer in a core package, so that the reflection code used for setting inner values can be used directly and one could remove the setInnerValue() from the interface. The drawback here is, that moving this part into core, 90% of the serialization code would move, too, defeating the modularisation and replaceability of the serializer component.

Any thought, what would be the better approach ?

[svarcheg]

Hello,

Sorry for the delay.

I feel like in theory the second option is better as this does not have to do a lot with serializer purpose. It may result in an important code impact and dependencies (aka serialization) will be a problem as you stated above. There's no quick win here from code perspective.

This is why in practice I would vote for the first option, mainly for its simplicity.

Kind regards,

Vladimir