Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [glassfish-dev] [cu-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0

We will look internally to see how long it would take us to backport Payara changes upstream to GlassFish.

 

As I’ve also said before there’s no guarantee that the work is trivial. IMHO it would be simpler just to reimplement the glue code and support for the concurrency deployment annotations in the GlassFIsh project. We have already completed and pushed upstream the whole of the Concurrency RI project work.

 

Even if we can free up the time to do the deployment work it may still delay Jakarta EE 10 release.

 

Steve

 

From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Ondrej Mihályi
Sent: 08 June 2022 11:16
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] [cu-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0

 

Hi Steve,

 

I'm only concerned about Jakarta EE 10 timeline. I brought up the fact that GlassFish isn't going to pass the TCK without Payara's help soon only because it threatens the Jakarta EE 10 release. As far as I'm concerned, I would be equally happy if Payara Server was able to pass the Jakarta EE 10 TCK soon and could be used as a CI to release Jakarta EE 10 instead of using GlassFish as the first CI.

I understand that Payara doesn't use Eclipse GlassFish directly for their business and I don't expect that Payara would favor GlassFish before their own products. Payara still benefits from Eclipse GlassFish source code directly or indirectly and I thought it would be beneficial for Payara if the Eclipse GlassFish project keeps moving forward and keeps up. However, my sole concern now is that all this impacts the Jakarta EE 10 timeline, especially since Jakarta EE 10 has already been delayed by several months.

 

I'd be thankful for any contribution to GlassFish from Payara, or anybody else indeed, if it helps with releasing Jakarta EE 10 soon.

 

All the best,

Ondro

 

P.S. If I didn't clarify it before, I no longer work for Payara and the opinions expressed on this email thread are my personal opinions of an individual Jakarta EE community member.

 

st 8. 6. 2022 o 11:30 Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> napísal(a):

Ondro,

 

Given that Payara can’t just copy files across, as I have explained, you are now demanding with zero notice that the Payara team drop everything and reimplement our server changes into GlassFish ASAP with subsequent delay to our implementation timelines.

 

My understanding is that there are a fair number of companies that create, sell and support direct derivatives of Eclipse GlassFish, which Payara does not, surely they can build the necessary deployment code in time.

 

Given the overall risk of delay to the Jakarta EE release I will look internally to see what our team can do, as we have done on all the previous releases, to pull the GlassFish timeline out of the fire.

 

Steve

 

 

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Ondrej Mihályi
Sent: 08 June 2022 09:57
To: cu developer discussions <cu-dev@xxxxxxxxxxx>; glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] [glassfish-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0

 

I wasn't asking about the original Oracle GlassFish code but about the code modified in Payara Server by Payara. Payara should be able to donate their code modifications to Eclipse GlassFish under any license without Oracle's approval, or am I wrong?

 

We're now talking about a huge risk that Jakarta EE 10 will be delayed again if GlassFish doesn't pass the Concurrency TCK. There's nobody who could implement concurrency support in such a short time so that EE 10 can be released at the end of June with at least one CI. The only option is that Payara donates their modifications done in Payara. Otherwise GlassFish isn't going to pass the TCK in time.

 

It's also possible that another CI is used to release EE 10. However, I think that only Payara Server has a potential to pass it though, with all the optional specifications. AFAIK, other implementations don't even aspire to provide all optional features and most of them are still far away from supporting even the required features of the Full profile. How far is Payara Server with passing the EE 10 TCK? Could it be used as a CI for EE 10 soon?

 

I'm also sending this to the Platform mailing list because I think the whole Jakarta EE 10 release is at stake right now.

 

All the best,

Ondro

 

 

ut 7. 6. 2022 o 16:59 Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> napísal(a):

Payara can’t relicense original Oracle GlassFish code from CDDL + GPL to EPLv2 + GPL as we aren’t the original licensor so we can’t just copy source files up.

 

Steve

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Ondrej Mihályi
Sent: 07 June 2022 15:51
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] [glassfish-dev] [External] : Re: glassfish-7 nightly bundle with concurrency TCK 3.0

 

Hi Steve,

 

If GlassFish project copies code from Payara, what's your preferred method to do that? Would Payara agree with re-licensing the code under EPL + GPL?

 

Or would the code need to be copied only under the GPL license or CDDL + GPL? In the latter case I think that the GlassFish team would have to agree on changing the declared project license statement, which now says that all the code is under EPL + GPL.

 

Ondro

 

ut 7. 6. 2022 o 16:23 Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> napísal(a):

Hi Scott,

 

<TLDR>

GlassFish doesn’t need to avoid copying code from Payara but it needs to be done correctly for licensing and technical considerations.

</TLDR >

 

Longer explanation

 

From a licensing consideration (IANAL).

Payara code, like the original Oracle GlassFish code it is forked from, is open source dual licensed CDDL / GPLv2 with Classpath Exception. Eclipse GlassFish is EPLv2 and GPL+CPE. You therefore can’t just directly copy source files across without relicensing them or electing to single license them with the mutually compatible GPL+CPE. This is also true for the Payara team, where the source file originates from the original GlassFish source as we are not the original licensor of those files.

 

From a technical perspective – Payara forked from Oracle GlassFish Community 6 years ago and has had a LOT of development work since then and may have diverged significantly from the Eclipse GlassFish source code which has had minimal substantive changes other than those required for Jakarta EE compatibility for many years. Changes do flow both ways within the GlassFish project though less so from Payara Core repo to GlassFish core repo as they are significantly divergent and GlassFish core repo is not directly upstream for Payara. So it may be possible to copy a bunch of files over and they work on the other hand it may not work.

 

HTH

 

Steve

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Marlow
Sent: 07 June 2022 14:47
To: cu developer discussions <cu-dev@xxxxxxxxxxx>; Petr Aubrecht <aubrecht@xxxxxxxxxxxx>
Subject: 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 3:51 PM, Scott Marlow wrote:

 

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

_______________________________________________
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

Back to the top