Description of problem: following is added to the JAXbContext during the KJAR deployment into the business-central: 1. *all* classes in the kjar 2. all classes in the kjar dependencies with the @Remoteable anno 3. all classes in the kjar dependencies with the @XmlRootElement anno Version-Release number of selected component (if applicable): 6.1 How reproducible: always Steps to Reproduce: 1. Deploy KJAR which includes class without @Remotable annotation 2. This class is added to the JAXBContext Actual results: All classes found in the KJAR are added to the JAXBContext Expected results: Following is added to the JAXBContext: 1. classes in the kjar with @Remoteable 2. classes in the kjar with @XmlRootElement 3. classes in the kjar dependencies with @Remoteable 4. classes in the kjar dependencies with @XmlRootElement Additional info:
Anton, This is actually done on purpose, we expect all classes added to the kjar to be closely tied to the processes themselves. This to avoid users would have to manually annotate all classes in the kjar (for example created by data modeler). For additional dependencies there's support for @Remotable and jaxb-annotated classes, as adding all possible classes coming from dependencies isn't feasible. Do you have an example when loading all classes in kjars is problematic and why? Because if a class inside the kjar is used in a process, it should probably be serializable through JAXB anyway.
Hi Kris, The original reason for this BZ is this: my customer included interface (purpose was custom annotation) in his deployment unit. JAXB can't instantiate the interface and hence, KJAR deployment fails. What is our recommendation for this use case? Cheers, Anton
Duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1231111 ?
*** This bug has been marked as a duplicate of bug 1199993 ***