glassfish
  1. glassfish
  2. GLASSFISH-18514

CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2
    • Fix Version/s: future release
    • Component/s: cdi, OSGi-JavaEE
    • Labels:
      None

      Description

      CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled.

      Please see attached server.log

      You can see after the server has started I manually redeployed the WAB and CDI was enabled that time.

      If I do not redeploy the WAB CDI is not enabled and I get NPE when trying to access a JAX-RS resource that @Inject's a @OSGiService(dynamic=true).

      1. server.log
        110 kB
        aaronjwhiteside

        Activity

        Hide
        aaronjwhiteside added a comment -

        So I think I tracked down the issue.

        The org.glassfish.fighterfish.osgi-cdi bundle which provides the cdi support for WAB's has a run level of 2. However any bundle that is deployed under <domain>autodeploy/bundles always has a run level of 1.

        So when you start glassfish that already has bundles under autodeploy/bundles and no osgi-cache (to tell it the deploy order, if you deployed something after the server was already started) it'll start the osgi-cdi bundle after the WAB bundle. And thus CDI support is never enabled for WAB's.

        I tried adding

        felix.fileinstall.start.level=4 
        

        to glassfish3/glassfish/config/osgi.properties

        But the bundles deployed from <domain>/autodeploy/bundles still seem to start in runlevel 1.

        Show
        aaronjwhiteside added a comment - So I think I tracked down the issue. The org.glassfish.fighterfish.osgi-cdi bundle which provides the cdi support for WAB's has a run level of 2. However any bundle that is deployed under <domain>autodeploy/bundles always has a run level of 1. So when you start glassfish that already has bundles under autodeploy/bundles and no osgi-cache (to tell it the deploy order, if you deployed something after the server was already started) it'll start the osgi-cdi bundle after the WAB bundle. And thus CDI support is never enabled for WAB's. I tried adding felix.fileinstall.start.level=4 to glassfish3/glassfish/config/osgi.properties But the bundles deployed from <domain>/autodeploy/bundles still seem to start in runlevel 1.
        Show
        aaronjwhiteside added a comment - For reference: http://felix.apache.org/site/apache-felix-file-install.html
        Hide
        aaronjwhiteside added a comment -

        OK so it turns out that all the felix.fileinstall* properties in osgi.properties are totally ignored and should probably be removed.

        The real file doing the configuration is:

        glassfish3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg
        

        However if I add the line:

        felix.fileinstall.start.level=4
        

        to this file, it still does not set the run level for bundles under autodeploy/bundles, they still start at run level one.

        However I do get a log message printed out:

        [#|2012-03-15T20:08:20.322-0400|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName=Thread-2;|felix.fileinstall.start.level set, but not a int: 4 |#]
        

        Which is interesting, apparently 4 really isn't an int.. I guess this is an ERROR even though it says INFO.. or maybe a WARN as it seems to have ignored the config.

        Without this fixed OSGi is pretty much useless.

        Show
        aaronjwhiteside added a comment - OK so it turns out that all the felix.fileinstall* properties in osgi.properties are totally ignored and should probably be removed. The real file doing the configuration is: glassfish3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg However if I add the line: felix.fileinstall.start.level=4 to this file, it still does not set the run level for bundles under autodeploy/bundles, they still start at run level one. However I do get a log message printed out: [#|2012-03-15T20:08:20.322-0400|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName= Thread -2;|felix.fileinstall.start.level set, but not a int : 4 |#] Which is interesting, apparently 4 really isn't an int.. I guess this is an ERROR even though it says INFO.. or maybe a WARN as it seems to have ignored the config. Without this fixed OSGi is pretty much useless.
        Hide
        aaronjwhiteside added a comment -

        Fixing this issue will probably fix another bug I reported too.

        http://java.net/jira/browse/GLASSFISH-18508

        And a bunch of other random weird stuff I was pulling my hair out over..

        Show
        aaronjwhiteside added a comment - Fixing this issue will probably fix another bug I reported too. http://java.net/jira/browse/GLASSFISH-18508 And a bunch of other random weird stuff I was pulling my hair out over..
        Hide
        aaronjwhiteside added a comment -

        OK so after more investigation it turns out you have to set:

        felix.fileinstall.start.level=4
        

        in osgi.properties AND org.apache.felix.fileinstall-autodeploy-bundles.cfg or less it does not get picked up. This is probably a bug too.

        (and obviously, even through I omitted it you must set glassfish.osgi.start.level.final=4 in osgi.properties too).

        So now I can see that the start level of my WAB bundle is really 4, however CDI still does NOT get enabled. I have to remove the war and redeploy it again, after the server has started for CDI to kicked in.

        So my assumption that the start level's were the issue seems to be moot, however having a start level of 1 for the bundles under autodeploy/bundles and a start level of 2 for most of glassfish's osgi to jee integration bundles is still a bug. The bundles under autodeploy/bundles should start in start level 4.

        So the question is now, if not start levels, what is causing CDI to not load and required a redeploy of the war to be enabled???

        Show
        aaronjwhiteside added a comment - OK so after more investigation it turns out you have to set: felix.fileinstall.start.level=4 in osgi.properties AND org.apache.felix.fileinstall-autodeploy-bundles.cfg or less it does not get picked up. This is probably a bug too. (and obviously, even through I omitted it you must set glassfish.osgi.start.level.final=4 in osgi.properties too). So now I can see that the start level of my WAB bundle is really 4, however CDI still does NOT get enabled. I have to remove the war and redeploy it again, after the server has started for CDI to kicked in. So my assumption that the start level's were the issue seems to be moot, however having a start level of 1 for the bundles under autodeploy/bundles and a start level of 2 for most of glassfish's osgi to jee integration bundles is still a bug. The bundles under autodeploy/bundles should start in start level 4. So the question is now, if not start levels, what is causing CDI to not load and required a redeploy of the war to be enabled???
        Hide
        Sanjeeb Sahoo added a comment -

        No, I don't understand some of your observations. This is how things are supposed to work:

        no osgi-cache:
        fileinstall is started at start level 2 and it is configured to start after modules/autostart/,
        which means first time (same as no osgi cache) the server starts, fileinstall will come into effect
        after all bundles in modules/autostart/. Once fileinstall is started, it will then go onto deploy
        autodeploy/bundles/. Now, let's say one such bundle is a WAB that uses CDI.
        Since osgi-cdi is already installed,when the WAB is processed, osgi-cdi will process the WAB as well.

        Let's stop the server and restart. Upon restart, the WAB is started at start level 1 which means it is
        started before osgi-web-container and osgi-cdi are started. But, the WAB processing is deferred until
        osgi-web-container is started. When server reaches start level 2, osgi-web-container is started and it
        processes the WAB. It does not matter whether osgi-cdi is active or not. It only has to be in INSTALLED
        state for it to be useful. So, when the WAB is processed by osgi-web-container, osgi-cdi will be used
        as well.

        So, I don't see a case why osgi-cdi is not used in your case. Could you supply a test case with instructions?
        I tried a WAB+CDI test case and could not reproduce.

        A note about fileinstall start level:
        The bundles in autodeploy/bundles/ are started at start level 1. This seems like
        a bad configuration. They should have start level matching that of fileinstall, which is 2. I will
        open a separate issue to do this. But, I can't see it affecting any functionality now.

        To change the start level of bundles in autodeploy/bundles, edit osgi.properties file.
        modules/autostart/o.a.f.fileinstall-autodeploy-bundles.cfg is not used any more.
        If you set a start level higher than 2, then you must also configure the server to change the
        start level to that value. Currently, server sets final start level to 2 using the property:
        glassfish.osgi.start.level.final=2
        Change it to the higher value, else your bundles in autodeploy/bundles will never get activated.

        Show
        Sanjeeb Sahoo added a comment - No, I don't understand some of your observations. This is how things are supposed to work: no osgi-cache: fileinstall is started at start level 2 and it is configured to start after modules/autostart/, which means first time (same as no osgi cache) the server starts, fileinstall will come into effect after all bundles in modules/autostart/. Once fileinstall is started, it will then go onto deploy autodeploy/bundles/. Now, let's say one such bundle is a WAB that uses CDI. Since osgi-cdi is already installed,when the WAB is processed, osgi-cdi will process the WAB as well. Let's stop the server and restart. Upon restart, the WAB is started at start level 1 which means it is started before osgi-web-container and osgi-cdi are started. But, the WAB processing is deferred until osgi-web-container is started. When server reaches start level 2, osgi-web-container is started and it processes the WAB. It does not matter whether osgi-cdi is active or not. It only has to be in INSTALLED state for it to be useful. So, when the WAB is processed by osgi-web-container, osgi-cdi will be used as well. So, I don't see a case why osgi-cdi is not used in your case. Could you supply a test case with instructions? I tried a WAB+CDI test case and could not reproduce. A note about fileinstall start level: The bundles in autodeploy/bundles/ are started at start level 1. This seems like a bad configuration. They should have start level matching that of fileinstall, which is 2. I will open a separate issue to do this. But, I can't see it affecting any functionality now. To change the start level of bundles in autodeploy/bundles, edit osgi.properties file. modules/autostart/o.a.f.fileinstall-autodeploy-bundles.cfg is not used any more. If you set a start level higher than 2, then you must also configure the server to change the start level to that value. Currently, server sets final start level to 2 using the property: glassfish.osgi.start.level.final=2 Change it to the higher value, else your bundles in autodeploy/bundles will never get activated.
        Hide
        aaronjwhiteside added a comment -

        After clearing the osgi-cache (I keep forgetting) CDI now works, so changing the start level fixed the issue.

        Can this please be fixed in the next release?

        Show
        aaronjwhiteside added a comment - After clearing the osgi-cache (I keep forgetting) CDI now works, so changing the start level fixed the issue. Can this please be fixed in the next release?
        Hide
        Sanjeeb Sahoo added a comment -

        What you want to be fixed? start level of bundles/autodeploy/? Sure it can be (could you file an issue under osgi category?), but, as I mentioned earlier, I don't understand why you had to change start level. Are you really sure things didn't work for you as is? I would love to understand it better. Do you have a reproducible test case?

        Show
        Sanjeeb Sahoo added a comment - What you want to be fixed? start level of bundles/autodeploy/? Sure it can be (could you file an issue under osgi category?), but, as I mentioned earlier, I don't understand why you had to change start level. Are you really sure things didn't work for you as is? I would love to understand it better. Do you have a reproducible test case?
        Hide
        tlcksnyder added a comment -

        not attempting to fix without a reproducible test case, or better description of reproduction steps.

        Show
        tlcksnyder added a comment - not attempting to fix without a reproducible test case, or better description of reproduction steps.

          People

          • Assignee:
            Sivakumar Thyagarajan
            Reporter:
            aaronjwhiteside
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: