Closed jeff-aion closed 5 years ago
Our current thinking is that we will add the test at the top-level, operating on the avm.jar
as produced for the dist
directory, as that is currently the unit we are expecting to be embedded. This decision may change as we develop a more concrete sense of the embedding use-cases and what is actually required for that case.
As part of this test, we can also add an attempt to build and deploy one of our dist
examples, to make sure that this is working as we expect.
External attempts to embed AVM in its own
ClassLoader
are failing due to the assumption the implementation has that the core AVM classes are loaded by the systemClassLoader
. This typically manifests as something along the lines ofjava.lang.NoClassDefFoundError: org/aion/avm/internal/IDeserializer
There are a few places where this assumption is being made:
Verifier
explicitly createsVerifierClassLoader
AvmSharedClassLoader
implicitly uses the system ClassLoader as a parentThe main question is how we want to test this. It is still far more convenient for the common-case to load the AVM from the system so should we handle this case as an explicitly different kind of unit test which builds its own
ClassLoader
or go even further to running this as a test on the final distribution shape?