Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Spec process for certification against SPEC TCK running in an EE env


On 10/20/21 9:39 AM, Scott Kurz wrote:

Thanks Scott S.,

But to my knowledge there's no concept of targeting one platform vs. another when certifying an impl against a component/spec like Batch or CDI, e.g. in the TCK process
https://jakarta.ee/committees/specification/tckprocess/

The linked TCK  process and https://jakarta.ee/compatibility/get_listed is pretty clear that a Spec (profile) may be targeted which CDI does document supporting via their command line options:

Run CDI TCK in Jakarta EE mode for Full Platform: 
   mvn test -Dincontainer

Run CDI TCK in Jakarta EE mode for Web Profile: 
   mvn test -Dincontainer=webprofile

Only run CDI TCK in Java SE mode:
   mvn test -Dincontainer=se



One way I can see rationalizing this situation would be to say that this Batch spec statement:

    When running on a Jakarta EE platform, the batch runtime uses global transactions.

is NOT a Batch spec-level statement but ONLY a platform-level statement, and therefore does NOT need to be validated via the component/spec-certification but ONLY by the platform TCK.

What makes sense for the Batch TCK to do here?  Keep the JTA transaction handling logic and document that is for Jakarta EE mode testing?  Or remove it and move it to the Platform TCK for use with running the Batch TCK in Jakarta EE mode to meet the Platform requirements?




Now, that all said.. the batch project should be allowed to say that either the SE-only or full EE suite can be used to certify against the component, (if an impl would rather run the EE suite).   It can also make it easy for the TCK / certification results to show evidence that an impl was run against the EE suite.
+1

But the Batch project can't create on its own two categories of compliance:  compliance within EE, compliance outside of EE.

+1 for the Jakarta Batch project *not* adding a new category based on a subset of EE (I'm mean the same as you stated but prefer to refer to it as a subsetting issue).


At least this interpretation is making sense to me but it's really up to the platform team to agree this is indeed the spec process in a case like this.

I'm not a platform committer but do still want to share my feedback here.  Hope it helps!

Scott



------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for "Scott Stark" ---10/19/2021 10:30:42 AM--- The way it is done in CDI is that there are sets of tests "Scott Stark" ---10/19/2021 10:30:42 AM--- The way it is done in CDI is that there are sets of tests that target the different environments, a

From: "Scott Stark" <starksm64@xxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 10/19/2021 10:30 AM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Spec process for certification against SPEC TCK running in an EE env
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>



The way it is done in CDI is that there are sets of tests that target the different environments, and the TCK docs talk about how to run each based on what environment you are targeting. For web and full testing you need to run with a flag to indicate that. 

If some EE container wants to certify against Batch in SE mode because they are not certifying some profile, they can, and they would follow the instructions for that. It is not up to the Batch TCK to try to detect what environment it is running in. I don't see why a implementation that makes uses of a few EE APIs but is not interested in that level of certification has to pass the EE mode of the Batch TCK. I suppose that is really up to the Batch project however.

On Oct 19, 2021 at 9:16:20 AM, Scott Kurz <skurz@xxxxxxxxxx> wrote:
    Let me post a question I raised a bit earlier:  https://www.eclipse.org/lists/jakartaee-platform-dev/msg02756.html).

    In short, while it's easy for a standalone spec TCK to separate tests into EE, non-EE "suites" (subsets) using JUnit or whatever technology, it's not clear to me what the certification process workflow should be.

    (We touched on this in our Oct. 13 TCK call led by Scott Marlow:
    https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit#heading=h.s6ehbjf0q1uj
    under the section:  "    Does the Platform own passing the Batch TCK against EE 10 or does Batch SPEC own that?")
    ---

    E.g. the Batch spec states:
        When running on a Jakarta EE platform, the batch runtime uses global transactions.  In a Java SE or other environment, the batch runtime may use global transactions if available, otherwise the transactional behavior is undefined.  
    So imagine a Batch test which uses java:comp JNDI location and a global JTA transaction within the test application logic.  

    It is clear that an implementation trying to certify and running in an SE environment should simply not run this test, which should therefore be in the EE only suite.

    For an implementation trying to certify against the EE platform TCK the process also seems obvious enough, even with a standalone Batch spec TCK.    The platform TCK will have some set of instructions referencing or pointing to the individual component/spec TCKs.  There will be instructions for Batch, e.g. "go run the EE suite of the Batch standalone TCK", along with instructions for other individual standalone TCKs and whatever aggregate TCK might also exist at the platform level (assuming that part exists).

    But what about an implementation that is running in an EE environment BUT not necessarily seeking platform certification ?    (BTW, this has come up with Spring Batch in the past.  While last I heard Spring Batch is not looking to certify against Batch 2.1, it still raises an interesting question).

    It seems wrong to say that this impl could be considered Batch compliant, without passing the test I described.      

    Does that suggest the TCK should have a "am I running in EE mode?" test, and we run the full suite, but the EE tests are no-ops if the "EE mode?" test fails?

    Or should the user select a "suite", EE or non-EE, and the certification should be:  "certified in SE" and/or "certified in EE" ?    

    Another interpretation is that "running on a Jakarta EE platform" is meaningful only with respect to seeking EE platform certifcation, which implies this implementation should run against the non-EE suite.    (In this case, better suite names would be "batch platform" vs. "batch standalone" rather than "EE" vs "SE".)
    ---

    To be honest, I'm not sure it's a crisis if we don't clarify this in EE 10.  However as we're looking to more formally separate out the Batch TCK from the Platform TCK it is a grey area of the process that I think we should understand better.

    Thanks,
    ------------------------------------------------------
    Scott Kurz
    WebSphere / Open Liberty Batch and Developer Experience
    skurz@xxxxxxxxxx
    --------------------------------------------------------

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




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

Back to the top