Limit Deployment Serialization Classes - mrietveld/jbpm GitHub Wiki

Home ▸ 1-Pager: Limit Deployment Serialization
2015-12-03

The main problem is described here: BZ-1125077.

In short, all classes from both the (kjar) deployment and it's dependencies are currently added to the list of classes used for serialization.

However, when those classes are interfaces, or otherwise not suited for serialization, this causes a problem.

The solution is of course to limit the classes added to the deployment serialization mechanism.

Specifically, when the KModuleDeploymentService class is processing a deployment, classes are added in 3 different places:

1. Classes in the kjar being deployed
2. Classes from the kjar depdencies
3. Classes listed (as a String) in the deployment descriptor's 'classes' field. These classes must of course also be available on the kjar/project's classpath.

The classes are limited based on whether or not they're annotated with 1 of 3 (type) annotations:

• @XmlRootElement
• @XmlType
• @Remotable

If classes

1. from one of 3 sources above
2. are annotated with any of the annotations
3. and are normal classes (and not interfaces, local, member or anonymous classes)

then these classes are added: this our solution.

The JAXBContext adds classes using the (class owner) classpath and we can not provide a classloader to the JAXBContext to use for resolving the classes added.

Furthermore, simply adding correctly (JAXB) annotated classes in a kjar/deployment to the JAXBContext is not sufficient, since the JAXBContext code will transitively resolve and add all classes referenced in the JAXB annotation classes if appropriate.

The question then becomes: How can we be sure that transitively resolved classes added to the JAXBContext are correctly resolved?

If we assume that

1. the JAXBContext is simply using the class owner classloader, which seems to be the case
2. a kjar/deployment class returns the correct ProjectClassLoader instance when getClassLoader()

is called, then we should be fine.

(2) seems to be true, based on modifications to the drools-core ClassBuidlerTest.

(Note: with XStream, this is not a problem as we can provide XStream with the project/kjar Classloader and not worry about it anymore.)

For example:

For example, let's say we have a correcly annotated @XmlRootElement class (Parent.class) that refers to a another class (Child.class) via a correctly annotated @XmlElement field, and the unannotated Child.class contains field referencing another unannotated class (GrandChaild.class). For the heck of it, let's have GrandChild also have a field that references a GreatGrandChild class.

The object tree looks like this:

@XmlRootElement
Parent
  @XmlElement
  Child child 

Child
  GrandChild grandChild 

GrandChild
  GreatGrandChild greatGrandChild

GreatGrandChild
  String name
  Integer numPresents
            

If we then execute the following code:

  Class [] boundClasses = {
          Parent.class
  };
  JAXBContext ctx = JAXBContext.newInstance(boundClasses);

Then all 4 of the above classes are added to the JAXBContext (at least, in the RI implementation), which can be shown by using the JAXBContext.toString() method.

(For more info about the JAXBContext.toString() method, see the JAXB Users Guide on Kenai while Kenai is still there.. :/ ).

JVM Class resolution

The "*Child" classes are found and resolved using what the JLS specification calls class resolution. Class resolution is the process of translating the binary class reference in the class bytecode to an actual link to the other class in the JVM.

Regarding resolution, the JLS 3 (SE 6), says the following:

For example, an implementation may choose to resolve each symbolic reference in a class or interface individually, only when it is used (lazy or late resolution), or to resolve them all at once while the class is being verified (static resolution). This means that the resolution process may continue, in some implementations, after a class or interface has been initialized.

• Fix the BZ

• goals

• nice to have

GET IT DONE

January, 2016

• QA
  • share documentation of features
  • show tests
• Documentation
• Product
  • inform about new modules