|Re: [jakartaee-platform-dev] Assumption that WAR can contain SE service files (for CDI extensions) causes TCK failures|
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.
Pure servlet never passes CDI TCK nor does CDI spec explicitly states support for it.
CDI 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:______________________________Hi,On Tue, May 24, 2022 at 10:39 AM Matej Novotny <manovotn@xxxxxxxxxx> 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.javaHowever, 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
To unsubscribe from this list, visit https://www.eclipse.org/
Back to the top