Problem with Gson Serialization to json

[reua...@gmail.com]

Hello Community,
I need to provide a number of test objects for a unit test. (MOrder, MOrderLine, ...)
I thought the easiest would be to just serialize the objects from my test case to Json, then deserialize these into objects when setting up the tests.
Unfortunately I can't get it to work. Any attempt to serialization runs into a java.lang.reflect.InaccessibleObjectException.
Has anybody successfully integrated a library that uses reflection within iDempiere? 
Is there an easy way to do it?
I already tired java serialization, but that is nor really usable in that context. I am afraid the test will break beyond repair if the serialized classes are modified later on.
Also I need the test data to be editable which is not possible with the java byte format.

If json serialization should not be an option what else could I do to generate POs that look and behave like the real thing? Note: I can not read my test data from the database because then the test would not be reproducible within the constraints of the test environment.

Stack Trace: 

java.lang.reflect.InaccessibleObjectException: Unable to make private java.lang.module.Configuration() accessible: module java.base does not "opens java.lang.module" to unnamed module @4702aecf

at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)

at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)

at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:189)

at java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:182)

at com.google.gson.internal.ConstructorConstructor.newDefaultConstructor(ConstructorConstructor.java:101)

at com.google.gson.internal.ConstructorConstructor.get(ConstructorConstructor.java:83)

at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:99)

at com.google.gson.Gson.getAdapter(Gson.java:423)

at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:115)

at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:164)

at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:100)

[Heng Sin Low]

1. gson should work. If I'm not mistaken, the idempiere-rest project at https://github.com/bxservice/idempiere-rest is using gson to perform serialization and de-serialization of PO, you can take a look at that.

2. Also, it is possible to just make use of the DB. In some unit test cases, we just create what's needed on the fly and either roll back or delete it from the db at the end of the test.

3. The other option is to load data from csv using the built-in csv loader or xml using the 2pack handler (PO also has an old xml serializer/de-serializer but I'm not sure whether that's working).

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/0a5d4d53-7260-47ba-9d3c-b203965f7999n%40googlegroups.com.

[reua...@gmail.com]

Thanks Hengsin,

That is exactly what I was looking for! I have looked swiftly at the rest API and found that it already has a PO serializer/deserializer.
I will give it a try and hopefully be able to use for the purpose.

I have to admit I don't think that proposals 2. and 3. are really practicable. To me test isn't a unit test anymore when it requires an external resource. (Also csv import involves DB writing and reading afaik)
This is a) because providing a defined state of the db resource for the test setup involves a time consuming db restore. I hope we are going to increase the test coverage of the app considerably and then it would take way too long for the test suite to complete when many tests relied on the database to be in a certain state. 
Also b) the tests can not run reliably since the db connection could just fail.  Also the lengthy test setup could fail or just time out. 

And c) it is much more work for the developer when the DB is required for a test. We should make writing tests as easy as possible. Otherwise people will simply not provide meaningful tests with their contributions.

Is there any chance to pull the idempiere-rest API or at least the json package into core?  That would surely be very helpful with the generation of unit test data for a lot of test situations.
One could of course install the plugin. But then any test that relies on the api for the deserialization of test data will not run on a system that does not use it.

WDYT?

Andreas

[Heng Sin Low]

you can check with carlos & co on that, I'm not involve with the idempiere-rest project anymore.

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/7805f371-a8f2-4444-a7a0-39d9f7e273b6n%40googlegroups.com.

[Carlos Antonio Ruiz Gomez]

Andreas, if you can port the gson serializer into core that sounds good.

That can open the door for a new set of importers/exporters and many other tools.

I'm not sure moving the whole idempiere-rest to core is a good idea (maybe in future), but for sure we can start trying to integrate the serializer part.

Regards,

Carlos Ruiz

El 5/7/21 a las 12:37, Heng Sin Low escribió:

[reua...@gmail.com]

Thanks Carlos, 
This is very encouraging. I have made myself familiar with the json package and I found the transfer very straight forward. 

The package has only very little dependencies with the rest of the plugin and it was quite easy to replace these.

I think you are right about leaving the rest (of the) api outside of core. After all it introduces another vulnerability into the system and it is better not to have it in the first place if one does not need it.

I made some changes to make the package more suitable for broader usage outside the rest api. 
I have in mind to split the transfer into two steps: the first pull request would merge my changes into the rest api plugin. 

The second step will implement the transfer within the core and the plugin.
If I did it in one step only it would be much more difficult to review the changes within the package. 

WDYT?

[Carlos Antonio Ruiz Gomez]

Yes, that sounds fine.

El 7/7/21 a las 18:53, reua...@gmail.com escribió: