| Re: [jakartaee-platform-dev] Assumption that WAR can contain SE service files (for CDI extensions) causes TCK failures |
Hi,
On Tuesday, May 24, 2022, Matej Novotny <manovotn@xxxxxxxxxx> wrote:The tree tests indeed force a war to not become BDA, but it does need to have CDI enabled. This is a new situation, which can only exist if the server explicitly recognizes that this is a support case.You could turn this into a case where you put the extension into WAR/lib but make sure neither WAR nor its lib is a BDA and it should still work.I’m going to try a couple of things to see if I can make GlassFish support this directly. Maybe using a trick like moving the code to a synthetic jar file internally may work, not sure yet.
I do wonder if other servers will also hit this. Did OpenLiberty already pass?
Pure servlet never passes CDI TCK nor does CDI spec explicitly states support for it.I know, but I meant that by needing to pass the CDI TCK, CDI forced full EE servers to support loading services from web-inf/classes.Since pure Servlet indeed doesn’t need to pass CDI, there’s nothing forcing them to support loading services from web-inf/classes.Kind regards,Arjan TijmsCDI targets only full blown EE and standalone SE usage._______________________________________________So whether servlet supports this (corner) case or not is of little importance WRT what's in the TCKs.MatejOn Tue, May 24, 2022 at 10:55 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:_______________________________________________The issue you linked is about reading the service file from WAR regardless of whether it is supposed to be a BDA or not.And this is done by many more existing TCKs which I assume you pass just fine (here is an example https://github.com/jakartaee/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/full/extensions/lifecycle/bbd/BeforeBeanDiscoveryTest.java).However, the three tests you noted here are probably the only tests in TCK that enforce the situation where there is a legitimate extension but the archive itself is not a BDA.So I'd say the cause for these test failures is elsewhere?Indeed, though they are related in a way.The GF code makes no assumption when creating the deployment structure that WEB-INF/classes can contain extensions. So when creating the top level deployment artefacts it simply doesn't scan for this explicitly.With a bean.xml present, the war is normally scanned, and any extension in WEB-INF/classes is picked up almost by accident it seems (but it's good it does work).The tree tests indeed force a war to not become BDA, but it does need to have CDI enabled. This is a new situation, which can only exist if the server explicitly recognizes that this is a support case.In short, I'm not sure it's defined anywhere that a Servlet container should be able to load SE service files from "WEB-INF/classes/META-INF/services", as the spec only ever talks about jars in WEB-INF/lib.I am not sure how defined this is but the TCKs have had many tests with this structure for years and all all EE servers seemed to have passed them.So seemingly it's not defined, but either it worked by accident (as it looks like in GF) or perhaps servers made this work just for CDI, even though a pure Servlet container that never passed the CDI TCK, but does pass the Servlet TCK, may not support this still.Kind regards,Arjan Tijms
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-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