It seems that there are missing dependencies among modules in soa layer. We tried a utility that scans through all modules of soa layer and tries to load all classes of the module plus all classes that are referred by those classes using the module classloader. The results are stored in attached report.
Created attachment 833162 [details] Report
Can you give us explicit example of these failures? Some of the ones being picked up are very suspicious, for example org/osgi/framework/InvalidSyntaxException, javax/ejb/EnterpriseBean etc.
Created attachment 833212 [details] Report
Created attachment 833215 [details] Report
[09:13am] kcbabo: jpechane: I think that is useful as a diagnostic tool, but it's not evidence on its own of a bug [09:13am] kcbabo: jpechane: for example, let's say I have module A which depends on module B and C [09:13am] kcbabo: module C might have a ton of stuff, but module A only uses a small part of C [09:14am] kcbabo: so if C references classes that are in D, E, F [09:14am] kcbabo: but the functionality used by A only includes C -> D [09:15am] kcbabo: then missing dependencies on E, F in C will never present a problem [09:15am] kcbabo: I hope I interpreted your approach correctly in terms of the class scan [09:15am] kcbabo: jpechane: putting this another way [09:16am] kcbabo: you have constructed a visibility graph [09:16am] kcbabo: by scanning the classes and figuring out what references what [09:17am] kcbabo: a missing dependency is only a problem when a dependency is missing from the runtime graph [09:17am] kcbabo: what classes are actually used in a module [09:17am] kcbabo: it's good info to have because it helps us catch possible missing dependencies [09:18am] kcbabo: but I wouldn't add a dependency based on that information alone [09:18am] kcbabo: I would create a test which exercises the supported functionality and then if that fails we know there's a problem [09:18am] kcbabo: jpechane: make sense? [09:19am] jpechane: kcbabo: ok [09:19am] kcbabo: jpechane: just looking at the top of that repot [09:19am] kcbabo: report [09:20am] kcbabo: first module I hit is POI [09:20am] kcbabo: which is gonna have a ton of stuff that it references [09:20am] kcbabo: all sorts of MS and OO document formats [09:20am] kcbabo: do we use them? I don't know. [09:20am] kcbabo: jpechane: well I can answer that SwitchYard doesn't use them for sure [09:21am] kcbabo: jpechane: whether the Drools team considers that to be a problem is another matter entirely [09:21am] kcbabo: jpechane: if there was a way to clean that report up a bit [09:22am] kcbabo: jpechane: eliminate the stack traces, maybe filter it out so it's just the unresolved type and the referencing module [09:22am] kcbabo: that might be an interesting report [09:22am] kcbabo: jpechane: I think there will be quite a few false positives in there [09:23am] kcbabo: but I bet there might be some real issues as well [09:23am] kcbabo: basically things we would find with functional testing eventually [09:23am] kcbabo: but just haven't been detected yet [09:24am] kcbabo: jpechane: a lot of those seem to be related to poi [09:25am] kcbabo: or python ... [09:35am] jpechane: kcbabo: I wil try to clean the report up [09:36am] jpechane: kcbabo: Are you sure you do not need POI? How about Drools and XLS decision tables? [09:36am] errantepiphany1: jpechane, kcbabo: ummmmm…. yes, poi is needed [09:36am] errantepiphany1: for dtables [09:37am] kcbabo: errantepiphany1 jpechane : I said that SwitchYard doesn't use them [09:37am] kcbabo: we use Drools, Drools uses POI [09:37am] errantepiphany1: righto [09:37am] kcbabo: they package the modules [09:37am] kcbabo: if the module definition is incorrect/incomplete, they are in the best position to comment/fix
We're removing the BPMS modules for ER8.