| Re: [ejb-dev] Please give feedback on this EJB test challenge for Jakarta EE 8... |
Looked at the challenge and did some brief look through the platform spec. I’ll need to do more, but here’s some high level info: - It’s not immediately clear if this is a valid challenge or not - EARs are only defined in the Platform spec, so while we can talk here it would be Platform spec decision - Language around the classloading structure of an EAR is vague - In practice, you need to follow an exact classloader hierarchy to pass all the TCK tests in all EAR related sections (ejb, connector, war) - All EJB jars are put into one classloader, each war is put into its own classloader that must have the EJB classloader as a parent (either immediately or a few parents up). - The big question: this boils down to parent-first or child-first classloading in the war file. If your war file classloader uses child-first classloading, than any class duplicated in the parent and child will result in the child’s version winning and therefore duplication will cause issues. This is clearly what the implementation is doing in the challenge. If your war file classloader uses parent-first classloading, than any class duplicated in the parent and child will result in the parent's version winning and therefore the child version is ignored, there is no actual duplication. This is clearly what those who pass the test are doing. We need to find spec language that might imply if there are requirements that either detail the classloading behavior explicitly or clear requirements that indirectly make one of those approaches mandatory. Now… the really hard part. This is for Jakarta EE 8 and we do not actually have specs for that version, so it’s a little fuzzy what set we would use. I assume we’d have to use the JCP copy of the specs. Is this what we have been doing?
|