Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ejb-dev] Please give feedback on this EJB test challenge for Jakarta EE 8...
Added Platform ml...

On Thu, Jun 1, 2023 at 3:09 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
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?

I'm not sure if others are using the JCP copy of the EE 8 specs (https://jcp.org/aboutJava/communityprocess/final/jsr366/index.html) but I haven't.  I looked back and found a previous EE 8 challenge https://github.com/jakartaee/platform-tck/issues/132 which referenced the https://github.com/jakartaee/jakartaee-platform/blob/v8/specification/src/main/asciidoc/platform/ApplicationProgrammingInterface.adoc so the EE 8 SPEC source code is available.  A related EE 8 Spec source link is https://github.com/jakartaee/jakartaee-platform/blob/v8/specification/src/main/asciidoc/platform/ApplicationAssemblyDeployment.adoc?plain=1#L101 which is the first reference to 'ear' in the application assembly doc.  

Also regarding this TCK challenge, we do not have to release a new 8.0.something Platform TCK as we only support the last two EE (major I think) releases.  But if someone wants to release a new EE 8 TCK they could (if the challenge is accepted and they have time to get the TCK CI jobs for EE 8 to work).  Regardless, if the TCK challenge is accepted, EE 8 certification requests could refer to the accepted challenge to explain why their related test failure can be ignored.

 



On Jun 1, 2023, at 11:19 AM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:



On Thu, Jun 1, 2023 at 12:47 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:

Hi,

Should the https://github.com/jakartaee/platform-tck/issues/1176 challenge be accepted? 

The reporter is using the EAR classloader to load EJB jars if I am following the description correctly.  They are running into problems when trying to invoke the EJB from a war due to the EJB jar + WAR both containing the (SecTest) application interface for the remote EJB. 

The test source is https://github.com/jakartaee/platform-tck/tree/8.0.2/src/com/sun/ts/tests/servlet/ee/spec/security/runAs

Some Platform SPEC links that may help the discussion are below.  

Note that [1] mentions that the context class loaders may be different for each module in an application.  Also note that [2] mentions that jars in the ear/lib folder (or specified library-directory) must be shared by all components.  [2] doesn't say anything about EJB/WAR modules being shared but do remember the use of "may" in [1].

Are there any links in the Core EJB spec that should also be referred to when considering the TCK challenge?

Scott


"
Libraries that dynamically load classes must consider the class loading environment of a Jakarta EE application. Libraries will often be loaded by a class loader that is a parent class loader of the class loader that is used to load application classes and thus will not have direct visibility to classes of the application modules. A library that only needs to dynamically load classes provided by the library itself can safely use the Class method forName . However, libraries that need to dynamically load classes that have been provided as a part of the application need to use the context class loader to load the classes. Note that the context class loader may be different in each module of an application.
" 


"
All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bundled with the application or installed separately, using any of the techniques described herein.
"
 


Thanks,
Scott

_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev

_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/ejb-dev

Back to the top