Jakarta EE TCK, 27 Jan 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TCK call #6

Description

January 27, 2022 Jakarta EE Platform TCK call #6. Minutes can be viewed via https://drive.google.com/file/d/1ITRLSSPfkZuwJ82hAvEaIV-QdM7znsUq/view?usp=sharing

Note that previous TCK call #5 was not recorded

A

Awesome and let's see, I'm gonna paste the agenda to the chat room, okay, cool, that's done, um and um oh hi dmitry good to see you um and I.

B

Was just saying that this.

A

Is record this is recorded just so that you know you know. Everyone knows. I started the recording and it's going to go ahead and share my screen for the agenda and I also pasted it into the chat room. The agenda link just so everyone you know, has it see sure.

A

Let me try that soon again,.

A

A

A

So um um I'll I'll um just do a quick introduction and- um um and just mention you know, you know that I I yeah I added some notes from the um that were based on what we had discussed in the platform call this week on tuesday, where we talked about split out tcks and I included the link to the platform called agenda so that you know maybe, after if anyone wants to look at them when they won't look at them. Now, that's you know, that's fine, um but that's the um that's where we came up.

A

The question came up um of: isn't it a problem that the platform tck and the new um um split out tcks, you know the new standalone, tc spec tcks may have the same test or duplicate and they may duplicate tests that are in both places and oh hold. On. Let's see, I need to let people in.

A

Okay, um this is.

C

Yeah, this is not that this is actually not a question of. uh Is it possible that uh both bundles I mean split out and uh jakarta? Dcks platform does have the same tasks. uh uh This is actually what we it's definitely possible, but this is not what we want to have, because it introduce uh two sources of truth and uh increases their support efforts right.

A

Yes, but but it's not yeah, so I I added a point here and it's arguable debatable. um That's why we're here, um but um I did I did. I did add what I tried to um be a point of you know point for you know, constraints and costs introduced.

A

If you have, um um you know if, if, if the you know, the standalone spec tck contains test to validate platform um requirements and um and if the standalone spec test doesn't contain those which um is you know, two different, you know two different um situations and um that we could find ourselves in and I think that kind of covers you know both sides, but on the um on on on on, you know like if, if the standalone spec tck doesn't contain the platform um um validation tests, then the standalone test, the standalone spec, doesn't have dependencies on the other platform specs.

A

If, if the standalone tck does have platform level tests, then that stand-alone spec has a dependency on platform specs and it creates you know chicken and egg type dependencies where let you know um I'll just summarize quickly and just say um let let's in the example I I mentioned. Let's say that, like the batch tck um depends on ejb and the batch. The batch spec goes final, um but then the ej ejb spec and, let's just say there- was some changes in flight for that release.

A

The ejb spec then makes a change that is breaking that tck, the batch tck that contains that batch. You know that each batch cck contains ejb test and that breaks that tck the batch spec has to release again. It needs a new tck, probably a new spec release, and I call that the cost and there's probably other things that it's it's not just straightforward, that it has to be one way or the other the spec.

A

In my opinion, this, the spec team should decide that. But but that's what we're here to discuss- and I think I think that kind of gives a sense of both sides. So I will give the floor up um to who you know. Whoever wants to respond to that.

B

So scott, I I was going to say uh at least in the json um pnb cases, right that the dependency um is only that the container um you know the jsp and the server containers must be compatible right so that, uh if servlet or jsp were to change um after say json pnb had finalized right, json wouldn't need to change. The servlet container is just responsible for for assuring that it that its compatibility with uh you know, requirements are still met, so so it it it's.

B

I I think that your I think your conclusion is absolutely correct. Is that you know the dependency relationships can't be ignored. They must be considered by the the you know, the corresponding spec teams, um but it isn't it's not all. It isn't always the case that you know just because there there are. um You know uh requirements across different component specs uh that every change is going to. You know have a abdominal effect.

A

Definitely it it's a worse case. You know it won't always be the case that we're removing the spec, but in the scenario I I mentioned it's only if and only if in the you know, in the json p case, let's say: servlets some servlets spec api- that that the json ptck was validating um at the plot. A platform requirement that spec is you that spec api for servlet is used in the tck.

A

That's already, you know final and was part of the ballot for jsonp only in a scenario where that api is removed, for whatever reason jsonp didn't. You know didn't know that that was going to happen, but that happens after so jsonp and that only in that case has to then repeat so.

B

That's right so in in this case, I think that the dependency is in the opposite direction. Right if, um if server were to go final and jsonp, you know and it as part of its uh actually I'm not even sure. If servant spec has this requirement or if it's just a platform, but in any case let's say the servlet spec, the server container had somehow indicated you know somehow become final and there was a change in jsonp right. You know that that could inflict a uh retest on terribly.

B

But if it's the platform spec that says the certain implementation in the platform must, you know, uh must be compatible with with jsonp right yeah. So then it's up to the platform implementations to make sure that they have. uh You know they have um achieve those requirements that may may or may not have a corresponding ripple effect into survey.

A

B

The spec teams have to do the analysis and yeah um and make sure that they have covered the dependency relationships correctly.

A

Yeah so jsonp, because it because of of what it would be because of it of the the platform um validations that it does, and you know from a dependency point of view, yeah yeah, 100 correct. It's not likely to go for this scenario that happened with jsonp, but for you know for batch.

A

um um You know we're batch depends on if yeah, sorry, where batch validates ejb enterprise beans. You know that. Would you know that could happen, because it's in it's an inverse dependency relationship um batch would go final before ejb does because ejb always goes. It goes final at the end, because it depends on the platform tck.

B

So so, in the case for jsonp right, I think the main sort of technical issue we have to resolve here is how uh how are we going to stage um these js the json ptck, so that it can run in the two required containers right I mean that that's for me, that's the fundamental technical problem that needs to get resolved today.

D

Right so the from for me, the question is so cdi has done this for a while. It has a set of tests and it relies on our killian to spin up the containers that it needs to test. So when you're testing the platform, you know it's injecting the it's already put in the cdi implementation and library into whatever platform is being tested and then the users are killing to deploy those tests. So the question for me for ed10 json bnp is, I mean, do we have do we have a test framework that can do that?

D

If not, then can't we just strip out the platform existing platform test to be a minimum test of each of the required containers.

C

Yeah, uh but this is what you sensed got. It requires a queen right and um uh we actually didn't use a query in our standalone tests and uh that's breakdown.

D

Right, that's what I expected so for ee10! That's what I'm saying can't we just have the the the new standalone tcks and take the existing platform tck for json b, for example, and just remove everything but basic validation that that json b implementation works.

B

Well, this anything this is the. I think this is the total validation right they just they. They take the test in ee9 right. They they take the jsonp standalone, they spin up uh jsp and they run they verify that the compatibility tests all pass right and they um actually, I what I think they do. Is they um they they actually interleave all the tests running one and json p1 and the servlet.

B

Then they run the next one, jsonp and json and then insert, but in this case I think it'll be easier uh for the test development effort to just you know, spin observe it run all the tests. Hopefully they pass then spin up jsp run all the tests. If, hopefully they pass right. um So so, if we can, um you know it's.

B

I can't believe that java test can't um be, um you know, cannot do that, um but you know I guess I would have to defer that uh the answer to that question to um you know the people that actually have expertise in that. For me, that'd be guru or always.

C

Yeah but jsonp tests are not java test based right. So that's exactly the problem that it's, my understanding of a problem is that currently there is no technical ability in a jaccard tck project to spin and run not java test based tests in different containers.

C

B

Possible, how are we going to run these tests with with a platform.

A

We so we'll set up the standalone tcka test to run and right.

B

In in java, in the current yeah, using the current tool.

A

So so, there's um um um you know right yeah, right now, users set up um the cdi and and other stand-alone tcks they'll now run um additional standalone tcks with their ee implementation.

A

um This you know for the standalone tcks that do work. You know so that do contain. You know the plot. You know the platform validation. So in the case of when it comes to running the platform, tck you'll only run you know. What's in the platform tck the platform tck itself is not at least not for ee10. It's not going to wrap all the other tcks that in the past, we've always run separately.

A

The difference is now there's new standalone tcks that also have to be set up and run. And again this was something we wanted to do to do that integration um as part of the refactoring but yeah. I don't think we would be completing that, um but yeah, maybe we would have completed it by now. I don't know, but you know we basically stopped in mid, mid, fall, pushing on that and it.

E

D

A

So but but we didn't yeah.

D

We didn't only see them sorry, they only see three possibilities for ee10. uh The simplest frankly is just to keep the duplicate test and you have to run both the next would be. Is there any way that you can get the j test harness to bridge to junit test? You know a an external library of j unit test.

D

The third is that you have to update the the jsonp tck to use our killing to to spin it up. I mean but longer term. The ideal thing would be that the tcp harness has an ability to run external or test ng tests in the can in the target containers. But you know that's going to be a lot of investigation. I don't think there's any possible way. We can do that for e10.

E

Maybe one more option to consider: I don't know how much work that would be, but given that those jsons tests are just simple jumi tests, I believe there exists uh some uh test runner for juni.

E

So an option could be to create new tests in a current tck, uh which would be implemented as junit runner run list of tests and somehow report results.

B

Traditionally, what we, so there are some tcks that are just run directly against glass, fish, the and then there are some that use a porting kit that that the porting kit, basically is just a bunch of. um As I understand it, it's a preliminary set of um setup and configuration actions that are scripted to um to make get the platform into you know to to the necessary state. Then the tck itself is run.

E

Yeah that would remain the difficult part, would probably be how to package var or each a b jar or a client for a client and deliver it on the server. Then the rest is quite easy, I would say, but I actually I I.

B

E

Know because I have no real experience, writing tests in current harness so.

B

Just an idea thrown away yeah, so guru or owen I mean: can you comment on? Is that possible? Is that something that we could contemplate here.

F

uh Basically, a porting kit we use for uh cdi uh dc case. uh Basically, we run uh the cdi uh dc case with glass fish using a port trinket, uh but the uh idea, uh a scenario in platform tck with json, b and jsonp, which we discussed a couple of times in platform tck meeting- is that vehicles are not supported uh the uh the ejv vehicle and app client vehicle, those those are not supported uh for a standalone dc case. That's the major issue we will face.

F

Even if you have a coating kit, putting kit will run as if it's running on a container, a servlet or ejp container, but vehicles concept will be missing from that.

B

So, egypt, I don't remember seeing egb or app client test results in the current case on you know the ee9 json pnp results, um so is that a requirement.

F

For jsonp and json uh b, uh there are vehicles defined uh scott. If you can share the vehicle.properties for jakarta.

A

It's um yeah yeah I'll I'll. Do that in a second. Let me just highlight the um from the spec text: yes, it it's there and then from the um I'll open up the.

A

Properties file- let's see okay.

B

Let me try that again copy.

B

So where are those run.

A

Let's see so um it's all on the agenda, but um it would you know um this. This is where I copied it from.

B

I understand so I I agree that you copied that, but where are those test results? Because I didn't see them? You.

A

Didn't see them? Okay, um I let me just look and let me look in my uh let's see.

B

Maybe you don't need to answer it. Okay, can you we should find out where those test results are because I didn't, I saw them either. I.

A

B

In the at least in the test, results that I looked at, but that.

C

I it should be fine because, uh currently uh for jakarta, 9.1 uh jason b and jason jsonp tests were part of cts. Basically right, I understand.

B

And I looked in pc, I I'm just I'm just kind of surprised because I didn't see them in the test results and I did look at the cps.

A

I thought I saw.

B

At least I thought.

A

I'll share with you, after the call what I've you know, what I'll look I'll look again and um I'll give you a link of what I looked at, and but we can do that after this call. Probably if that's so.

B

If you have so it's so your ears, it sounds like there's a fundamental problem that we cannot stage those containers um uh in the current test. Harness is that is that correct.

A

It's so we're talking about running so we're talking about running the standalone tck test from the platform tck, and it's not a problem that I don't. I don't. I mean it'd be nice to do that, but I don't see the requirement for the platform tck having to run um tests from the standalone tck.

A

I I guess you get you're trying to eliminate the duplication and that's great, um but um we just don't. You know like to integrate java test harness. um You know to use the the junit test classes.

A

um You know we're basically in yeah, that's something! That's we don't have that integrated and um I could see running like a standalone tck, but it would just be like the user doing it so that doesn't help we're really talking about. We want to run them against the vehicles that we have. You know set up with java tests and it's just you know we have this huge tck that what it's been 20 over. You know over 20.

A

You know 20, um you know years um in the making and um we could yeah if we bolted into j unit. It would just be you know it would be a real. You know really, I don't we talked about it, but it seemed like a problem. We don't, we didn't need to solve. If we try to solve that now, um I guess you run a junit test, but the genuine test doesn't know how to deploy.

A

So you have to you really, you know, there's not much. You use in reusing from the junit test, and you know it's just you. Both test test frameworks aren't compatible so they're just different.

E

Yeah but but the idea was that you run test written for current hardness and in that test you just invoke the junior test.

A

Yeah but the new.

E

Api and you one probably, would have to pass in something connecting results and to be able to report it back to the harness.

A

Maybe I mean maybe.

E

And then the test written for harness will be able to be executed within the container or through that vehicle or whatever right.

A

Basically you'd be, you know.

E

A

The the boarding kit would be invoked to do the deployment right, so they have to be. You know like right now ant and we have all these ant scripts that build the.

E

A

E

That would remain, it would still deploy the test, execute the test written for the harness and that that test being run would underneath, execute the unit and run everything with it. Then, within that particular container or context or whatever.

A

Yeah yeah, so I guess it's it's it it's basically, you know it it. It's updates to the ant scripting. You know it sounds like in you know, making changes in the ant scripting.

E

It would be about correct packaging of stuff.

A

That can be difficult and creating new, like rapper tck tests. That kind of probably do whatever is you know missing. Whatever you know is missing to.

D

You do you need, you do need the vehicle components, an agb, servlet, a servlet, filter, etc, etc. Actually, making use of the api under test, in other words, you're not really validating that it integrates in that container. So it's not just as simple as running existing geo unit tests, unless they're already referencing those components, which is what cdi does so cd adds. That's a test that have are using egb components to exercise cdi features.

C

uh Scott, but actually both jason b and jason p, but don't use any uh container features so right now.

D

That's the issue is so it's. It is truly a standalone se level correct so tcpa. So that's what I'm saying why we do need platform level tests that validate that a given json, b or p implementation can be used in the containers.

D

Exactly so, for me, the simplest approach for ev10 is we're just going to have to keep the duplicate tests. I mean long term. I ideally I don't want to have to be writing because.

B

D

C the tck cyclic dependencies it would. The ideal thing is that a given platform could write. I'm sorry specification team can write. This is our expectation for json bnp, integration and servlet etcetera, etcetera, but we don't have to deal with the arcelian integration. You know that there is a framework in the platform or whatever higher level container that wants to validate the behavior, could just pull those tests in.

D

So that's the issue for ee10k. Is there anything we can do even to attempt.

B

Yeah is it possible to copy that code back I mean I I I think I agree with you, scott. I I don't uh at this point in the project. I don't see how it doesn't appear that we can stage.

B

You know we can just create that vehicle or set up the vehicle and then throw those tests into it right. But you know that's, ideally that's what we'd have, but we don't have that so yeah. So.

A

um The tests will be they'll, be duplicated tests. Then you know.

B

Based on everything, you're saying I I don't see how we can avoid it, and I I guess I haven't heard anybody um speak up to a an alternative.

D

Well, well, yeah, no, because even even if we could run the j-unit tests as they exist, they're really not covering what we need to cover. So that's! That's the that's the other issue.

C

D

B

C

Covering everything, what's uh the previous javascript.

E

Actually, actually it's half and half it's half and half for jsonp and b. They would cover everything, but for cdi it would definitely not work because, as scott already said, cdi has a lot of other dependencies, but for jsonpnb I think that would be sufficient.

C

So why we can't, in this case, uh uh just require in the user guide for the platform that implementation runs standalone tests, which can be found at that url right and uh in the platform tests have just one or maybe several, depending on the spec simple tests, which does test that json binding is accessible in this container.

C

Like writing, simple serialization or whatever, just simply testing that it kind of callable.

B

So so that's what the tests do now right that the tests run explicitly run against each container, and I think in this discussion, what we have what's been stated. Is um it's not possible to pre-configure that so that those so that each test, that's in the json-b test, suite will be run. You know it for each of those four containers.

C

Now I I think I I'm I mean something different. uh What I meant is that we have a bundle of split out tests, standalone tests right and in- and this is this- is our standalone tests and they are not running as part of a platform test right. It's part of a platform test. We have just one past which tests that json b is accessible, is callable in the servlet container. That's it there's.

B

Right and then you've got to do that for the egb container in this the jsp container in the appliance yes, and so.

D

Dimitri you, you there's not like a requirement for uh manipulating egb method parameters or anything like that type of stuff. It's just strictly and you'll not non.

B

D

Okay, okay, well, then, then yeah, then maybe there is a simple way. So what which person j unit? Are you guys using? Is it four or five five? So maybe there is just a way to create a new, simple, servlet, egb and app client vehicle that really just launches the junit uh suite.

B

Well, that's that's what that's what that's, what the boarding kit would do, but uh just a minute ago, scott said that he didn't that we couldn't well.

D

Right now it doesn't well, I just don't think it has the the the integration hooks with chain in it. Right now is just the issue right.

B

I don't think that's it. I I don't think it's innovation, scott. When you said you can't uh that you can't run those uh vehicles. What are you? Could you just clarify that.

A

Sure, when so, when you, when you run a test, um um you know you already, you know in in in all you know, and you know you already have an app server already you're up and running. You basically are invoking an ant script that um calls into the user's um deploy um it's like a job in the portion. It's like a java class that does that.

A

That does a deployment, and it's told this is the particular deployment and um the deployments are all on on the disk um and the um important kit script that gets invoked can do whatever it likes to you know to handle the deployment and it can add, like vendor deployment descriptors at that point, everything that's needed um so so, basically, um I I I guess like for these jna tests, um um you know they would have to.

A

I guess we would have to like, like to add in the parameter that tells the user that they're setting up a j4j unit test, but they should go ahead and prepare that test to run and deploy it, and you know, do whatever modifications they need. um Yeah.

D

But one there might be, there must be some like stub from the test, harness that's emitting the results, or I mean how. How are the results collected in.

A

They they just go.

D

To the integra.

A

They you know they just you know, there's a um you know. The java test, harness um um just throws an exception. Basically, um so up a higher level gets an exception.

A

So um in the case of j unit yeah, we would just need to you know we would just have to go by the exit code and kind of you know say you know, throw some fake exception to say that you know the test field in terms of like you know, results, collect and that's just kind of like on the disk, and you know done an unknown location kind of thing and that's kind of not an issue.

C

But just hang on a second right, so we are always talking about g unit right, but the idea is that we use j unit only in standalone tests and in the platform tests. uh We just have one test, which is not gu, which is java test harness yes, and we actually have a bunch of these tests. Already we delete everything. We keep only one okay, yeah.

A

C

A

We're talking about two different things and um but yeah. I agree with dimitri.

D

That that is what I mean.

A

What dimitri is saying is what works that can work now and I think scott, you said it as well. um Just have some platform.

D

A

To validate the requirements we just kind of jumped off our, I thought we were jumping back to the kind of like bolton, the java test, you framework and the junit test framework and kind of. I thought we were kind of getting back to talking about integrating those and.

C

A

C

It's out of scope out scope of this meeting, so uh we need really to decide what to do with json, binding json processing test which are already jud5 right. And if we agree that the solution is that we keep standalone uh junior five based and in the platform. We just keep a minimum set of tests, ideally one or two, uh which does which, which just tests accessibility of the spec within the container right. We already have a full set, but we reduce them to minimum number of tests and.

E

If it's sufficient.

C

B

So in I can only guess what why the requirements are, or you know, state what they state, but I think the the um the goal of the requirement is to assure that um within each of these containers, whether or not they they um are implement, regardless of how they are implemented within the container, all the requirements of jsonp are met right, I'm just let's just use jsonp for now right, so in the tests right now, they will run each of the tck tests against each container right- and I guess so, and and so if each container has a completely independent implementation or if each container shares a common implementation, those tests will verify that the container meets the requirements right and so demetrius.

B

What you're suggesting will result in a you know that that sort of has an implication uh on how the how the platform is implemented right- and I guess I you know- I I would I would. Rather we didn't go down that road.

A

C

That's that that's kind of uh I'm making some assumptions, yes, uh but in general, uh if we require a json b implementation which used in the platform to pass all tck tests and json b specification itself doesn't have any dependencies requirements uh or doesn't use any other specifications used in the platform which is true, then it would be sufficient at this.

C

I think it would be sufficient uh that we uh declare in the user guide that platform implementation of json b should pass standalone tests, which is give based, and it passes the minimum number of platform tests which just test that json b is accessible because json b doesn't use any additional features or doesn't depend on other specifications.

C

It's a it's a losing requirements. I agree with that. But for me it sounds fine.

D

Yeah and I'm looking at the existing jsonp test and the the platform tck, they look pretty minimalistic anyway. So is there really concern about duplication.

E

Oh yes, there is uh at least for a jsonp. There is one test uh in the platform uh which is uh very specific to it and with jsonp we had some issues in the past passing it. It basically verifies that user provided implementation through in a web, app, for instance, through webbing of lib, can be loaded and used instead of the server provided one.

E

So this is one sort of test. It's called plugability test which definitely have to stay in the platform and that's what platforms should definitely run in each container and everything. So this is one really important test just to know that.

D

Right, so if you basically delete all these jsonp api tests, I assume most of the duplication. Is there because that's where the bulk of the test is are if we just delete those, I mean it seems like the remainder is certainly providing all the integration testing.

A

A

So in in the platform tc in the sorry in in the um in the pl for the validation of the platform requirements, we have one proposal which is have a minimum number of tests, which you know in some cases, that could be just the signature tests in each of the the vehicles, and I think that um you know um for the case where we already have platform tests that are doing more than that.

A

um If we went to the minimum, whether it's only a signature test or some small subset of the current platform tests, where lose, as ed said, we would be losing some testing. Is that a platform discussion that we should just have separately from this? um And you know in terms of driving which tests we remove or don't remove from the platform tck for json, p and b is? Is that like? Is that.

D

It has, it has to be a collaboration between you know the platform team and the spec team, because I mean I have to ask the spec team, which of these existing tc cast t uh platform. Tck tests for addiction p are really effectively just duplicates.

D

um You know, are already being handled by the stand-alone tck now.

A

Can that conversation where.

D

A

Is is a spec is, is a platform tck investigating too, or is it just the spec team, that's kind of stating what the platform requirements and uh the.

B

Platform team controls what they're doing yeah.

D

The platform team certainly has to say: well, you know, are you testing blar? You know if that's a requirement? Okay, you know. How are we testing? They have to understand that? Okay, so again, to the point of that's why I was trying to understand what are what are exactly requirements if we're just requiring that I can invoke the api.

D

That's one thing, but, as uh lucas said you know, you do want the ability to customize the behavior of the api with classes that are coming from the container level deployment. You know something that's been bundled with an egb jar, it's been bundled in a war, etc.

D

You know that those are relevant tests that we need to keep at the platform level.

A

um I mean I personally I'm in favor of keeping um tests in the platform only because from yeah I've seen many cases where it helps. You know, implementations find bugs that they otherwise wouldn't have found if those weren't there- because I don't know um like I've- mentioned this example before, but you have uh like a servlet control on that user transaction that invokes um persistence, context, operation over multiple invocations and a different thread is used and you find some bug that you would wouldn't have found.

A

Otherwise, if you didn't have those combinations of you know, operations being invoked.

D

Yeah I mean the platform should certainly be focused on the integration test. I mean, that's, that's what it should be for.

C

Yeah and I thought to agree with you so for the specs like servlet- it's definitely better to uh have all the tests tcks in the platform test, because uh it's celebrated basically integrates with many things right, but for json body and json processing.

C

I'm not sure about that, uh and uh uh just remember that the convenience of standalone g unit test is that when you make your implementation, you can run this dck. That's as part of of your maven build and easily detect problems right.

C

So it's kind of a trade-off as a as I understand right and we need to solve it somehow, because release date is closed. Yeah and the uh this is exactly this is. This is a blocking issue for these two specs right, so uh sooner we uh solve it sooner. We submit specs for a belt.

D

Well so it did, I mean it seems like to me the the the best proposal is to just remove the api test. Do the does the the tck jsonp api directory? Does that have any integration test, or is that strictly implementation functionality that now is being handled by the standalone tck.

C

Yeah, I would agree with that. uh I I I I'm just not sure how we make this decision right because ad, for instance, disagrees right and.

D

Well, no, I think that's the proposal that we take to the the platform um you know and have the dual scouts representing the platform tck and we have others representing the implementations and we have people representing the specs. Can we just make that decision? This is the proposal and decide that that's acceptable for ee10.

C

Okay makes sense to.

B

Me, I'm not sure I disagree, I'm just no. I I don't like reducing the compatibility requirements right so.

D

Yeah and uh yeah, I agree so that's that's. What I'm trying to understand is: is there a clear separation between integration tests and basically, just functionality, tests that are not maybe not even not only consumed but probably extended in the new standalone tck.

C

Yeah, we definitely need to do it with a minimum loss right or even with no loss right, yeah.

B

And we might also decide well we'll do that for 10., we'll bring them back in 11.. I mean that's also possible.

C

In 11, it would be better to actually make this vehicle, which allows running j-unit tests as part of the platform tests. So.

B

Yeah you're bringing the test back. Yes,.

A

B

A

Sorry go ahead.

B

A

Just you know the big, the big, the big change we're making for um the refactoring is just you know. It's switching to you know multi. You know multi multi um module. um You know maven. You know projects that um um you know that you know move off of the ant and the porting kit and um can integrate into um you know with you know, junit or test ng. um We didn't actually pick one, um but you know the idea was to start use. You know you know basically start creating this the same.

A

You know the same tck's um stan in the platform tck that could be just easily uh extracted into standalone tcks with the platform integration already ready to go, um and then you know just kind of like if we wanted to split it up, because we already you know we'll have we'll have all the standalone tcks ready to go almost you know they just happen to live in the platform. Tck repository, that's kind of the idea, but you know that should integrate more easily as well with separate tcks.

D

Okay, so my proposal would be: is that we we have um the the spec team validate that you know some subset of the existing platform. Tck tests are really just implementation tests that are now.

D

Superseded by the standalone tck and can be removed and the and whatever integration tests remain will are, are not duplicate tests. They are additional to test they're dealing with the platform, level requirements and they'll, so we're going to have to run a standalone tck and those integrations sons. The the tests that were that have been superseded by the standalone tck.

B

So I think the platform test requirements will be run. The standalone, tck and the platform tck will contain some yes someday some tests that are copied or or uh ported from the uh extracted the. What did you call the plugability tests? um Well, those will actually continue to exist inside the platform. Tck project and be tested against each container is that right.

D

B

D

I mean before for jsonp those integration tests already exist in the tck right.

B

uh I don't know if they've been updated and then copied back.

A

That's the thing they haven't been uh well.

D

A

D

Yeah they haven't been built at all in the standalone tck because they were strictly.

A

They haven't been updated in the.

D

D

Well, that's the issues there there's api changes that need to be updated right.

B

So so the the tests in the extracted tck that are common need to find their way back into the the tests in the extracted. Tck must be that they're going to be common to both the the standalone tck and the platform. Tck must be identical.

A

They need to be identical or they need to test the current. You know the up.

B

Updated test must be identical, however, that is accomplished.

B

um I mean just gotta port. The test back.

B

If someone's will you know, someone can look at them and say nope, this test doesn't change I'll, just leave it. That's point two. You know there doesn't have to be a physical copy action.

D

Yeah, the issue is that there's there's tests that just don't apply to the standalone tck in the in the platform tck.

B

If they're, not in the extracted pc, I thought they were there.

D

You know what I'm hearing is they're, not because they depend on.

D

They depend on container deployment features. Is that not right.

B

Where lucas are the are those plugability tests in the standalone, tck.

E

Oh uh yes, uh I have it in jsonp, but they run in seo only so they have to stay at the platform level, because the containers do have different class loading models and everything. So.

E

On the one hand, they are tested the same behavior, on the other hand, within different contexts, so yeah.

D

C

So I'm reading I'm reading these bullets, and uh this is something different. What you're talking about right, standalone tck, will contain tests extracted from the platform pck like jsonp plugability tests- yeah it can, but it it should not right. So it's kind of up to the spec team right, for instance, we have in json binding a new functionality which we added to standalone tests standalone. I mean extracted tests only at the moment and we don't exist in the platform pck, because we are not testing anything platform related right.

B

Are there changes to the plugability test.

C

We're testing about if we're talking about the plugability test, what lucas mentioned.

E

No well in the car, there are no changes, but the difference is really the behavior of glass holders in each container and availability of implementations and stuff like that right, because, if within the web container, this test basically adds custom implementation of jsonp into the deployment unit and expects that uh what's provided in the var is used instead of yeah, and this is different from the behavior or merge in java se.

E

C

E

It it does the same thing, but in different.

C

Contexts java sd is also container right, so basically, this test tests, something in different containers, including java c right. So.

E

That's okay: we have to keep it in both places. Basically, that's what I'm trying to say what.

C

I'm trying to say what I'm trying to say that uh there are platform tests right uh which should test interoperability in case of uh uh your uh how's. It called plugability test. It should be in the platform tests right and there may be something else, and there are standalone tests which are testing your implementation right, standalone, javascript and in case of json b.

C

Your plugability test should be there too right and uh that standalone tests should contain a bunch of other tests right which are testing that implementation is compatible with specification, and this bunch of tests should potentially not be a part of a platform test right.

E

In my opinion, it doesn't have to be important from my own personal perspective. What's important at the platform level is to execute signature tests within each container to execute these plugability tests in each container, and probably one or two some simple tests, and that's basically it, but that's just my opinion.

C

But I I think they are talking about the same so.

D

Yeah, I think that's what we're trying to agree on. I think we agree on that.

A

I I guess the the question was yeah, so there's two different options here. You know the question marks um either. um You know the tests need to be identical in both or um it's just that the platform tck needs to have. It needs to be synced and updated to to contain into you know the updated api usage.

A

That's in the standalone, but not necessarily all the same tests as the stand-alone tck. So yeah do we allow varying amounts or do we have identical tests and only test what can be tested in both, which means a reduction in both.

E

A

So I think it's.

E

A

First case.

C

I think we are going too deep into details at the moment. It can't.

A

Be the same, it can be not probably.

D

I don't see any point for them to be identical, because what was the point of pulling them out, then I mean clearly you have functionality that is just targeted to implementation, details that you're trying to exercise relative to the specification that has nothing to do with the container environment, and then you have details on if I'm an e2b component or I'm deploying an application with these components, and I need control over how I bundled the implementations of you know: serializers, deserializers, etc, etc.

D

At the container level that that's when I need to test, I mean all the other details have already been tested. There's no point to retesting them within the container, unless there's expectation that things like a security context or transaction context or persistence context are going to affect it, because it's something that's the case for jsonp, because they're relatively focused specifications.

A

So is what was the idea of having identical tests just so because we don't want to lose the platform tests that are already there? Was that the kind of the thinking there? Okay.

B

So what I was trying to ask was from the moment we extracted those vulnerability tests to what exists in the tck today. Were there any changes with respect to, however, they're testing compatibility?

B

If there weren't, then we already have the tests we need in platform tck. We don't need to copy anything back if there have been changes, since it was extracted. If they're doing something different to verify compatibility, then those whatever those modifications are need to get back in to the platform.

E

I believe that these plugability tests are insane.

B

So, if that's the case, then we just delete all the other tab. You know we just disable all the other tests uh run this the standalone vehicle and then run the plugability test in each of these um each of these vehicles, and I think we're done.

A

Okay, so so we okay, so basically I'm gonna move that up. I guess that's. I guess I guess this is really okay. So if the plugability test, if the json, let's make sure I capture this and uh plug up data.

B

Hey, I don't know that you need to capture it all. I think you could just say we we've concluded that the plugability testings in the platform tck our situation for ee10.

B

If you want to make a note that we need to remind ourselves that those plugability tests are shared between these two tcks, that wouldn't be a terrible thing, because eventually one of them will change. You know the most likely the plugability somebody will add a new plugability test in the standalone tck. We want to make sure that that gets that reflected back these these these. These test suite needs to remain synchronized.

B

Okay, all right.

A

Okay, so that's really the defining thing and- and that was because you know the spec- the spec lead identified. You know that is important, and that was the conversation and we had it right here: great okay, I'm just gonna. I think I can remove the rest of this. Then.

A

D

Yeah, I think that's just.

B

So I'm I'm good with that for json bmp, I don't know scott, uh I don't know about tdi or you do you have it.

D

B

D

These are guys already dealing with this problem, but you know, but they we used our killing to deal with it. So, okay, yeah I mean the bigger question for cdi is in the future.

D

We want to break out the fact that we have dependencies on all these of downstream containers so that we can actually really get to today. Yeah.

B

I agree with you.

A

Okay, so for the other tcks we'll need to identify which tests must stay in the platform, so we can remove. So we could remove the other test.

B

Well see the thing just scott. The the concern I have is that in many cases the component specs, don't necessarily have an in. You know an intimate understanding of what the platform requirements are yeah right. So um you know I. I don't think we can entirely rely on the component teams to do that. Analysis. Right. No.

D

B

Group has to do I mean okay,.

D

Now, whoever wrote the integration test you know needs to verify that um that there aren't additional integration tests required. You know for a given update to a component specification.

B

Right so jms, you know, you know, there's a bunch of stuff in our message: that's jms related, but the standalone gms that has nothing.

B

Anyway, okay um we're over time- and I think at least I have to get on to another call.

A

Okay, thanks everybody, I'm going to stop recording now.

E

Thank you have a nice day.