lrmi | LRMI in RDF | Data Manipulation library

We're using GigaSpaces version 8.0.0 (yes it's old) along with Spring 3 (yes it's also old). There are two modules A and B. A is the "main" module that reads and writes to the space and exposes some remote services. A and B run separately. B creates an instance of an entity that has a field that is a class object. This class only exists in B; A does not know about it. It then makes a remote call to A that ends up writing the instance to the space.

Later, A loads up this entity and creates an instance of the remote class by doing entity.getClassObject().newInstance(). This works even though this class doesn't exist in the A's runtime classloader, because the classloader for this class is the LRMI (light remote-method invocation) classloader that comes with GigaSpaces. I guess it knows how to instantiate it.

The problem arose when we added an aspect to A. We have existing code that autowires an instance of the remote class using A's application context and also initializes it using initializeBean. The autowiring and initialization worked fine until we added the aspect. Now, during initialization, it attempts to see if the advices in the aspect apply to the bean that is being initialized. As part of this process, it attempts to create an instance of the class using Class.forName and the bean's class' name. This results in a ClassNotFoundException because the class obviously does not exist in the runtime class loader. So AspectJ resolves the type as MissingResolvedTypeWithKnownSignature instead of failing immediately. But eventually there is a failure when AspectJ tries to find the superclass of the class because it doesn't have that information, and it throws the following exception: