Re: [glassfish-dev] [cu-dev] [External] : Re: glassfish-7 nightly bundle

[Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>]

+ glassfish-dev

---

From: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Sent: 06 June 2022 19:47
To: cu developer discussions <cu-dev@xxxxxxxxxxx>; Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>
Subject: RE: [cu-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0

 

For the NameNotFoundExceptions – there is new functionality whereby the Compatible Implementation needs to deploy resources based on new annotations. This will need implementing in the core GlassFish deployment code, I don’t know if it has been done. We (Payara team) updated the glassfish concurrent-ri implementation project however this library doesn’t cover deployment of resources.

 

Steve

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Marlow
Sent: 06 June 2022 14:39
To: cu developer discussions <cu-dev@xxxxxxxxxxx>; Gurunandan Rao <gurunandan.rao@xxxxxxxxxx>
Subject: Re: [cu-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0

 

https://github.com/jakartaee/concurrency/issues/227 is a TCK challenge for removing duplicate classes.  Does the issue identify the same classes or are there additional duplicate classes we are having trouble with?

 

Scott

 

On 6/6/22 8:55 AM, Gurunandan Rao wrote:

There is no improvement with glassfish remote vs managed.

 

I have attached some of the findings from a glassfish managed run with logs, including server.log and con.log(concurrency TCK run log).

 

 

Following concurrency TCK wars are deployed on glassfish at runner maven target directory:

_DEFAULT__AbortedExceptionTests_0f5bb170-7854-42e5-8a3a-f49fa0806e63.war

_DEFAULT__APITests_b39523e6-2e88-462e-8254-4c26fd4e83d3.war

_DEFAULT__ContextPropagationServletTests.Deserialize_ContextPropagationServletTests.Deserialize.war

_DEFAULT__ContextPropagationServletTests.Proxy_ContextPropagationServletTests.Proxy.war

_DEFAULT__ContextPropagationServletTests.Work_ContextPropagationServletTests.Work.war

_DEFAULT__ContextServiceTests_0048d6dc-7c21-4a8a-a5f8-aa5e5ca2c86b.war

_DEFAULT__ContextServletTests_91a670cf-54e5-4e12-8365-7f919de9d87f.war

_DEFAULT__ContextTests_9a9b7af4-1d70-441f-84d0-683d28c19a45.ear

_DEFAULT__DeploymentDescriptorTests_DeploymentDescriptorTests.ear

_DEFAULT__ForbiddenAPIServletTests_84a83d54-7e61-46a1-966f-335cfe652ccd.war

_DEFAULT__ForbiddenAPITests_test-2e613806-7766-4c8f-ad2a-506bdd067042.war

_DEFAULT__ForbiddenAPITests_test-ec6d7abf-5414-41fc-87b2-b84215cacb05.war

_DEFAULT__InheritedAPITests_53c87a40-8632-4593-b879-ea133aa82048.war

_DEFAULT__InheritedAPITests_inheritedapi.ear

_DEFAULT__LastExecutionTests_b547164b-1b9b-4017-b899-8994778117aa.war

_DEFAULT__ManageableThreadTests_c3470197-35c3-4639-84a6-9f0820e4be76.war

_DEFAULT__ManagedExecutorDefinitionTests_ManagedExecutorDefinitionTests.ear

_DEFAULT__ManagedExecutorsTests_4e3dd552-f62d-4fc7-8a45-1c2da1666ae8.war

_DEFAULT__ManagedScheduledExecutorDefinitionTests_ManagedScheduledExecutorDefinitionTests.ear

_DEFAULT__ManagedScheduledExecutorServiceTests_e048de7d-3db9-4842-83d9-14f939261631.war

_DEFAULT__ManagedTaskListenerTests_b70f7a2f-b753-451a-9856-97306a7a7ad2.war

_DEFAULT__ManagedTaskTests_34d11c97-ba4a-4cc6-9dca-df8cc8e95de0.war

_DEFAULT__ManagedThreadFactoryDefinitionTests_ManagedThreadFactoryDefinitionTests.ear

_DEFAULT__SecurityTests_security.ear

_DEFAULT__SignatureTests_signatureTest.war

_DEFAULT__SkippedExceptionTests_02f0a783-9868-4be6-b881-3cd8c3507d84.war

_DEFAULT__TransactionTests_42916b7f-0ed5-44ae-83a6-9c4bcd700a97.war

_DEFAULT__TransactionTests_7b566bcc-b6ef-4fdb-af21-2a58f8bc1c27.war

_DEFAULT__TransactionTests_c0667655-fb79-4964-b361-682ce0e1974a.war

_DEFAULT__TriggerTests_983a9d31-eb10-4026-9a32-e5c997f2abd6.war

 

Also multiple exception with following stack-trace at GF server.log:

 

=====================

 

 

Caused by: java.lang.LinkageError: loader java.net.URLClassLoader @6e28bb87 attempted duplicate class definition for ee.jakarta.tck.concurrent.common.counter.__CounterRemote_Remote_DynamicStub. (ee.jakarta.tck.concurrent.common.counter.__CounterRemote_Remote_DynamicStub is in unnamed module of loader java.net.URLClassLoader @6e28bb87, parent loader com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader @534243e4)

at java.base/java.lang.ClassLoader.defineClass1(Native Method)

at java.base/java.lang.System$2.defineClass(System.java:2131)

 

 

=====================

 

Error while binding JNDI name ee.jakarta.tck.concurrent.common.counter.CounterRemote for EJB CounterSingleton

at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1385)

at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:165)

at com.sun.ejb.containers.StatelessContainerFactory.createContainer(StatelessContainerFactory.java:39)

at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:198)

 

 

=====================

 

 Caught exception attempting to call test method testAsyncCompletionStageMSE on servlet ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.resourcedef.ManagedScheduledExecutorDefinitionServlet

javax.naming.NamingException: Lookup failed for 'java:app/concurrent/ScheduledExecutorA' 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.NameNotFoundException: No object bound to name java:app/concurrent/ScheduledExecutorA]

at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:467)

at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:414)

at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at java.naming/javax.naming.InitialContext.doLookup(InitialContext.java:282)

at ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.resourcedef.ManagedScheduledExecutorDefinitionServlet.testAsyncCompletionStageMSE(

 

 

=====================

 

javax.naming.NamingException: Lookup failed for 'java:comp/concurrent/ContextC' 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.NameNotFoundException: No object bound to name java:comp/concurrent/ContextC]

at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:467)

at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:414)

at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at java.naming/javax.naming.InitialContext.doLookup(InitialContext.java:282)

at ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.resourcedef.ReqBean.lookUpAContextService(ReqBean.java:55)

... 36 more

 

 

=====================

 

 Caught exception attempting to call test method testCompletedFutureMSE on servlet ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.resourcedef.ManagedScheduledExecutorDefinitionServlet

javax.naming.NamingException: Lookup failed for 'java:module/concurrent/ScheduledExecutorB' 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.NameNotFoundException: No object bound to name java:module/concurrent/ScheduledExecutorB]

at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:467)

at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:414)

at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at java.naming/javax.naming.InitialContext.doLookup(InitialContext.java:282)

at ee.jakarta.tck.concurrent.spec.ManagedScheduledExecutorService.resourcedef.ManagedScheduledExecutorDefinitionServlet.testCompletedFutureMSE(ManagedScheduledExecutorDefinitionServlet.java:204)

 

=====================

 

regards,

Guru

---

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Kyle Aure <kylejaure@xxxxxxxxx>
Sent: 04 June 2022 01:17
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: [External] : Re: [cu-dev] glassfish-7 nightly bundle with concurrency TCK 3.0

 

Hello Guru,

 

It looks like the issue with the glassfish build is that Arquillian was unable to deploy the applications to the server.

Here is an example of the error errors:

org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy test-c70c0de9-addc-483d-a9d8-603df8b5c5b4.war

Caused by: org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientException: jakarta.ws.rs.ProcessingException: java.net.ConnectException: Connection refused (Connection refused)

Caused by: jakarta.ws.rs.ProcessingException: java.net.ConnectException: Connection refused (Connection refused)

Caused by: java.net.ConnectException: Connection refused (Connection refused)

This likely means the server wasn't started or wasn't configured to allow Arquillian to deploy applications. 

I see that for the Concurrency TCK you are using the Glassfish Managed container for Arquillian, whereas for the JBatch TCK you are using the Glassfish Remote container for Arquillian.

It looks like Arquillian was able to deploy one application for (39f8e721-08d9-4880-bb3f-52f8cfbc9ecd) for the test package ee.jakarta.tck.concurrent.api.ManagedExecutors

After that test, no other deployments succeeded.

Perhaps the managed container for Glassfish does not support multiple deployments?

I'm not quite sure of the specifics about how Glassfish containers work, but perhaps it would be worthwhile to try switching from Managed to Remote?

 

Hope that helps,

Kyle Jon Aure

 

 

On Fri, Jun 3, 2022 at 9:22 AM Gurunandan Rao <gurunandan.rao@xxxxxxxxxx> wrote:

Please Note: The failures are blocker for Platform TCK 10.0 ballot, as per discussion at TCK call.

 

regards,

Guru

---

From: Gurunandan Rao
Sent: 02 June 2022 11:20
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: glassfish-7 nightly bundle with concurrency TCK 3.0

 

For glassfish-7 nightly bundle run with concurrency TCK 3.0, we have TCK test results with 31 failures, 446 skipped.

 

We have followed instructions with concurrency TCK user guide for creation of glassfish-7 runners and source for glassfish-7 concurrency runners is available at https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/glassfish-runner/concurrency-tck .

 

CI run of concurrency TCK can be found at https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-concurrency-tck-glassfish-run/15/testReport/

 

Test run logs link - https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-concurrency-tck-glassfish-run/15/artifact/glassfish-runner/concurrency-tck/target/surefire-reports/TestSuite.txt

 

Glassfish logs link - https://ci.eclipse.org/jakartaee-tck/job/10/job/jakarta-concurrency-tck-glassfish-run/15/artifact/glassfish-runner/concurrency-tck/target/glassfish7/glassfish/domains/domain1/logs/server.log

 

Please let us know, if there is need of configuration change at Aquilian or runner for passing of GF 7 with concurrency TCK.

 

 

regards,

Guru

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________

cu-dev mailing list

cu-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev