| Re: [cu-dev] [glassfish-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0 |
BCC: GlassFish-dev mailing list...
How likely is it that someone just needs to merge the Payara
changes from https://github.com/payara/Payara/pull/5767
into their local GlassFish development tree and create a GlassFish
pull request from that?
Is it normal for code changes to flow from https://github.com/payara/Payara to GlassFish or does GlassFish need to avoid copying code from the Payara project?
Scott
On 6/6/22 12:13 PM, Petr Aubrecht wrote:
Hi all,
if it helps, there are three parts done on Payara to implement Concurrency 3.0:
- Concurreny 3.0 RI: https://github.com/eclipse-ee4j/concurrency-ri/pull/50
- Integration with Payara (should be very similar to Glassfish): https://github.com/payara/Payara/pull/5767
How likely is it that someone just needs to merge the Payara changes from https://github.com/payara/Payara/pull/5767 into their local GlassFish development tree and create a GlassFish pull request from that?
Scott
- TCK runner: https://github.com/payara/jakartaee-10-tck-runners/tree/main/concurrent-tck
The runner has excludes the tests, which I challenged.
Petr
On 6/6/22 17:13, Ondrej Mihályi wrote:
Hi, Gurunandan, Steve and others.
No work has been done on GF to pass the Concurrency TCK yet. I'm in touch with Arjan Tijms and David Matejcek, currently the most active GlassFish committers, and they are busy with passing TCKs for other specifications and have no plans to start working on Concurrency in the near future. That's unfortunate, because if GF doesn't pass the whole Jakarta EE TCK soon, I'm afraid that it will delay the release date of the whole Jakarta EE 10, unless another implementation can pass the TCK soon.
Probably not many of you know that I left Payara a few weeks ago. Therefore I'm not representing Payara anymore. However, I'd still like to contribute to GF to pass the Concurrency TCK but my time and also knowledge of the Concurrency implementation are limited. On top of that, it looks like integrating the new version of the Eclipse concurrency-ri component into GlassFish is a lot of work, judging from the amount of code changes in Payara Server it required to integrate it. I'm afraid that only Arjan and David are not able to do it in a reasonable time, even if I help them, as all of us are working on GlassFish only in our free time.
Therefore I'd like to ask if there's anybody willing to help with GlassFish to pass the Concurrency TCK?
Some help is necessary so that GlassFish can pass the Jakarta EE TCK soon and thus Jakarta EE 10 can be released without a significant delay. With the current course of action it's very likely that Jakarta EE 10 release will be significantly delayed until there's another compatible implementation other than GlassFish.
All the best,Ondro Mihalyi
po 6. 6. 2022 o 16:26 Gurunandan Rao <gurunandan.rao@xxxxxxxxxx> napísal(a):
_______________________________________________+ 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.0For 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.warCaused 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 listcu-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________ 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