Outstanding failures in cditck-porting tests with glassfish 6 web profile. #23184

gurunrao · 2020-08-18T14:49:42Z

cditck-porting tests fail with glassfish 6 web profile.

Environment Details

GlassFish Version (and build number):6 nightly build Web profile.
JDK version:1.8
OS:Linux
Database:Derby

Test results can be found here - https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/82/testReport/

Run Log and glassfish logs can be downloaded from here - https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/82/artifact/cdi-tck-results.tar.gz

Run logs can be viewed here - https://ci.eclipse.org/jakartaee-tck/blue/rest/organizations/jenkins/pipelines/cditck-porting/branches/master/runs/82/nodes/27/steps/30/log/?start=0

gurunrao · 2020-08-28T08:33:43Z

@starksm64 - Most of failure above are related to removal of "jakarta/xml/ws/WebServiceRef" package or webservices jars from glassfish 6 web-profile bundle.

scottmarlow · 2020-08-31T15:26:31Z

@smillidge @starksm64 @alwin-joseph @gurunrao @alwin-joseph

I noticed that we aren't actually collecting the GlassFish logs in https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/82/artifact/cdi-tck-results.tar.gz

IMO we should archive the GlassFish logs for https://ci.eclipse.org/jakartaee-tck/job/cditck-porting job so the exact cause of CDI deployment failure:jakarta/xml/ws/WebServiceRef can be viewed.

FYI a related failure was addressed by @gurunrao via jakartaee/platform-tck#480.

scottmarlow · 2020-08-31T15:29:53Z

https://github.com/eclipse-ee4j/cditck-porting/blob/master/Jenkinsfile#L99 needs to be updated to collect the GlassFish logs.

An example of archiving all logs is https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/Jenkinsfile#L222, I'll create a pull request that is similar.

starksm64 · 2020-08-31T15:32:26Z

Note there is a new CDI TCK release that fixes a missed javax.xml.ws package, so likely that is the issue. The new candidate TCK is at: https://download.eclipse.org/ee4j/cdi/3.0/cdi-tck-3.0.1-dist.zip

…

On Mon, Aug 31, 2020 at 10:26 AM Scott Marlow ***@***.***> wrote: @smillidge <https://github.com/smillidge> @starksm64 <https://github.com/starksm64> @alwin-joseph <https://github.com/alwin-joseph> @gurunrao <https://github.com/gurunrao> @alwin-joseph <https://github.com/alwin-joseph> I noticed that we aren't actually collecting the GlassFish logs in https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/82/artifact/cdi-tck-results.tar.gz IMO we should archive the GlassFish logs for https://ci.eclipse.org/jakartaee-tck/job/cditck-porting job so the exact cause of CDI deployment failure:jakarta/xml/ws/WebServiceRef can be viewed. FYI a related failure was addressed by @gurunrao <https://github.com/gurunrao> via jakartaee/platform-tck#480 <jakartaee/platform-tck#480>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23184 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMQJSBGROHUTS5CL3MDSDO6LNANCNFSM4QDS7UUQ> .

scottmarlow · 2020-08-31T15:37:44Z

👍 Will try https://download.eclipse.org/ee4j/cdi/3.0/cdi-tck-3.0.1-dist.zip

Also created eclipse-ee4j/cditck-porting#22 :-)

scottmarlow · 2020-08-31T18:43:55Z

My pr didn't correctly reference the GlassFish server.log folder but now see the output now from Guru's job output that contains java.lang.ClassNotFoundException: jakarta.xml.ws.WebServiceRef not found by org.glassfish.main.web.weld-integration

server.log

@smillidge does the GlassFish Web Profile have a dependency on org.glassfish.metro:webservices-api-osgi?

More complete exception call stack:

org.glassfish.deployment.common.DeploymentException: CDI deployment failure:jakarta/xml/ws/WebServiceRef
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:212)
	at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:107)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:304)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:472)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:195)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:467)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:516)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:512)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:360)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:511)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:542)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:534)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:360)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:533)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1441)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:86)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1823)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1699)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:230)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:208)
	at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:252)
	at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:305)
	at org.glassfish.admin.rest.resources.TemplateListOfResource.post(TemplateListOfResource.java:140)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:469)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:391)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:356)
	at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:292)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:155)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:440)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:144)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:174)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:153)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:196)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:88)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:248)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:181)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:121)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:99)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:51)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:510)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:82)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:83)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:34)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:101)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
	at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.WeldException: jakarta/xml/ws/WebServiceRef
	at org.jboss.weld.executor.AbstractExecutorServices.checkForExceptions(AbstractExecutorServices.java:82)
	at org.jboss.weld.executor.AbstractExecutorServices.invokeAllAndCheckForExceptions(AbstractExecutorServices.java:59)
	at org.jboss.weld.executor.AbstractExecutorServices.invokeAllAndCheckForExceptions(AbstractExecutorServices.java:67)
	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer.createClassBeans(ConcurrentBeanDeployer.java:65)
	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:256)
	at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:438)
	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:86)
	at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:200)
	... 67 more
Caused by: java.lang.NoClassDefFoundError: jakarta/xml/ws/WebServiceRef
	at org.glassfish.weld.services.WsInjectionHandlerImpl.handles(WsInjectionHandlerImpl.java:33)
	at org.glassfish.weld.services.InjectionServicesImpl.registerInjectionTarget(InjectionServicesImpl.java:181)
	at org.jboss.weld.manager.InjectionTargetFactoryImpl.postProcess(InjectionTargetFactoryImpl.java:159)
	at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:94)
	at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:102)
	at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:82)
	at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:280)
	at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:221)
	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:68)
	at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:65)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	... 1 more
Caused by: java.lang.ClassNotFoundException: jakarta.xml.ws.WebServiceRef not found by org.glassfish.main.web.weld-integration [230]
	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)
	at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 16 more
]]

gurunrao · 2020-09-01T07:17:59Z

@lukasj - Any suggestion on above stack-trace with "java.lang.ClassNotFoundException: jakarta.xml.ws.WebServiceRef".

lukasj · 2020-09-01T10:26:20Z

given that xml ws is not required part of web profile (not in EE 8, nor in EE 9), the failure is expected. The solution can be either to explicitly add XML Web Services to the Web Profile OR remove these tests from the TCK. The latter looks to be easier to do, while the former might be more correct, based on the fact that XML Web Services used to be supported by the JDK 8.

lukasj · 2020-09-01T10:31:18Z

Note that webservices jars were removed from web profile in Java EE 8 (at the latest, long before the move to EF) if they have ever been part of it and required functionality used to be taken from Java SE.

smillidge · 2020-09-01T11:19:42Z

hmm tricky this could be because the jars already existed in the JDK previously. I will take a longer look at the weld integration code to see if this can be isolated. However from the comment by @starksm64 it maybe that this is now a requirement in the Web Profile? Maybe one for the platform mailing list?

lukasj · 2020-09-01T12:43:46Z

looking at the spec more closely, there is currently following sentence:

...all Web Profile 9 APIs must support the Java™ Platform, Standard Edition 8 API...

and javax/xml/ws/WebServiceRef is SE 8 API but jakarta/xml/ws/WebServiceRef is not SE 8 API.

smillidge · 2020-09-01T13:15:19Z

I think this needs to go to the Platform project for a decision not something we can decide on the GlassFish project.

lukasj · 2020-09-01T13:23:50Z

@smillidge I agree with you

scottmarlow · 2020-09-01T13:51:38Z

The Table 2. Jakarta EE Technologies shows:

Jakarta EE Technology	App Client	Web	Enterprise Beans	Status
XML Web Services 3.0	Y	Y	Y	OPT

What does the above (Web Profile spec) link that @lukasj mentioned mean in contrast to the Platform SPEC Table 2? Do they mean the same?

Why does the linked Web Profile spec text still require running on JDK 11? IMO, likely needs an update:

For the first one, the Jakarta EE Platform specification mandates support for the “ java: ” naming context in all profiles. Consequently, Web Profile products must support it. For a similar reason, all Web Profile 9 APIs must support the Java™ Platform, Standard Edition 8 API, and all Web Profile 9 products must run on Java™ Platform, Standard Edition 11 runtime.

@smillidge In case it helps, here are a few more details to show some of the differences I see between Web Profile + Full Platform related pom.xml in GlassFish:

https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/pom.xml#L415 (Full Platform) has:

<dependency>
                <!-- Contains jakarta.jws, jakarta.xml.soap, jakarta.xml.ws -->
                <groupId>org.glassfish.metro</groupId>
                <artifactId>webservices-api-osgi</artifactId>
                <version>${webservices.version}</version>
            </dependency>

https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/web/weld-integration/pom.xml#L142 (Web Profile) has:

<!-- Since weld-integration artifact is part of web distro and we
             don't want webservices-api-osgi to be part of web distro, we
             mark this dependency as optional for it to be:
              - excluded by packager
              - optional for OSGi
        -->
        <dependency>
            <groupId>org.glassfish.metro</groupId>
            <artifactId>webservices-api-osgi</artifactId>
            <optional>true</optional>
        </dependency>

If https://jakarta.ee/specifications/xml-web-services/3.0/apidocs/jakarta.xml.ws/jakarta/xml/ws/WebServiceRef.html is optional for Full Platform + Web Profile both references #1 + #2 have optional=true? I don't know the OSGi internal rules that might be triggered in response to having optional=true but shouldn't the (Web Profile) jakarta.xml.ws.WebServiceRef class be found (or loaded on first reference) when it is referenced?

smillidge · 2020-09-01T14:53:33Z

I haven't had time to analyse the packaging in detail yet. It's probably that one excludes the jar from the packaging when building the web profile distribution i.e. it is not shipped.

smillidge · 2020-09-01T14:55:25Z

The GlassFish weld integration jar has it as an optional OSGI import. So it's likely that the weld integration jar is referencing it directly in the code and this hasn't been a problem before but I need to analyse more.

smillidge · 2020-09-01T15:01:58Z

tbh it is likely possible to handle the CNFE here

glassfish/appserver/web/weld-integration/src/main/java/org/glassfish/weld/services/InjectionServicesImpl.java

Line 182 in 6f0eed0

getWsHandler().validateWebServiceRef(annotatedField);

in the way the other validate methods are doing. However not sure what the test is doing?

scottmarlow · 2020-09-01T15:12:19Z

I also noticed https://github.com/weld/core/blob/master/jboss-tck-runner/pom.xml#L561 which is also interesting (not sure if it has any influence on what is going on in the Web Profile test failures):

        <!--This should probably be inside TCK itself in the future, remove if present there-->
        <profile>
            <!-- auto-activated profile for any JDK 9+ -->
            <id>jdk9+</id>
            <activation>
                <jdk>[9,)</jdk>
            </activation>
            <dependencies>
                <dependency>
                    <groupId>jakarta.xml.ws</groupId>
                    <artifactId>jakarta.xml.ws-api</artifactId>
                    <version>${jax.api.version}</version>
                    <scope>test</scope>
                </dependency>

lukasj · 2020-09-01T15:45:54Z

@scottmarlow for ${jax.api.version} >= 3.x, the profile makes no sense, since ${jax.api.version} has jakarta. packages and is not present in JDK < 9, so there is no conflict with the content of the JDK. A consequence is that jakarta packages from this jar are not available for tests on JDK 8. But there can be some reason why it is done this way and I just don't see it

starksm64 · 2020-09-01T16:14:13Z

It is just an artifact of the global javax to jakarta namespace changes. The profile will be removed once we move beyond Java 8.

…

On Tue, Sep 1, 2020 at 10:46 AM Lukas Jungmann ***@***.***> wrote: @scottmarlow <https://github.com/scottmarlow> for ${jax.api.version} >= 3.x, the profile makes no sense, since ${jax.api.version} has jakarta. packages and is not present in JDK < 9, so there is no conflict with the content of the JDK. A consequence is that jakarta packages from this jar are not available for tests on JDK 8. But there can be some reason why it is done this way and I just don't see it — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23184 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMTVXCPNBJTXEZJM3TLSDUJMFANCNFSM4QDS7UUQ> .

scottmarlow · 2020-09-02T17:00:04Z

Are the tests that fail due to jakarta/xml/ws/WebServiceRef class reference needed for testing only WebServiceRef? Or are the below tests useful for testing non-WebServiceRef aspects?

TCK test sources are in https://github.com/eclipse-ee4j/cdi-tck

List of failing tests:

org.jboss.cdi.tck.tests.alternative.selection.SelectedAlternative01Test.arquillianBeforeClass
org.jboss.cdi.tck.tests.alternative.AlternativeAvailabilityTest.arquillianBeforeClass 
org.jboss.cdi.tck.tests.context.dependent.DependentContextTest.arquillianBeforeClasssec
org.jboss.cdi.tck.tests.context.passivating.broken.producer.field.managed.dependent.ManagedBeanWithIllegalDependencyTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.context.passivating.broken.producer.field.enterprise.EnterpriseBeanWithIllegalDependencyTest.arquillianBeforeClass 
org.jboss.cdi.tck.tests.context.passivating.producer.ProducerWithPrimitiveFieldTypePassivationTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.context.passivating.PassivatingContextTest.arquillianBeforeClass 
org.jboss.cdi.tck.tests.decorators.definition.broken.parameterizedTypesWithDifferentTypeParameters.DifferentTypeParametersTest.arquillianBeforeClass 
org.jboss.cdi.tck.tests.decorators.definition.producer.DecoratorNotAppliedToResultOfProducerTest.arquillianBeforeClass 
org.jboss.cdi.tck.tests.definition.scope.broken.tooManyScopes.producer.field.SessionBeanProducerFieldTooManyScopesTest.arquillianBeforeClass 
org.jboss.cdi.tck.tests.definition.bean.types.illegal.BeanTypesWithIllegalTypeTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.definition.bean.broken.restricted.RestrictedProducerFieldTest.arquillianBeforeClass 
org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.VerifyValuesTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.extensions.lifecycle.events.ContainerLifeCycleEventRuntimeInvocationTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.extensions.configurators.annotatedTypeConfigurator.AnnotatedTypeConfiguratorTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.extensions.beanManager.bean.SyntheticBeanTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.extensions.alternative.metadata.AlternativeMetadataTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.extensions.producer.ProducerTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.extensions.processBean.ProcessBeanTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanICTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.enterprise.newBean.NewEnterpriseBeanTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.wildcard.ProducerFieldTypeWithWildcardTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.decorator.ProducerFieldOnDecoratorTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.array.ProducerFieldArrayTypeVariableTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.typeVariable2.RequestScopedProducerFieldWithTypeVariableTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.inject.InjectAnnotatedProducerFieldTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.interceptor.ProducerFieldOnInterceptorTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.enterprise.EnterpriseProducerFieldDefinitionTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.ProducerFieldDefinitionTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.lifecycle.ProducerFieldLifecycleTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.simple.lifecycle.SimpleBeanLifecycleTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.simple.newSimpleBean.NewSimpleBeanTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.simple.definition.broken.field.InjectedFieldAnnotatedWithProducesTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.simple.definition.SimpleBeanDefinitionTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.simple.definition.EnterpriseBeanNotDiscoveredAsManagedBeanTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.inheritance.initializer.InitializerMethodInheritanceTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.lookup.typesafe.resolution.ResolutionByTypeTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.lookup.typesafe.resolution.primitive.PrimitiveInjectionPointTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.lookup.typesafe.resolution.EnterpriseResolutionByTypeTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.lookup.modules.EnabledProducerFieldInjectionAvailability02Test.arquillianBeforeClass
org.jboss.cdi.tck.tests.lookup.dependency.resolution.AmbiguousDependencyResolutionTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.definition.scope.broken.tooManyScopes.producer.field.ProducerFieldTooManyScopesTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.enterprise.nonstatic.NonStaticFieldOfSessionBeanTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.array.ProducerFieldArrayWildcardTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.producer.field.definition.broken.typeVariable.ProducerFieldWithTypeVariableTest.arquillianBeforeClass
org.jboss.cdi.tck.tests.implementation.simple.ee.components.JavaEEComponentsTest.arquillianBeforeClass

CC @dblevins

scottmarlow · 2020-09-02T17:16:42Z

I see jakarta.xml.ws.WebServiceRef (e.g. @WebServiceRef(name = "service/HelloService"))
used in the Platform TCK test sources but not https://github.com/eclipse-ee4j/cdi-tck.

I also don't see any jakarta.xml.ws.Service in https://github.com/eclipse-ee4j/cdi-tck.

starksm64 · 2020-09-02T17:29:45Z

The classes used in the CDI TCK are jakarta.jws.* (e.g., jakarta.jws.WebService). Any arquillianBeforeClass failure is due to a deployment failure that does not even start the tests.

…

On Wed, Sep 2, 2020 at 12:16 PM Scott Marlow ***@***.***> wrote: I see jakarta.xml.ws.WebServiceRef (e.g. @WebServiceRef(name = "service/HelloService")) used in the Platform TCK test sources but not https://github.com/eclipse-ee4j/cdi-tck. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23184 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMSY4JUDIEXYIGFUI73SDZ4YTANCNFSM4QDS7UUQ> .

scottmarlow · 2020-09-02T18:21:23Z

One underlying question is if the 47 failing CDI tests were excluded (or made optional if that is possible) would we lose much more than WebService testing? I'm not sure if the failing 47 tests are actually using WebServices.

scottmarlow · 2020-09-02T18:38:24Z

I didn't check all of listed 47 tests but org.jboss.cdi.tck.tests.implementation.simple.ee.components/JavaEEComponentsTest did deploy/pass with our Full Platform standalone TCK testing.

starksm64 · 2020-09-02T18:45:08Z

Even the JavaEEComponentsTest does not use webservice apis of any kind; It only references the servlet apis. Iit would seem that the web platform integration in GF is just introducing a bad dependency that is failing the deployments.

…

On Wed, Sep 2, 2020 at 1:38 PM Scott Marlow ***@***.***> wrote: I didn't check all of listed 47 tests but org.jboss.cdi.tck.tests.implementation.simple.ee.components/JavaEEComponentsTest did deploy/pass with our Full Platform standalone TCK testing]( https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/80/testReport/org.jboss.cdi.tck.tests.implementation.simple.ee.components/JavaEEComponentsTest ). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23184 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMVI2UDPNPUGK7DTNVLSD2GK5ANCNFSM4QDS7UUQ> .

scottmarlow · 2020-09-02T18:49:41Z

Perhaps https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/web/weld-integration/src/main/java/org/glassfish/weld/services/WsInjectionHandlerImpl.java#L28 is being invoked for more than just webservice apis.

It looks like https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/web/weld-integration/src/main/java/org/glassfish/weld/services/InjectionServicesImpl.java does call ^ for non-webservices apis.

lukasj · 2020-09-02T20:54:58Z

@smillidge That is where we ended up from #23063 The basic question is whether SOAP is mandatory feature of web-profile. If it is optional then tests should be allowed to fail, I think.

lukasj · 2020-09-02T21:00:31Z

... but if I take it as it used to be supported in web-profile through JDK, then probably metro needs to be moved to the web-profile since the base is JDK8 now (thinking loud)

smillidge · 2020-09-02T21:28:36Z

@lukasj You have a better memory than me :-)

scottmarlow · 2020-09-03T18:43:34Z

@smillidge That is where we ended up from #23063 The basic question is whether SOAP is mandatory feature of web-profile. If it is optional then tests should be allowed to fail, I think.

The org.jboss.cdi.tck.tests.implementation.simple.ee.components.JavaEEComponentsTest test fails but doesn't reference SOAP.

The only jakarta.jws.* references are from https://github.com/eclipse-ee4j/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injection/non/contextual/Translator.java + https://github.com/eclipse-ee4j/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/lookup/injection/non/contextual/TranslatorEndpoint.java.

IMO, it would be good to fix the org.jboss.cdi.tck.tests.implementation.simple.ee.components.JavaEEComponentsTest failure so we have a clearer idea of how many tests are failing due to actual SOAP use.

lukasj · 2020-09-03T20:17:56Z

@scottmarlow for the record by SOAP in this particular context I'm referring to SOAP web services stack consisting of Jakarta SOAP with Attachments (jakarta.xml.soap.*), Jakarta XML Web Services Metadata (jakarta.jws.*), Jakarta XML Web Services (jakarta.xml.ws.*) and eventually also Jakarta Enterprise Web Services. It might make sense to treat Jakarta SOAP with Attachments separately as a standalone part but for the rest (which depends on Jakarta SOAP with Attachments) it should be either all or nothing.

scottmarlow · 2020-09-03T20:32:16Z

I see zero jakarta.xml.soap.* references in the https://github.com/eclipse-ee4j/cdi-tck repo.

I don't see any tests referencing jakarta.xml.ws although there is a copy of javaee_web_services_client_1_3.xsd that does via documentation.

scottmarlow · 2020-09-04T14:14:28Z

@smillidge @lukasj I started a discussion thread on https://www.eclipse.org/lists/jakartaee-tck-dev/msg00950.html regarding the jakarta.jws.WebService references in the CDI TCK, since Web Services are optional for Jakarta EE 9.

IMO, I think that #23184 should still fix the annotation scanning code failure referencing jakarta.xml.ws.WebServiceRef.

smillidge · 2020-09-04T14:29:36Z

@scottmarlow how do I reproduce the annotation scanning code failure? My understanding from https://github.com/eclipse-ee4j/jakartaee-tck/wiki/Jakarta-EE-9-TCK-results is that the Web Profile is passing the Web Profile platform TCK so the failure is not wide ranging.

scottmarlow · 2020-09-04T14:45:53Z

@smillidge from looking at following https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/web/weld-integration/src/main/java/org/glassfish/weld/services/InjectionServicesImpl.java#L181 code, it looks like we need a test that has Produces something that is not { EJB, Resource, PersistenceUnit, PersistenceContext} to reach the getWsHandler().handles() call that I think will produce the error:

       for (AnnotatedField<? super T> annotatedField : annotatedType.getFields()) {
            if ( annotatedField.isAnnotationPresent( Produces.class ) ) {
                if ( annotatedField.isAnnotationPresent( EJB.class ) ) {
                    validateEjbProducer( annotatedClass, annotatedField, injectionResources );
                } else if ( annotatedField.isAnnotationPresent( Resource.class ) ) {
                    validateResourceProducer( annotatedClass, annotatedField, injectionResources );
                } else if ( annotatedField.isAnnotationPresent( PersistenceUnit.class ) ) {
                    validateResourceClass(annotatedField, EntityManagerFactory.class);
                } else if ( annotatedField.isAnnotationPresent( PersistenceContext.class ) ) {
                    validateResourceClass(annotatedField, EntityManager.class);
                } else if ( getWsHandler().handles(annotatedField)) {
                    getWsHandler().validateWebServiceRef(annotatedField);
                }
            }
        }

scottmarlow · 2020-09-05T09:53:56Z

@smillidge as per jakartaee/cdi-tck#215 (comment), there are no JWS tests being run by the CDI TCK.

Scott produced https://download.eclipse.org/ee4j/cdi/3.0/cdi-tck-3.0.2-dist.zip for us to try, I mentioned on cdi-tck/issues/215 that we are now doing that:

Updated: https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/87 will test https://download.eclipse.org/ee4j/cdi/3.0/cdi-tck-3.0.2-dist.zip with Web Profile. I expect the same failure to occur due to what looks like an annotation scanning bug mentioned in #23184. I now believe that based on your assessment of the CDI TCK that not further failures are expected after #23184 is fixed.

https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/86 is testing https://download.eclipse.org/ee4j/cdi/3.0/cdi-tck-3.0.2-dist.zip with Full Platform, I expect this test to pass.

smillidge · 2020-09-06T16:32:17Z

Both passed :-)

scottmarlow · 2020-09-07T01:17:01Z

Both passed :-)

Sorry @smillidge , that was a typo that I later corrected. https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/87 is still failing.

smillidge · 2020-09-12T14:54:41Z

OK raised #23202 to fix the issue. It only arose on @produces on a field so took a little longer to track down a reproducer.

gurunrao · 2020-09-13T17:46:22Z

failures with latest run are 11 - https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/89/testReport/

Failures are due to "http://xmlns.jcp.org/xml/ns/javaee" in CDI tck.

Glassfish logs can be found at - https://ci.eclipse.org/jakartaee-tck/job/cditck-porting/job/master/lastSuccessfulBuild/artifact/cdi-tck-results.tar.gz

Exception stacktrack looks like below:

[2020-09-13T16:07:32.225+0000] [glassfish 6.0] [SEVERE] [NCLS-CORE-00026] [jakarta.enterprise.system.core] [tid: _ThreadID=49 _ThreadName=admin-listener(5)] [timeMillis: 1600013252225] [levelValue: 1000] [[
Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001422: Enabled alternative class org.jboss.cdi.tck.tests.alternative.broken.not.alternative.Cat (<{http://xmlns.jcp.org/xml/ns/javaee}class>org.jboss.cdi.tck.tests.alternative.broken.not.alternative.Cat</{http://xmlns.jcp.org/xml/ns/javaee}class> in file:/home/jenkins/agent/workspace/cditck-porting_master/glassfish6/glassfish/domains/domain1/applications/2dc0927fc21809841501a567c8f3bf924ec1ac7/WEB-INF/beans.xml@4) does not match any bean, or is not annotated with @Alternative or an @Alternative stereotype, or does not declare a producer annotated with @Alternative or an @Alternative stereotype
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:212)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:107)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:304)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:472)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:195)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:467)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:516)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:512)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:511)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:542)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:534)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:533)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1441)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:86)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1823)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1699)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:230)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:208)
at org.glassfish.admin.rest.utils.ResourceUtil.runCommand(ResourceUtil.java:252)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:305)
at org.glassfish.admin.rest.resources.TemplateListOfResource.post(TemplateListOfResource.java:140)
at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:124)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:167)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:79)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:469)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:391)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:253)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:232)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:680)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:356)
at org.glassfish.admin.rest.adapter.RestAdapter$2.service(RestAdapter.java:292)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:155)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:440)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:144)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:174)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:153)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:196)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:88)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:248)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:181)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:121)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:99)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:51)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:510)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:82)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:83)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:34)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:101)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001422: Enabled alternative class org.jboss.cdi.tck.tests.alternative.broken.not.alternative.Cat (<{http://xmlns.jcp.org/xml/ns/javaee}class>org.jboss.cdi.tck.tests.alternative.broken.not.alternative.Cat</{http://xmlns.jcp.org/xml/ns/javaee}class> in file:/home/jenkins/agent/workspace/cditck-porting_master/glassfish6/glassfish/domains/domain1/applications/2dc0927fc21809841501a567c8f3bf924ec1ac7/WEB-INF/beans.xml@4) does not match any bean, or is not annotated with @Alternative or an @Alternative stereotype, or does not declare a producer annotated with @Alternative or an @Alternative stereotype
at org.jboss.weld.bootstrap.Validator.validateEnabledAlternativeClasses(Validator.java:729)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:491)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:496)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:93)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:203)
... 66 more
]]

smillidge · 2020-09-14T13:52:38Z

@gurunrao does this need any action on the GlassFish side?

scottmarlow · 2020-09-14T18:50:28Z

@smillidge it looks like the GlassFish 6.0 Full Platform (latest nightly build) also fails the same tests. So, I think it is a GlassFish regression.

I ran the cditck-porting tests once more with GlassFish (Full Platform) build glassfish-6.0.0-SNAPSHOT-2020-09-06.zip and they passed (CDI test results are here).

scottmarlow · 2020-09-14T19:56:44Z

IMO, the GlassFish Full Platform cditck-porting test failures need a new issue, so created #23205 which should be actionable on the GlassFish side.

smillidge · 2020-09-15T08:44:55Z

I'm not aware of any changes in that area. Has there been an updated schema in the test suite or api as I added the schemas to GlassFish for the RC1 release back for the first release?

gurunrao · 2020-09-15T13:58:39Z

closing the issue as there is one more issue for same root cause - #23205

gurunrao added the ee9-tck label Aug 18, 2020

smillidge added this to the 6.0.0 milestone Aug 21, 2020

scottmarlow mentioned this issue Sep 5, 2020

Tests that reference optional technologies moved from Java SE 8 to Jakarta EE 9 should be removed or made optional jakartaee/cdi-tck#215

Closed

smillidge self-assigned this Sep 7, 2020

smillidge mentioned this issue Sep 12, 2020

Fix CDI deployment failures on WebProfile due to Jakarta Web Services… #23202

Merged

smillidge closed this as completed in #23202 Sep 13, 2020

gurunrao reopened this Sep 13, 2020

scottmarlow mentioned this issue Sep 14, 2020

Regression in cditck-porting tests with GlassFish 6 Full Platform (nightly build as of September 14, 2020)) #23205

Closed

gurunrao closed this as completed Sep 15, 2020

Outstanding failures in cditck-porting tests with glassfish 6 web profile. #23184

Outstanding failures in cditck-porting tests with glassfish 6 web profile. #23184

Comments

gurunrao commented Aug 18, 2020 • edited Loading

Environment Details

gurunrao commented Aug 28, 2020

scottmarlow commented Aug 31, 2020

scottmarlow commented Aug 31, 2020 • edited Loading

starksm64 commented Aug 31, 2020 via email

scottmarlow commented Aug 31, 2020

scottmarlow commented Aug 31, 2020

gurunrao commented Sep 1, 2020

lukasj commented Sep 1, 2020

lukasj commented Sep 1, 2020 • edited Loading

smillidge commented Sep 1, 2020

lukasj commented Sep 1, 2020

smillidge commented Sep 1, 2020

lukasj commented Sep 1, 2020

scottmarlow commented Sep 1, 2020

smillidge commented Sep 1, 2020

smillidge commented Sep 1, 2020

smillidge commented Sep 1, 2020

scottmarlow commented Sep 1, 2020 • edited Loading

lukasj commented Sep 1, 2020

starksm64 commented Sep 1, 2020 via email

scottmarlow commented Sep 2, 2020 • edited Loading

scottmarlow commented Sep 2, 2020 • edited Loading

starksm64 commented Sep 2, 2020 via email

scottmarlow commented Sep 2, 2020

scottmarlow commented Sep 2, 2020 • edited Loading

starksm64 commented Sep 2, 2020 via email

scottmarlow commented Sep 2, 2020 • edited Loading

lukasj commented Sep 2, 2020

lukasj commented Sep 2, 2020 • edited Loading

smillidge commented Sep 2, 2020

scottmarlow commented Sep 3, 2020

lukasj commented Sep 3, 2020 • edited Loading

scottmarlow commented Sep 3, 2020

scottmarlow commented Sep 4, 2020

smillidge commented Sep 4, 2020

scottmarlow commented Sep 4, 2020

scottmarlow commented Sep 5, 2020 • edited Loading

smillidge commented Sep 6, 2020

scottmarlow commented Sep 7, 2020 • edited Loading

smillidge commented Sep 12, 2020

gurunrao commented Sep 13, 2020 • edited Loading

Exception stacktrack looks like below:

smillidge commented Sep 14, 2020

scottmarlow commented Sep 14, 2020 • edited Loading

scottmarlow commented Sep 14, 2020 • edited Loading

smillidge commented Sep 15, 2020

gurunrao commented Sep 15, 2020

gurunrao commented Aug 18, 2020 •

edited

Loading

scottmarlow commented Aug 31, 2020 •

edited

Loading

lukasj commented Sep 1, 2020 •

edited

Loading

scottmarlow commented Sep 1, 2020 •

edited

Loading

scottmarlow commented Sep 2, 2020 •

edited

Loading

scottmarlow commented Sep 2, 2020 •

edited

Loading

scottmarlow commented Sep 2, 2020 •

edited

Loading

scottmarlow commented Sep 2, 2020 •

edited

Loading

lukasj commented Sep 2, 2020 •

edited

Loading

lukasj commented Sep 3, 2020 •

edited

Loading

scottmarlow commented Sep 5, 2020 •

edited

Loading

scottmarlow commented Sep 7, 2020 •

edited

Loading

gurunrao commented Sep 13, 2020 •

edited

Loading

scottmarlow commented Sep 14, 2020 •

edited

Loading

scottmarlow commented Sep 14, 2020 •

edited

Loading