Comment out MVC temporarily to have CDI TCK passing again

[arjantijms]

Signed-off-by: Arjan Tijms arjan.tijms@gmail.com

[dmatej]

No, not again! :D

[dmatej]

So ... here we go to investigation ...
| 210f6f2 | 1831 | 0 | OK | PR with last MVC integration |
| 3cde738 | 1831 | 0 | OK | After merge with last MVC integration |
| a24af3b | 1831 | 0 | OK | Merge pull request #24016 from arjantijms/tck_concurrency_sigtest |
| cc62657 | 1827 | 4 | FAIL | Using older mvc-api version 2.0.1 |

Before the last commit I noticed stacktraces in server.log, but in that state with mvc-api 2.1.0.M1 it passed CDI TCK. Time to make it right ...

Option 1: MVC-API 2.0.1 + resolve conflict with CDI, why 4 tests fail?
Option 2: MVC-API 2.1.0.M1 + fix those stacktraces. Does it even work or those exceptions just prevent MVC to start, then CDI just passes? Then it would be a worse equivalent to this PR ...
What is really happening?

[ERROR] Failures:
[ERROR]   ProcessBeanAttributesNotFiredForBuiltinBean>Arquillian.run:138->testProcessBeanAttributesNotFired:51 expected [true] but found [false]
[ERROR]   AfterTypeDiscoveryTest>Arquillian.run:138->testFinalAlternatives:128 expected [true] but found [false]
[ERROR]   AfterTypeDiscoveryTest>Arquillian.run:138->testInitialAlternatives:81 expected [3] but found [11]
[ERROR]   AfterTypeDiscoveryMassOperationsTest>Arquillian.run:138->testInitialAlternatives:77 expected [3] but found [11]

[dmatej]

mvn clean install -Pfastest -Djakarta.mvc-api.version=2.1.0.M1 -T4C && mvn clean install -Pstaging,tck -pl :glassfish-external-tck-cdi -Dit.test=ProcessBeanAttributesNotFiredForBuiltinBean

vs.

mvn clean install -Pfastest -Djakarta.mvc-api.version=2.0.1 -T4C && mvn clean install -Pstaging,tck -pl :glassfish-external-tck-cdi -Dit.test=ProcessBeanAttributesNotFiredForBuiltinBean

• compare server.log

[dmatej]

Hmmm, 2.1.0.M1 simply disables Krazo:

[2022-06-26T22:57:40.333862+02:00] [glassfish 7.0] [SEVERE] [] [jakarta.enterprise.web.core] [tid: _ThreadID=66 _ThreadName=admin-listener(3)] [timeMillis: 1656277060333] [levelValue: 1000] [[
  java.util.ServiceConfigurationError: jakarta.servlet.ServletContainerInitializer: Provider org.eclipse.krazo.servlet.KrazoContainerInitializer not found
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1219)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1228)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
	at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:5289)
	at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:627)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5227)
	at com.sun.enterprise.web.WebModule.start(WebModule.java:549)
...
[2022-06-26T22:57:40.737397+02:00] [glassfish 7.0] [WARNING] [] [ServiceLoader] [tid: _ThreadID=66 _ThreadName=admin-listener(3)] [timeMillis: 1656277060737] [levelValue: 900] [[
  Could not load service class org.eclipse.krazo.cdi.KrazoCdiExtension]]

[dmatej]

This PR is not acceptable, maybe passes TCK, but still ends with the stacktrace in the server.log. Maybe we can exclude krazo too then ... but ... why the hell is 2.0.1 is breaking CDI TCK tests???!

Simply said, we are fixing CDI TCK tests by breaking Krazo+MVC.

[dmatej]

This is the difference in the server.log:
left fails the TCK, right passed.

...

Caused by: javax.naming.NamingException: Lookup failed for 'java:comp/BeanManager' in SerialContext[myEnv={java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:480)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:427)
	at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
	at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
	at org.glassfish.soteria.cdi.CdiUtils.jndiLookup(CdiUtils.java:209)
	... 93 more
Caused by: javax.naming.NamingException: Error retrieving java:comp/BeanManager [Root exception is java.lang.IllegalStateException: Cannot resolve bean manager]
	at org.glassfish.weld.BeanManagerNamingProxy.handle(BeanManagerNamingProxy.java:98)
	at com.sun.enterprise.naming.impl.NamedNamingObjectManager.tryNamedProxies(NamedNamingObjectManager.java:75)
	at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:140)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:460)
	... 97 more
Caused by: java.lang.IllegalStateException: Cannot resolve bean manager
	at org.glassfish.weld.BeanManagerNamingProxy.handle(BeanManagerNamingProxy.java:93)
	... 100 more

[arjantijms]

Maybe we can exclude krazo too then

It should already have been excluded. Hmmm.

[dmatej]

Maybe we can exclude krazo too then

It should already have been excluded. Hmmm.

Aha, sorry, I excluded just mvc-api, you're right.

[dmatej]

I'm approving that, seems there is some issue with empty beans.xml and perhaps we can fix that tomorrow ... today ... no steps back .. except for few days :)