Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] Improving efficiency of TCK jobs and switching to build/run TCKs with https://www.eclipse.org/downloads/download.php?file=/ee4j/glassfish/glassfish-6.0.0-SNAPSHOT-nightly.zip
FYI https://github.com/eclipse-ee4j/glassfish/issues/23120 was opened by the GlassFish team to "bundle api and impl as separate jars", which should this issue! 

Scott

On 7/14/20 12:39 PM, Scott Marlow wrote:

Hi,
https://github.com/eclipse-ee4j/el-ri/issues/130 is for the below GlassFish exception that occurs with Jakarta Expression Language 4.0.0-RC2 but not 4.0.0-RC1.  This appears to be a blocker for EE 9.
I mentioned in the above el-ri/issues#130 link that I think RC1 is from January of 2020 and RC2 is from June of 2020, so it isn't clear as to which el-ri API RC2 change is causing the below failure.
Any additional insight as to why the below exception occurs with EL-RI API RC2?
FYI, the exception is also copied to https://gist.github.com/scottmarlow/1dacd0f2d08c8e129b1702de0e74ddd3 which is linked from https://github.com/eclipse-ee4j/el-ri/issues/130. 

Thanks,
Scott
On Thu, Jul 2, 2020 at 9:22 PM Scott Marlow <smarlow@xxxxxxxxxx <mailto:smarlow@xxxxxxxxxx>> wrote: 



    On Thu, Jul 2, 2020 at 11:22 AM Alwin Joseph
    <alwin.joseph@xxxxxxxxxx <mailto:alwin.joseph@xxxxxxxxxx>> wrote:


        On 02/07/20 7:46 am, Scott Marlow wrote:

        Hi,

        The build/run TCK jobs [1][2][3] are now updated to use the
        nightly GlassFish build.


        Hi Scott, I updated the same to
        https://download.eclipse.org/ee4j/glassfish/glassfish-6.0.0-SNAPSHOT-nightly.zip.
        This should be the same as you were referring.


    The both do seem the same to me as well (I downloaded both and they
    both contain files with today's date).

        But the glassfish start domain gave the below exception after
        using this new bundle. Maybe if this nightly glassfish can
        possibly have issues we could fall back to M1 release?

    Or we could try
    https://ci.eclipse.org/jakartaee-tck/job/build-glassfish/lastSuccessfulBuild/artifact/appserver/distributions/glassfish/target/glassfish.zip,
    which is from July 1.  Perhaps we should add a Jenkins job parameter
    for GF_BUNDLE_URL, so that we can more easily try different builds
    of GlassFish if needed.

    Scott

              [exec] Error starting domain domain1.
              [exec] The server exited prematurely with exit code 1.
              [exec] Before it died, it produced the following output:
              [exec]
              [exec] Launching GlassFish on Felix platform
              [exec] Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime@221ee7b8 in service registry.
              [exec] Completed shutdown of GlassFish runtime
              [exec] We are in non-embedded mode, so org.glassfish.main.core.glassfish [103] has nothing to do...

              [exec] Exception in thread "main" java.lang.reflect.InvocationTargetException
              [exec] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              [exec] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              [exec] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              [exec] 	at java.lang.reflect.Method.invoke(Method.java:498)
              [exec] 	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:73)
              [exec] 	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:30)
              [exec] Caused by: A MultiException has 2 exceptions.  They are:
              [exec] 1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.jdbc.config [165]], State = [NEW]
              [exec] 2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor(
              [exec] 	implementation=org.glassfish.jdbc.config.JdbcConnectionPoolInjector
              [exec] 	name=jdbc-connection-pool
              [exec] Caused by: com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.jdbc.config [165]], State = [NEW]
              [exec] 	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:193)
              [exec] 	at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:54)
              [exec] 	at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2234)
              [exec] 	... 31 more
              [exec] Caused by: org.osgi.framework.BundleException: Unable to resolve org.glassfish.main.jdbc.config [165](R 165.0): missing requirement [org.glassfish.main.jdbc.config [165](R 165.0)] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.connectors.config.validators)(version>=6.0.0)(!(version>=7.0.0))) [caused by: Unable to resolve org.glassfish.main.connectors.internal-api [46](R 46.0): missing requirement [org.glassfish.main.connectors.internal-api [46](R 46.0)] osgi.wiring.package; (&(osgi.wiring.package=com.sun.enterprise.deployment.runtime.connector)(version>=6.0.0)(!(version>=7.0.0))) [caused by: Unable to resolve org.glassfish.main.deployment.dol [70](R 70.0): missing requirement [org.glassfish.main.deployment.dol [70](R 70.0)] osgi.wiring.package; (&(osgi.wiring.package=jakarta.enterprise.inject.spi)(version>=3.0.0)(!(version>=4.0.0))) [caused by: Unable to resolve jakarta.enterprise.cdi-api [133](R 133.0): missing requirement [jakarta.enterprise.cdi-api [133](R 133.0)] osgi.wiring.package; (&(osgi.wiring.package=jakarta.el)(version>=4.0.0))]]] Unresolved requirements: [[org.glassfish.main.jdbc.config [165](R 165.0)] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.connectors.config.validators)(version>=6.0.0)(!(version>=7.0.0)))]



        Regarding efficiency of TCK jobs, we saw a hint that our TCK
        jobs may not be using correct memory settings.  The hint is
        that increasing the JNLP memory size from 2176Mi to 3Gi [4],
        allowed the Full Platform TCK run to completion.  Previously,
        for several test runs the JPA tests (running only with the
        appmanagedNoTx vehicle) would unexpectedly fail to deploy
        correctly.  This sounds to me like we could be experiencing
        thrashing of some sort.

        How can we can properly ensure that for all launched JVM
        processes (especially long running ones), we don't use more
        memory than is allowed by the OS (vm/container) that we are
        running on.

        So, how can we get OS level statistics for the jakartaee-tck
        Jenkins jobs?  It likely involves contacting
        cbi-dev@xxxxxxxxxxx <mailto:cbi-dev@xxxxxxxxxxx> which is fine
        but I wanted to ask here first, to raise awareness and get
        advice.

        Scott

        [1]
        https://ci.eclipse.org/jakartaee-tck/job/standalonetck-nightly-build-run-master

        [2]
        https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-build-master

        [3]
        https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-run-master


        [4] https://github.com/eclipse-ee4j/jakartaee-tck/pull/347

        _______________________________________________
        jakartaee-tck-dev mailing list
        jakartaee-tck-dev@xxxxxxxxxxx
        <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
        To unsubscribe from this list, visit
        https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

        _______________________________________________
        jakartaee-tck-dev mailing list
        jakartaee-tck-dev@xxxxxxxxxxx <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
        To unsubscribe from this list, visit
        https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top