-
Notifications
You must be signed in to change notification settings - Fork 125
EE 11 Slack discussion persistence tests September 24, 2025
Brian Decker Wednesday at 2:25 PM Done with ejb30, I've switched my focus to the persistence tests... Has anyone (other than Glassfish, I guess) run the appclient tests in this bucket? I'm running smack into what seems like an obvious spec violation in the AppManagedVehicle. It consists of a Stateful EJB that is (now in 11.0.x) using @Transactional to mark a method. I know that some implementations allow this anyway, but it's forbidden by 15.3.3 in the EJB spec: It is illegal to associate Jakarta Transactions transactional interceptors with Enterprise Beans. The Enterprise Beans Container should fail deployment of such applications. Open Liberty accordingly fails deployment of all of these test applications, rendering them unusable. The easy solution would be to change this (and any others that I haven't hit yet) to use jakarta.ejb.TransactionAttribute instead. 64 replies
Brian Decker Wednesday at 2:26 PM Curiously, the 10.0.x version of this vehicle has that method tagged as @Remove, which also seems pretty weird, so I can see why there was a temptation to change things. It just wasn't changed to the right thing for an EJB. (edited)
Brian Decker Wednesday at 2:33 PM Reading through my errors, it looks like at least Stateful3VehicleBean has the same problem.
Jared Anderson Wednesday at 3:21 PM I take it that you will be opening up a new challenge for this issue. 3:23 I am guessing that the TCK is missing tests for the error condition that you are pointing out. May need to add some EJB TCK tests in EE 12.
Brian Decker Wednesday at 4:37 PM Yes, to a challenge. From talking to folks, the rest of that would be complicated.
Brian Decker Wednesday at 5:20 PM I can see that this was specifically added by @Scott Marlow here -- https://github.com/jakartaee/platform-tck/pull/2137 Scott, do you recall if this actually resolved failures on your end? Or was it just an attempt to fix stuff that ultimately doesn't end up being needed for the Glassfish runs?
Scott Marlow Wednesday at 6:36 PM Hmm, that looks like a mistake, should of used https://jakarta.ee/specifications/enterprise-beans/4.0/apidocs/jakarta/ejb/transactionattributetype#REQUIRED 6:36 Which should be the default but agree that should be changed. :dart: 1
Brian Decker Wednesday at 6:37 PM Right, should be the default, so is probably not actually needed. If it is somehow needed by a particular implementation that sounds like a bug on their part not a problem with the test. (edited)
Scott Marlow Wednesday at 6:38 PM Right we should delete it as per the referenced ejb requirement. 6:38 https://jakarta.ee/specifications/enterprise-beans/4.0/jakarta-enterprise-beans-spec-core-4.0#a9644 I mean as you mentioned.
Brian Decker Wednesday at 6:39 PM As I note, there also used to be an @Remove annotation on that method that should probably be restored. It was removed when that bean was temporarily made Stateless during dev and then switched back to Stateful. :+1: 1
Scott Marlow Wednesday at 6:40 PM At the time I think we were trying to quickly solve a lot of Persistence failures. 6:41 That change probably had no impact 6:43 Has anyone (other than Glassfish, I guess) run the appclient tests in this bucket? I'm running smack into what seems like an obvious spec violation in the AppManagedVehicle. Not yet but will soon.
Jared Anderson Wednesday at 7:08 PM While you were gone Payara also submitted CCRs for Web Profile and Platform 11 using a beta build and Scott marked the CCRs accepted today.
Scott Marlow Wednesday at 7:44 PM I haven't looked at Payara source but thought it was a fork of GlassFish but not really sure if they sync with major GlassFish source releases or not. 7:45 But sure they count as passing those tests as well.
Arjan Tijms Thursday at 1:44 PM Payara is indeed a GlassFish fork, and they do, more or less, sync with GlassFish code 1:45 EJB hasn’t changed much over the years, so the implementation in GlassFish and Payara are pretty much identical, safe for perhaps the odd bug fix here and there. 1:46 Some newer things are different though. E.g. the Payara Jakarta Data implementation is completely different from the GlassFish Jakarta Data implementation.
Jared Anderson Thursday at 1:46 PM Yeah, the problem is glassfish allows @Transactional even though the spec says not to allow it so the problem was not caught during ratification.
Arjan Tijms Thursday at 1:47 PM Yeah, I noticed before that the GlassFish engineers that came before the current team mostly focussed on positive spec implementations, and didn’t so much explicitly implement negative (forbidden) things. WebSphere and later Liberty has always been more strict about it.
Brian Decker Thursday at 6:21 PM Goodness. It took a bit of tinkering to get these appclient tests set up with the right context roots, but we're cooking with oil now. [INFO] Tests run: 130, Failures: 0, Errors: 0, Skipped: 0 Only eleventy billion persistence tests left to go...
James R. Perkins Thursday at 6:47 PM Yeah, the persistence TCK is huge. We're failing pretty miserably on WildFly, or we were. However, the integration work is not complete so I haven't dug too much into the failures yet. On my local VM the tests take something like 9 hours to run.
Ondro Friday at 4:22 AM Payara submitted a CCR for Jakarta EE 11 Platform, so they should have passed the test too. Maybe somebody from Payara can confirm? @Andrew Pielage?
Arjan Tijms Friday at 7:28 AM Well, all the persistence tests themselves via the servlet protocol are quite fast. 7:28 It’s the appclient ones that are crazy over the top slow
James R. Perkins Friday at 9:56 AM Yeah, it took 16 minutes for the web profile, but the others take more time.
Brian Decker Friday at 12:46 PM I mentioned context roots for these tests upthread... I've found myself having to generate/include rather boilerplateish application.xml files for each of these apps (and there are many) that look something like this: appmanaged_vehicle_web.war jpa_core_annotations_access_field_vehicles
<module>
<ejb>jpa_core_annotations_access_field_appmanaged_vehicle_ejb.jar</ejb>
</module>
<module>
<java>jpa_core_annotations_access_field_vehicles_client.jar</java>
</module>
Jared Anderson Friday at 12:49 PM If you are going to make application.xml files, you probably should use the EE 11 application xsd file with version = 11.
Brian Decker Friday at 12:49 PM That is true. Didn't think about it -- just stole a header from another application.xml already in the EE 11 TCK. 12:50 So apparently that's not a thing that was done in the TCK? Struggling to find one that is version 11.
James R. Perkins Friday at 12:51 PM It may have been a chicken and egg issue where the XSD didn't exist at the point of migration and never got re-addressed.
Scott Marlow Friday at 12:58 PM I vaguely remember updating a bunch of the application.xml files I think for EE 10 but don't think we had time for EE 11
Scott Marlow Friday at 1:08 PM For EE 12 TCKs we should update to EE 11 application.xml files or even 12 if that becomes available when we have time to make the change.
Brian Decker Friday at 1:10 PM Anyway, my actual question specific to persistence and the multitude of vehicle tests has been obscured by the statement about versions. Any thoughts on that from folks?
James R. Perkins Friday at 1:21 PM It seems reasonable to me that the TCK test itself should provide those. Especially given it's a standard deployment descriptor. My complete guess on how GlassFish passes is tests seem to include tcks/apis/persistence/persistence-inside-container/spec-tests/src/main/resources/com/sun/ts/tests/common/vehicle/appmanaged/appmanaged_vehicle_ejb.jar.sun-ejb-jar.xml by default. 1:22 Let me get a real link 🙂 https://github.com/jakartaee/platform-tck/blob/3e642738584b2e4b9a6a9d80bb12fed6b53[…]n/vehicle/appmanaged/appmanaged_vehicle_ejb.jar.sun-ejb-jar.xml appmanaged_vehicle_ejb.jar.sun-ejb-jar.xml This Source Code may also be made available under the following Secondary https://github.com/[jakartaee/platform-tck](https://github.com/jakartaee/platform-tck)|jakartaee/platform-tckjakartaee/platform-tck | Added by GitHub
Arjan Tijms Friday at 1:26 PM All the runners and the jobs that run them are public for glassfish, so it should be possible to see exactly what’s being run
Scott Marlow Friday at 1:34 PM I think https://github.com/jakartaee/platform-tck/blob/main/tcks/apis/persistence/persiste[…]istence/core/annotations/access/field/Client1Stateful3Test.java is the source that corresponds to the mentioned test that you generated an application.xml for. The top of that test shows the EE 10 archive contents which do not mention an application.xml. For the same test actually in EE 10, I see no application.xml which is in sync with what I observed for EE 11: jar tf jpa_core_annotations_access_field_vehicles.ear META-INF/ META-INF/MANIFEST.MF jpa_core_annotations_access_field_appmanagedNoTx_vehicle_client.jar jpa_core_annotations_access_field_appmanagedNoTx_vehicle_ejb.jar jpa_core_annotations_access_field_appmanaged_vehicle_client.jar jpa_core_annotations_access_field_appmanaged_vehicle_ejb.jar jpa_core_annotations_access_field_pmservlet_vehicle_web.war jpa_core_annotations_access_field_puservlet_vehicle_web.war jpa_core_annotations_access_field_stateful3_vehicle_client.jar jpa_core_annotations_access_field_stateful3_vehicle_ejb.jar jpa_core_annotations_access_field_stateless3_vehicle_client.jar jpa_core_annotations_access_field_stateless3_vehicle_ejb.jar lib/ lib/jpa_core_annotations_access_field.jar 1:36 I've found myself having to generate/include rather boilerplateish application.xml files for each of these apps My comment ^ is in response to Brian having to generate application.xml files.
Brian Decker Friday at 1:36 PM Yeah, I agree with all of the findings, which is why I haven't been able to figure out how GF is using the correct context root for these tests. 1:37 The test calls /* for each whereas the default root would be /* 1:38 The web modules in question aren't even actually added to the apps in the TCK code. That happens in the tck-appclient protocol code. 1:41 So the necessary (to me) part of the application.xml files I've been adding is: appmanaged_vehicle_web.war jpa_core_annotations_access_field_vehicles
Brian Decker Friday at 1:51 PM EE 10 is a bit of a moot comparison. The EE 11 apps are constructed differently: image.png
image.png
1:52 Each vehicle gets its own separate app created, all with the same ear name. 1:52 Whereas in EE 10, as you can see from Scott's output, there's a lot more bundled together. :+1: 1
Scott Marlow Friday at 2:45 PM Do you have deploy time tooling in earlier EE releases that generated or used externally defined application.xml files that are now all wrong?
Brian Decker Friday at 2:46 PM No, the old app structure didn't require anything of the sort for these. I don't even think there are servlets as part of the call chain in EE 10. Looking at what you posted, there's not a war at any rate, other than the ones for the WebProfile vehicles. 2:51 I think the clients called directly to the EJBs in EE <=10?
Scott Marlow Friday at 3:10 PM The clients called into servlet vehicle for tests identified in https://github.com/jakartaee/platform-tck/blob/10.0.x/install/jakartaee/other/vehicle.properties for servlet
Brian Decker Friday at 3:12 PM Sure, but my point is that the appmanagedflow (to use one example) didn't used to involve a servlet. Now it does, and it uses one with a non-standard context-root.
Scott Marlow Friday at 3:30 PM I need to look at something else but it sounds like a challenge is coming for either missing application.xml or maybe missing war packaging.
Brian Decker Friday at 3:33 PM I don't know that I'm planning a challenge for this. It's more of a request for improvement (and/or a 'what am I missing?' check) than anything else. But if all of the vendors are finding themselves having to invent stuff to work around it, then maybe it could/should be done as a challenge. That's why I was curious as to how Glassfish was handling it. I don't see anything in the runner that's doing anything in this space. Maybe there's a GF config setting to use app-name as context root or something? No idea. (edited)
Scott Marlow Friday at 3:45 PM We will hopefully catch up soon with WildFly just not there yet.
David Matějček Friday at 4:04 PM Payara doesn't sync, in fact GF and PA are diverging a lot as each has own users and own teams and also even different new features.
David Matějček Friday at 4:14 PM About the appname, there are several options in GlassFish: Take name from command line if set explicitly Take name from [sun/glassfish]-application.xml if set Take name from application.xml if set Take name from the ear file name as default With Arquillian it brought a new problem, @Arjan Tijms found that today - with latest versions of the omnifish-arq-container I set the file name explicitly (like from command line), because there were memory leaks otherwise - arq did not know the name of the app to undeploy. But that means that all other options are ignored. In older TCK versions of multiple pieces were used very old container versions for GF, each with different bugs around, we started now using always the same. So, I guess similar problem can have anyone else too, I guess ... seems the only option is to parse deployed descriptors ... or parse response from the server which should send the deployed final app name. Or make it configurable, which would be transparent ... and it doesn't conflict with other ways. And yeah, maybe there was some descriptor now missing, @Arjan Tijms tried to check yesterday, I forgot results. (edited)
Brian Decker Friday at 4:21 PM It's not about knowing the appname per se, it's about using it as the context root. By default, all of these tests will try to call the apps at localhost//* But also by default, web modules are bound at localhost//* Something needs to tell the server under test to put everything in the persistence bucket that's using a tck-appclient vehicle at instead. :+1: 1
4:22 It is quite literally hundreds of applications because this bucket is so enormous, so I've had to write some code to dynamically create an appropriate application.xml for each app in order to set things properly. Also sent to the channel
Brian Decker Today at 12:12 PM Challenge opened for the @Transactional issue: https://github.com/jakartaee/platform-tck/issues/2469 I have one more challenge coming for Persistence, but otherwise have gotten the whole thing running. :+1: 1
Scott Marlow 1 minute ago As a reminder, this conversation will be deleted before the end of December, 2025. I wonder if we should paste a copy of this slack thread into the Platform TCK wiki for future reference? I'd hate to lose the content as needed in the future, especially about the context root problem with hundreds of test deployments.