glassfish
  1. glassfish
  2. GLASSFISH-18975

Regression: GlassFish broken on Equinox, CNF occurs for javax.transaction classes

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 4.0_b45
    • Fix Version/s: 4.1
    • Component/s: OSGi
    • Labels:
      None

      Description

      QuickLook tests have started to fail on Equinox platform starting with svn rev # 55306 where Jersey 2.0-m05-2 was integrated. See the following job for details:
      http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-continuous-ql-equinox/4449/
      This job was triggered by http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/11710/ and as per this triggering job, only jersey component was upgraded.

      To run QuickLook on Equinox, the steps are:
      mkdir glassfish3/glassfish/osgi/equinox/
      download equinox jar,
      copy the downloaded jar to above equinox dir.
      Set an environment variable GlassFish_Platform=Equinox
      Run QuickLook.

      1. cnf.txt
        78 kB
        Jakub Podlesak

        Activity

        Sanjeeb Sahoo created issue -
        Hide
        Pavel Bucek added a comment -

        mentioned job is not failing.

        I've tried to run quicklook tests on my machine, but glassfish (trunk) did not even start.

        My steps:

        • checkout fresh GF sources
        • build
        • unzip appserver/distributions/glassfish/glassfish.jar
        • mkdir -p glassfish3/glassfish/osgi/equinox/
        • cp org.eclipse.osgi_3.8.0.v20120529-1548.jar glassfish3/glassfish/osgi/equinox/
        • export GlassFish_Platform=Equinox
        • cd tests/quicklook; mvn -Dglassfish.home=/.../target/glassfish3/glassfish/ test | tee run.log

        console output:

        ...
        start-derby-unix:
        
        start-derby-windows:
        
        setOSConditions:
        
        start-server-felix:
             [echo] +-----------------------------+
             [echo] |                             |
             [echo] | S T A R T I N G   GLASSFISH |
             [echo] |       in Felix mode         |
             [echo] |                             |
             [echo] +-----------------------------+
        
        start-server-felix-unix:
        

        execution get stuck after last line. And it still says that I'm using felix, not equinox.

        Can you please provide more details about how to reproduce reported issue?

        thanks,
        Pavel

        (I'm running Mac OS X - 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 and Java "1.6.0_33")

        Show
        Pavel Bucek added a comment - mentioned job is not failing. I've tried to run quicklook tests on my machine, but glassfish (trunk) did not even start. My steps: checkout fresh GF sources build unzip appserver/distributions/glassfish/glassfish.jar mkdir -p glassfish3/glassfish/osgi/equinox/ cp org.eclipse.osgi_3.8.0.v20120529-1548.jar glassfish3/glassfish/osgi/equinox/ export GlassFish_Platform=Equinox cd tests/quicklook; mvn -Dglassfish.home=/.../target/glassfish3/glassfish/ test | tee run.log console output: ... start-derby-unix: start-derby-windows: setOSConditions: start-server-felix: [echo] +-----------------------------+ [echo] | | [echo] | S T A R T I N G GLASSFISH | [echo] | in Felix mode | [echo] | | [echo] +-----------------------------+ start-server-felix-unix: execution get stuck after last line. And it still says that I'm using felix, not equinox. Can you please provide more details about how to reproduce reported issue? thanks, Pavel (I'm running Mac OS X - 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 and Java "1.6.0_33")
        Hide
        Lukas Jungmann added a comment -

        Pavle, try to update, the failure you're seeing could be related to GLASSFISH-18976 which I fixed yesterday. Thanks.

        Show
        Lukas Jungmann added a comment - Pavle, try to update, the failure you're seeing could be related to GLASSFISH-18976 which I fixed yesterday. Thanks.
        Hide
        Sanjeeb Sahoo added a comment - - edited

        Pavel,

        I now see why you say that job is not failing. I had mentioned the continuous build job URL that triggered the failing job. Now I have updated the description with correct job URL. Sorry for the confusion. The job has been UNSTABLE since last jersey integration. See it's status is yellow and the last line in console output is UNSTABLE. The job runs QL against full and web profile. If you see the entire log, you shall see full profile QL failing the same way it failed for you. Basically, server does not start on Equinox and our pathetic QuickLook test framework continues to run tests instead of aborting early.

        That report saying "starting Felix mode" should be changed to "OSGi mode."

        You have already reproduced the issue. You don't have to run QL. Just start server and you shall see it failing to start. The behavior has not changed even after Lukas fixed the JAXB issue as part of his bug fix.

        Thanks,
        Sahoo

        Show
        Sanjeeb Sahoo added a comment - - edited Pavel, I now see why you say that job is not failing. I had mentioned the continuous build job URL that triggered the failing job. Now I have updated the description with correct job URL. Sorry for the confusion. The job has been UNSTABLE since last jersey integration. See it's status is yellow and the last line in console output is UNSTABLE. The job runs QL against full and web profile. If you see the entire log, you shall see full profile QL failing the same way it failed for you. Basically, server does not start on Equinox and our pathetic QuickLook test framework continues to run tests instead of aborting early. That report saying "starting Felix mode" should be changed to "OSGi mode." You have already reproduced the issue. You don't have to run QL. Just start server and you shall see it failing to start. The behavior has not changed even after Lukas fixed the JAXB issue as part of his bug fix. Thanks, Sahoo
        Sanjeeb Sahoo made changes -
        Field Original Value New Value
        Description QuickLook tests have started to fail on Equinox platform starting with svn rev # 55306 where Jersey 2.0-m05-2 was integrated. See the following job for details:
        http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/11710/

        To run QuickLook on Equinox, the steps are:
        mkdir glassfish3/glassfish/osgi/equinox/
        download equinox jar,
        copy the downloaded jar to above equinox dir.
        Set an environment variable GlassFish_Platform=Equinox
        Run QuickLook.
        QuickLook tests have started to fail on Equinox platform starting with svn rev # 55306 where Jersey 2.0-m05-2 was integrated. See the following job for details:
        http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-continuous-ql-equinox/4449/
        This job was triggered by http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/11710/ and as per this triggering job, only jersey component was upgraded.

        To run QuickLook on Equinox, the steps are:
        mkdir glassfish3/glassfish/osgi/equinox/
        download equinox jar,
        copy the downloaded jar to above equinox dir.
        Set an environment variable GlassFish_Platform=Equinox
        Run QuickLook.
        Hide
        Pavel Bucek added a comment -

        Sahoo,

        thanks for input and direction (you've mentioned that problem might be in jersey-media-json-jettison module. Unfortunately I wasn't able to figure out the cause of this :/ Jakub is on vacation and he should be back next week and he should be able to handle this.

        Or if you have some spare cycles and want to investigate further.. I should be able at least test proposed solution (I have my workspace ready for that, I've tested lots of Import/Export manifest headers combinations lately). Sorry for inconvenience :-/

        Pavel

        Show
        Pavel Bucek added a comment - Sahoo, thanks for input and direction (you've mentioned that problem might be in jersey-media-json-jettison module. Unfortunately I wasn't able to figure out the cause of this :/ Jakub is on vacation and he should be back next week and he should be able to handle this. Or if you have some spare cycles and want to investigate further.. I should be able at least test proposed solution (I have my workspace ready for that, I've tested lots of Import/Export manifest headers combinations lately). Sorry for inconvenience :-/ Pavel
        Hide
        Sanjeeb Sahoo added a comment -

        Thanks Pavel for the update. I don't have any cycles to work on this. I have already spent much time debugging this. Can we revert the integration until we have fixed it?

        Show
        Sanjeeb Sahoo added a comment - Thanks Pavel for the update. I don't have any cycles to work on this. I have already spent much time debugging this. Can we revert the integration until we have fixed it?
        Hide
        Pavel Bucek added a comment -

        well, that is not for me to decide :-/ that commit fixes several other issues; mainly introduces Jersey EJB integration, which is required by other teams.

        Personally - I would wait till start of next week (when Martin and Jakub will be back from vacation) with final decision.

        Show
        Pavel Bucek added a comment - well, that is not for me to decide :-/ that commit fixes several other issues; mainly introduces Jersey EJB integration, which is required by other teams. Personally - I would wait till start of next week (when Martin and Jakub will be back from vacation) with final decision.
        Hide
        Sanjeeb Sahoo added a comment -

        Since we have waited so long, I think it makes sense to wait for them to come back and have a look.

        Show
        Sanjeeb Sahoo added a comment - Since we have waited so long, I think it makes sense to wait for them to come back and have a look.
        Hide
        Jakub Podlesak added a comment -

        To me, this seems to remind an issue discussed some time ago here: http://www.eclipse.org/forums/index.php/m/901649/
        Concrete fragment not being properly resolved in this case is javax.transaction.jar. This bundle exports packages,
        which are already included in the osgi.properties:extra-system-packages. Felix console shows this conflict e.g. here (running in Felix):

        g! inspect package requirement 244
        org.glassfish.main.transaction.internal-api [244] imports packages:
        -------------------------------------------------------------------
        ...
        javax.transaction; version=0.0.0 -> org.apache.felix.framework [0]
        javax.transaction.xa; version=0.0.0 -> org.apache.felix.framework [0]
        javax.transaction; version=1.1.0 -> org.apache.felix.framework [0]
        javax.transaction.xa; version=1.1.0 -> org.apache.felix.framework [0]
        ...
        

        looking from the other end does not help neither:

        g! inspect package capability 0 
        org.apache.felix.framework [0] exports packages:
        ------------------------------------------------
        javax.transaction; version=0.0.0 imported by:
           org.jboss.weld.osgi-bundle [263]
           org.glassfish.corba.glassfish-corba-orb [99]
           org.glassfish.main.connectors.runtime [40]
           org.glassfish.main.connectors.inbound-runtime [38]
           org.glassfish.main.javax.ejb [134]
           org.glassfish.main.ejb.ejb-container [77]
           org.glassfish.main.transaction.internal-api [244]
           org.glassfish.main.orb.iiop [198]
           org.eclipse.persistence.jpa [209]
           org.glassfish.main.transaction.jta [183]
           org.glassfish.fighterfish.osgi-jta [274]
           org.glassfish.metro.webservices-osgi [258]
           org.glassfish.main.web.weld-integration [262]
           org.glassfish.main.web.glue [250]
           org.eclipse.persistence.core [208]
           org.glassfish.main.transaction.jts [184]
           org.glassfish.main.common.container-common [66]
           org.glassfish.main.ejb.ejb-full-container [78]
           org.glassfish.main.javax.resource [144]
           org.glassfish.main.connectors.internal-api [39]
        javax.transaction.xa; version=0.0.0 imported by:
           org.glassfish.main.connectors.runtime [40]
           org.glassfish.main.jms.core [175]
           org.glassfish.main.connectors.inbound-runtime [38]
           org.glassfish.main.transaction.jts [184]
           org.glassfish.main.javax.jms [140]
           org.glassfish.main.jdbc.runtime [160]
           org.glassfish.main.transaction.internal-api [244]
           org.eclipse.persistence.jpa [209]
           org.glassfish.main.transaction.jta [183]
           org.glassfish.metro.webservices-osgi [258]
           org.glassfish.main.connectors.internal-api [39]
           org.glassfish.main.javax.resource [144]
        ...
        javax.transaction; version=1.1.0 imported by:
           org.jboss.weld.osgi-bundle [263]
           org.glassfish.corba.glassfish-corba-orb [99]
           org.glassfish.main.connectors.runtime [40]
           org.glassfish.main.connectors.inbound-runtime [38]
           org.glassfish.main.javax.ejb [134]
           org.glassfish.main.ejb.ejb-container [77]
           org.glassfish.main.transaction.internal-api [244]
           org.glassfish.main.orb.iiop [198]
           org.eclipse.persistence.jpa [209]
           org.glassfish.main.transaction.jta [183]
           org.glassfish.fighterfish.osgi-jta [274]
           org.glassfish.metro.webservices-osgi [258]
           org.glassfish.main.web.weld-integration [262]
           org.glassfish.main.web.glue [250]
           org.eclipse.persistence.core [208]
           org.glassfish.main.transaction.jts [184]
           org.glassfish.main.common.container-common [66]
           org.glassfish.main.ejb.ejb-full-container [78]
           org.glassfish.main.javax.resource [144]
           org.glassfish.main.connectors.internal-api [39]
        javax.transaction.xa; version=1.1.0 imported by:
           org.glassfish.main.connectors.runtime [40]
           org.glassfish.main.jms.core [175]
           org.glassfish.main.connectors.inbound-runtime [38]
           org.glassfish.main.transaction.jts [184]
           org.glassfish.main.javax.jms [140]
           org.glassfish.main.jdbc.runtime [160]
           org.glassfish.main.transaction.internal-api [244]
           org.eclipse.persistence.jpa [209]
           org.glassfish.main.transaction.jta [183]
           org.glassfish.metro.webservices-osgi [258]
           org.glassfish.main.connectors.internal-api [39]
           org.glassfish.main.javax.resource [144]
        ...
        

        Since Jersey does not deal with the javax.transaction packages in any regard, the failure
        is IMHO caused by Jersey newly introduced bundles tweaked Equinox bundle ordering,
        which lead to the above described fragile setup manifested itself by failing.

        I tried to remove javax.transaction and javax.transaction.xa packages from the extra package list,
        but it did not help, and instead of versioned javax.transaction* packages, the system bundle
        kept showing the unversioned export only.

        Show
        Jakub Podlesak added a comment - To me, this seems to remind an issue discussed some time ago here: http://www.eclipse.org/forums/index.php/m/901649/ Concrete fragment not being properly resolved in this case is javax.transaction.jar. This bundle exports packages, which are already included in the osgi.properties:extra-system-packages. Felix console shows this conflict e.g. here (running in Felix): g! inspect package requirement 244 org.glassfish.main.transaction.internal-api [244] imports packages: ------------------------------------------------------------------- ... javax.transaction; version=0.0.0 -> org.apache.felix.framework [0] javax.transaction.xa; version=0.0.0 -> org.apache.felix.framework [0] javax.transaction; version=1.1.0 -> org.apache.felix.framework [0] javax.transaction.xa; version=1.1.0 -> org.apache.felix.framework [0] ... looking from the other end does not help neither: g! inspect package capability 0 org.apache.felix.framework [0] exports packages: ------------------------------------------------ javax.transaction; version=0.0.0 imported by: org.jboss.weld.osgi-bundle [263] org.glassfish.corba.glassfish-corba-orb [99] org.glassfish.main.connectors.runtime [40] org.glassfish.main.connectors.inbound-runtime [38] org.glassfish.main.javax.ejb [134] org.glassfish.main.ejb.ejb-container [77] org.glassfish.main.transaction.internal-api [244] org.glassfish.main.orb.iiop [198] org.eclipse.persistence.jpa [209] org.glassfish.main.transaction.jta [183] org.glassfish.fighterfish.osgi-jta [274] org.glassfish.metro.webservices-osgi [258] org.glassfish.main.web.weld-integration [262] org.glassfish.main.web.glue [250] org.eclipse.persistence.core [208] org.glassfish.main.transaction.jts [184] org.glassfish.main.common.container-common [66] org.glassfish.main.ejb.ejb-full-container [78] org.glassfish.main.javax.resource [144] org.glassfish.main.connectors.internal-api [39] javax.transaction.xa; version=0.0.0 imported by: org.glassfish.main.connectors.runtime [40] org.glassfish.main.jms.core [175] org.glassfish.main.connectors.inbound-runtime [38] org.glassfish.main.transaction.jts [184] org.glassfish.main.javax.jms [140] org.glassfish.main.jdbc.runtime [160] org.glassfish.main.transaction.internal-api [244] org.eclipse.persistence.jpa [209] org.glassfish.main.transaction.jta [183] org.glassfish.metro.webservices-osgi [258] org.glassfish.main.connectors.internal-api [39] org.glassfish.main.javax.resource [144] ... javax.transaction; version=1.1.0 imported by: org.jboss.weld.osgi-bundle [263] org.glassfish.corba.glassfish-corba-orb [99] org.glassfish.main.connectors.runtime [40] org.glassfish.main.connectors.inbound-runtime [38] org.glassfish.main.javax.ejb [134] org.glassfish.main.ejb.ejb-container [77] org.glassfish.main.transaction.internal-api [244] org.glassfish.main.orb.iiop [198] org.eclipse.persistence.jpa [209] org.glassfish.main.transaction.jta [183] org.glassfish.fighterfish.osgi-jta [274] org.glassfish.metro.webservices-osgi [258] org.glassfish.main.web.weld-integration [262] org.glassfish.main.web.glue [250] org.eclipse.persistence.core [208] org.glassfish.main.transaction.jts [184] org.glassfish.main.common.container-common [66] org.glassfish.main.ejb.ejb-full-container [78] org.glassfish.main.javax.resource [144] org.glassfish.main.connectors.internal-api [39] javax.transaction.xa; version=1.1.0 imported by: org.glassfish.main.connectors.runtime [40] org.glassfish.main.jms.core [175] org.glassfish.main.connectors.inbound-runtime [38] org.glassfish.main.transaction.jts [184] org.glassfish.main.javax.jms [140] org.glassfish.main.jdbc.runtime [160] org.glassfish.main.transaction.internal-api [244] org.eclipse.persistence.jpa [209] org.glassfish.main.transaction.jta [183] org.glassfish.metro.webservices-osgi [258] org.glassfish.main.connectors.internal-api [39] org.glassfish.main.javax.resource [144] ... Since Jersey does not deal with the javax.transaction packages in any regard, the failure is IMHO caused by Jersey newly introduced bundles tweaked Equinox bundle ordering, which lead to the above described fragile setup manifested itself by failing. I tried to remove javax.transaction and javax.transaction.xa packages from the extra package list, but it did not help, and instead of versioned javax.transaction* packages, the system bundle kept showing the unversioned export only.
        Hide
        Jakub Podlesak added a comment -

        CNF exception log, when starting osgi http service bundle in equinox

        Show
        Jakub Podlesak added a comment - CNF exception log, when starting osgi http service bundle in equinox
        Jakub Podlesak made changes -
        Attachment cnf.txt [ 50946 ]
        Hide
        Jakub Podlesak added a comment -

        updated summary and category

        Show
        Jakub Podlesak added a comment - updated summary and category
        Jakub Podlesak made changes -
        Summary Regression: GlassFish broken on Equinox due to recent Jersey integration Regression: GlassFish broken on Equinox, CNF occurs for javax.transaction classes
        Component/s OSGi [ 10641 ]
        Component/s jax-rs [ 10646 ]
        Hide
        TangYong added a comment -

        Hi Sahoo,

        I have used the recent v4 trunk snapshot(2013/01/25) and put org.eclipse.osgi_3.9.0.v20130128-202223.jar(Equinox Stable Build: KeplerM5) into glassfish/osgi/equinox, then after setting "GlassFish_Platform=Equinox" and executing "asadmin start-domain", anything is OK basiclly and glassfish/domains/domain1/osgi-cache/equinox/org.eclipse.osgi and sub-directories and related files are all generated normally. However, also noticing that in glassfish/domains/domain1/osgi-cache/equinox/, a log file is generated and its content is as following:

        !SESSION 2013-02-03 17:08:52.921 -----------------------------------------------
        eclipse.buildId=unknown
        java.version=1.7.0_09
        java.vendor=Oracle Corporation
        BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=ja_JP

        !ENTRY javax.annotation-api 4 0 2013-02-03 17:08:52.921
        !MESSAGE FrameworkEvent ERROR
        !STACK 0
        org.osgi.framework.BundleException: State change in progress for bundle "file:/D:/20130125/glassfish3/glassfish/modules/endorsed/javax.annotation-api.jar" by thread "main".
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
        at java.lang.Thread.run(Thread.java:722)
        Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
        ... 6 more
        Root exception:
        org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
        at java.lang.Thread.run(Thread.java:722)

        !ENTRY javax.annotation-api 4 0 2013-02-03 17:08:58.453
        !MESSAGE FrameworkEvent ERROR
        !STACK 0
        org.osgi.framework.BundleException: State change in progress for bundle "file:/D:/20130125/glassfish3/glassfish/modules/endorsed/javax.annotation-api.jar" by thread "main".
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:387)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.resumeBundles(PackageAdminImpl.java:317)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:556)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
        at java.lang.Thread.run(Thread.java:722)
        Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
        ... 8 more
        Root exception:
        org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:387)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.resumeBundles(PackageAdminImpl.java:317)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:556)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
        at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
        at java.lang.Thread.run(Thread.java:722)

        Then, I used "asadmin osgi lb" and found that javax.annotation API (1.1.99.b01)'s status is Active, so I can not confirm whether we can ignore the above exception.

        Thanks

        Show
        TangYong added a comment - Hi Sahoo, I have used the recent v4 trunk snapshot(2013/01/25) and put org.eclipse.osgi_3.9.0.v20130128-202223.jar(Equinox Stable Build: KeplerM5) into glassfish/osgi/equinox, then after setting "GlassFish_Platform=Equinox" and executing "asadmin start-domain", anything is OK basiclly and glassfish/domains/domain1/osgi-cache/equinox/org.eclipse.osgi and sub-directories and related files are all generated normally. However, also noticing that in glassfish/domains/domain1/osgi-cache/equinox/, a log file is generated and its content is as following: !SESSION 2013-02-03 17:08:52.921 ----------------------------------------------- eclipse.buildId=unknown java.version=1.7.0_09 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=ja_JP !ENTRY javax.annotation-api 4 0 2013-02-03 17:08:52.921 !MESSAGE FrameworkEvent ERROR !STACK 0 org.osgi.framework.BundleException: State change in progress for bundle "file:/D:/20130125/glassfish3/glassfish/modules/endorsed/javax.annotation-api.jar" by thread "main". at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174) at java.lang.Thread.run(Thread.java:722) Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException ... 6 more Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174) at java.lang.Thread.run(Thread.java:722) !ENTRY javax.annotation-api 4 0 2013-02-03 17:08:58.453 !MESSAGE FrameworkEvent ERROR !STACK 0 org.osgi.framework.BundleException: State change in progress for bundle "file:/D:/20130125/glassfish3/glassfish/modules/endorsed/javax.annotation-api.jar" by thread "main". at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:387) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.resumeBundles(PackageAdminImpl.java:317) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:556) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174) at java.lang.Thread.run(Thread.java:722) Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException ... 8 more Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:387) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.resumeBundles(PackageAdminImpl.java:317) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:556) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251) at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174) at java.lang.Thread.run(Thread.java:722) Then, I used "asadmin osgi lb" and found that javax.annotation API (1.1.99.b01)'s status is Active, so I can not confirm whether we can ignore the above exception. Thanks
        Hide
        TangYong added a comment -

        There is a point that I forgot to say: in server.log, I have found any exception or unnormal info.

        Show
        TangYong added a comment - There is a point that I forgot to say: in server.log, I have found any exception or unnormal info.
        Hide
        Sanjeeb Sahoo added a comment -

        Tang,

        Have you run QuickLook tests against Equinox? You can find the instructions to run QL using Equinox in this bug's description field.

        Sahoo

        Show
        Sanjeeb Sahoo added a comment - Tang, Have you run QuickLook tests against Equinox? You can find the instructions to run QL using Equinox in this bug's description field. Sahoo
        Hide
        TangYong added a comment - - edited

        Sahoo

        >Have you run QuickLook tests against Equinox? You can find the instructions to run QL using Equinox in this bug's
        >description field.

        I Have not still ran QuickLook tests against Equinox and today(maybe tomorrow) I will give you the result of QuickLook tests.

        Tang

        Show
        TangYong added a comment - - edited Sahoo >Have you run QuickLook tests against Equinox? You can find the instructions to run QL using Equinox in this bug's >description field. I Have not still ran QuickLook tests against Equinox and today(maybe tomorrow) I will give you the result of QuickLook tests. Tang
        Hide
        TangYong added a comment -

        BTW: needing to modify <antcall target="start-server-felix"/> and based on GlassFish_Platform condition to judge outputting "in Felix mode" or "in Equinox mode" or "Knopflerfish mode", currently this is hard-coded.

        Show
        TangYong added a comment - BTW: needing to modify <antcall target="start-server-felix"/> and based on GlassFish_Platform condition to judge outputting "in Felix mode" or "in Equinox mode" or "Knopflerfish mode", currently this is hard-coded.
        TangYong made changes -
        Comment [ Hi Sahoo,

        I have ran appserver QuickLook tests against Equinox and result is as following:

        Firstly, Pavel's scene has been re-produced occasionally: while running start-server-felix-windows, test is blocked and hanged.

        Secondly, I start to investigate appserver\tests\quicklook\build.xml, and found that this hanging is related to the following task,so I made some experiments:

        <waitfor maxwait="30" maxwaitunit="second" checkevery="500">
                <http url="http://localhost:4848/"/>
        </waitfor>

        1) removing the above task and test again

        This will cause many QL tests failed because the task is used for starting web container.

        2) changing the above task's setting as following

          <waitfor maxwait="3" maxwaitunit="minute" checkevery="500">
                <http url="http://localhost:4848/"/>
          </waitfor>

        Why I do such? After I left QL tests, and just starting domain, if I access "http://localhost:4848/", anything is OK. So I have doubted that whether because in some cases, <waitfor> task's maxwait time is too short and causes in 30 second, web container has been still in starting state.

        So, after I do 2) and test again, QL tests did not hang.

        However, this hanging also happened occasionally, so I guess that the issue is unstable.

        BTW: I also want to know whether having some better way to start web container rather than depending on <waitfor> task or not?

        Thanks
        --Tang ]
        TangYong made changes -
        Comment [ However, I also doubted whether such hanging is caused by the following:

            <exec executable="cmd" spawn="true">
                <arg value="/c"/>
                <arg value="${glassfish.home}\bin\asadmin.bat"/>
                <arg value="start-domain"/>
                <arg value="domain1"/>
            </exec>

        Because start-domain is executed in another process, I can not judge if in 30 second, domain is still in starting state, what will happen?
        ]
        TangYong made changes -
        Comment [ I am thinking that if caused by <exec> task, based on [1], whether we can add specify inputstring="" for the <exec> task because the "start-domain" forked process doesn't consume any input.

        [1]: http://ant.apache.org/faq.html#input-makes-exec-hang

        Because now in my env, the hanging also happened very occasionally.

        Thanks
        --Tang ]
        Hide
        TangYong added a comment -

        Hi sahoo,

        Please ignore my yesterday's comments because today, I made QL tests many times in my env and another machine again.

        The result is that except <antcall target="start-server-felix"/> is hard-coded, QL tests did not hang,
        ....
        testng-summary:
        [echo] [testng]
        [echo] [testng] ===============================================
        [echo] [testng] QuickLookTests
        [echo] [testng] Total tests run: 112, Failures: 1, Skips: 0
        [echo] [testng] ===============================================
        [echo] [testng]
        [INFO] Executed tasks
        [INFO] ------------------------------------------------------------------------
        [INFO] BUILD SUCCESS
        [INFO] ------------------------------------------------------------------------
        ...

        Failured test is as following and I will create a jira:

        <class name="test.admincli.RestartDomainTests">
        <test-method status="FAIL" signature="restartDomainTest()" name="restartDomainTest" duration-ms="0" started-at="2013-02-05T14:55:49Z" finished-at="2013-02-05T14:55:49Z">
        <exception class="java.lang.AssertionError">
        <message>
        <![CDATA[Restart domain failed. expected:<true> but was:<false>]]>
        </message>
        <full-stacktrace>
        <![CDATA[java.lang.AssertionError: Restart domain failed. expected:<true> but was:<false>
        at org.testng.Assert.fail(Assert.java:84)
        at org.testng.Assert.failNotEquals(Assert.java:438)
        at org.testng.Assert.assertEquals(Assert.java:108)
        at org.testng.Assert.assertEquals(Assert.java:239)
        at test.admincli.RestartDomainTests.parseTestResults(RestartDomainTests.java:90)
        at test.admincli.RestartDomainTests.restartDomainTest(RestartDomainTests.java:62)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604)
        at org.testng.internal.Invoker.invokeMethod(Invoker.java:470)
        at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:564)
        at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:830)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
        at org.testng.TestRunner.runWorkers(TestRunner.java:678)
        at org.testng.TestRunner.privateRun(TestRunner.java:624)
        at org.testng.TestRunner.run(TestRunner.java:495)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:300)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275)
        at org.testng.SuiteRunner.run(SuiteRunner.java:190)
        at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:765)
        at org.testng.TestNG.run(TestNG.java:699)
        at org.testng.TestNG.privateMain(TestNG.java:824)
        at org.testng.TestNG.main(TestNG.java:802)
        ]]>

        So, could you please run that hudson job to see whether the issue happens again or not because I have no way to run that hudson job.

        Thanks
        --Tang

        Show
        TangYong added a comment - Hi sahoo, Please ignore my yesterday's comments because today, I made QL tests many times in my env and another machine again. The result is that except <antcall target="start-server-felix"/> is hard-coded, QL tests did not hang, .... testng-summary: [echo] [testng] [echo] [testng] =============================================== [echo] [testng] QuickLookTests [echo] [testng] Total tests run: 112, Failures: 1, Skips: 0 [echo] [testng] =============================================== [echo] [testng] [INFO] Executed tasks [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ ... Failured test is as following and I will create a jira: <class name="test.admincli.RestartDomainTests"> <test-method status="FAIL" signature="restartDomainTest()" name="restartDomainTest" duration-ms="0" started-at="2013-02-05T14:55:49Z" finished-at="2013-02-05T14:55:49Z"> <exception class="java.lang.AssertionError"> <message> <![CDATA [Restart domain failed. expected:<true> but was:<false>] ]> </message> <full-stacktrace> <![CDATA[java.lang.AssertionError: Restart domain failed. expected:<true> but was:<false> at org.testng.Assert.fail(Assert.java:84) at org.testng.Assert.failNotEquals(Assert.java:438) at org.testng.Assert.assertEquals(Assert.java:108) at org.testng.Assert.assertEquals(Assert.java:239) at test.admincli.RestartDomainTests.parseTestResults(RestartDomainTests.java:90) at test.admincli.RestartDomainTests.restartDomainTest(RestartDomainTests.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604) at org.testng.internal.Invoker.invokeMethod(Invoker.java:470) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:564) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:830) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:678) at org.testng.TestRunner.privateRun(TestRunner.java:624) at org.testng.TestRunner.run(TestRunner.java:495) at org.testng.SuiteRunner.runTest(SuiteRunner.java:300) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275) at org.testng.SuiteRunner.run(SuiteRunner.java:190) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792) at org.testng.TestNG.runSuitesLocally(TestNG.java:765) at org.testng.TestNG.run(TestNG.java:699) at org.testng.TestNG.privateMain(TestNG.java:824) at org.testng.TestNG.main(TestNG.java:802) ]]> So, could you please run that hudson job to see whether the issue happens again or not because I have no way to run that hudson job. Thanks --Tang
        Tom Mueller made changes -
        Assignee Sanjeeb Sahoo [ ss141213 ]
        Sanjeeb Sahoo made changes -
        Fix Version/s 4.0_b82_EE7MS7 [ 16111 ]
        Hide
        Sanjeeb Sahoo added a comment -

        Deferring to 4.0.1 due to lack of time and priority.

        Show
        Sanjeeb Sahoo added a comment - Deferring to 4.0.1 due to lack of time and priority.
        Sanjeeb Sahoo made changes -
        Fix Version/s 4.0.1 [ 16061 ]
        Fix Version/s 4.0_b82_EE7MS7 [ 16111 ]
        Hide
        tuomas_kiviaho added a comment -

        @Jakub I started to have similar problems with JTA packages on another project when I switched from
        org.glassfish.main.transaction:javax.transaction:3.1.2.2 over to javax.transaction:javax.transaction-api:1.2

        http://wiki.osgi.org/wiki/System_Bundle has a compact explanation of the differentiating manifest headers (Require-Bundle and Fragment-Host) pointing to system.bundle

        Show
        tuomas_kiviaho added a comment - @Jakub I started to have similar problems with JTA packages on another project when I switched from org.glassfish.main.transaction:javax.transaction:3.1.2.2 over to javax.transaction:javax.transaction-api:1.2 http://wiki.osgi.org/wiki/System_Bundle has a compact explanation of the differentiating manifest headers (Require-Bundle and Fragment-Host) pointing to system.bundle
        Romain Grécourt made changes -
        Fix Version/s 4.1 [ 16387 ]
        Fix Version/s 4.0.1 [ 16061 ]

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: