Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cu-dev] [glassfish-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0
Thanks Petr for sharing information about Payara implementation.

I'm not sure whether somebody not affiliated with Payara can just take the code from Payara and apply it to GlassFish, because it's copyrighted to Payara licenced under CDDL. It would be best if Payara donated the code themselves so that everything is legally OK. Another option might be that somebody from Payara approves the PR and explicitly states there that Payara allows donating the code under the EPL license and under Payara copyright. That would be also OK with the Eclipse Contributor Agreement.

Scott, it's not easy to answer your question "How likely is it that someone just needs to merge the Payara changes?" Provided that Payara will at least allow me to use their code I can try porting Payara integration to GlassFish but I'm not sure whether it would be completely straightforward or there will be some non-trivial challenges. The amount of code-changes is pretty big, although most of the touched code should be similar or even same between Payara and GlassFish. I'll try to port Payara code and will let you know whether it's easy or not.

Steve, Petr, or somebody else from the Concurrency team, could you please release the Concurrency-ri version 3.0.0-RC1 to a public maven repository, so that GlassFish can use it as a dependency? I see that Petr's changes are already in the 3.0.0-RC1 tag but I don't see this version neither in Maven Central nor in the Eclipse maven repo.

All the best,
Ondro

po 6. 6. 2022 o 21:51 Scott Marlow <smarlow@xxxxxxxxxx> napísal(a):


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.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 .

 

 

 

 

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
_______________________________________________
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
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

Back to the top