[jboss-osgi-issues] [JBoss JIRA] (JBOSGI-802) WAR deployments do not always manage to resolve OSGi dependencies during startup

[Hannu Lahtinen (JIRA)]

     [ https://issues.jboss.org/browse/JBOSGI-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hannu Lahtinen updated JBOSGI-802:
----------------------------------
    Description: 
Originally discussion in thread: https://developer.jboss.org/thread/272591

Setup:
- webapp.war has "Dependencies: deployment.OSGI_BUNDLE_A" defined in its MANIFEST.MF.
- deployment.OSGI_BUNDLE_A has "Import-Package: foo.bar.osgi.bundle.b.path" in its MANIFEST.mf.
- Standalone.xml has
-- automatic deployment-scanner enabled 
-- OSGi bundles are eagerly started
-- org.osgi.framework.startlevel.beginning is 2
-- OSGI_BUNDLE_A defined as a OSGi subsystem capability with startlevel=1. 
-- OSGI_BUNDLE_B defined as a OSGi subsystem capability with startlevel=1. 
- webapp.war is placed in deployments folder.

When Wildfly is started deployment-scanner starts to deploy webapp.war and OSGi subsystem starts to install bundles and solve dependencies. OSGi subsystem logs on INFO level that bundle A and bundle B have been installed. At this point an ERROR is logged that informs that webapp.war failed to start due to an ModuleNotFoundException. deployment.OSGI_BUNDLE_B was not found. After this OSGi bundle A and B are started and Wildfly finishes starting up. 
At this point we can remove webapp.war.failed from deployments folder. Deployment scanner starts deploying webapp.war again. This time deployment succeeds without issues. All dependencies are resolved and system works without issues.
This bug does not occur consistently. Sometimes webapp.war is deployed without issues when Wildfly is started. Also we can start Wildfly with the argument "-Djboss.msc.max.container.threads=1" and Wildfly always starts up cleanly (albeit slowly).

This is highly simplified description of the scenario in which this bug occurs. In reality there are multiple WARs that are dependent on multiple OSGi bundles and those are dependent on multiple other OSGi bundles.

Note that this has been mostly tested in an environment where every startup is on a "fresh" Wildfly installation. tmp and data directories have not been created and standalone.xml does not contain <deployment> -tags.

  was:
Setup:
- webapp.war has "Dependencies: deployment.OSGI_BUNDLE_A" defined in its MANIFEST.MF.
- deployment.OSGI_BUNDLE_A has "Import-Package: foo.bar.osgi.bundle.b.path" in its MANIFEST.mf.
- Standalone.xml has
-- automatic deployment-scanner enabled 
-- OSGi bundles are eagerly started
-- org.osgi.framework.startlevel.beginning is 2
-- OSGI_BUNDLE_A defined as a OSGi subsystem capability with startlevel=1. 
-- OSGI_BUNDLE_B defined as a OSGi subsystem capability with startlevel=1. 
- webapp.war is placed in deployments folder.

When Wildfly is started deployment-scanner starts to deploy webapp.war and OSGi subsystem starts to install bundles and solve dependencies. OSGi subsystem logs on INFO level that bundle A and bundle B have been installed. At this point an ERROR is logged that informs that webapp.war failed to start due to an ModuleNotFoundException. deployment.OSGI_BUNDLE_B was not found. After this OSGi bundle A and B are started and Wildfly finishes starting up. 
At this point we can remove webapp.war.failed from deployments folder. Deployment scanner starts deploying webapp.war again. This time deployment succeeds without issues. All dependencies are resolved and system works without issues.
This bug does not occur consistently. Sometimes webapp.war is deployed without issues when Wildfly is started. Also we can start Wildfly with the argument "-Djboss.msc.max.container.threads=1" and Wildfly always starts up cleanly (albeit slowly).

This is highly simplified description of the scenario in which this bug occurs. In reality there are multiple WARs that are dependent on multiple OSGi bundles and those are dependent on multiple other OSGi bundles.

Note that this has been mostly tested in an environment where every startup is on a "fresh" Wildfly installation. tmp and data directories have not been created and standalone.xml does not contain <deployment> -tags.



> WAR deployments do not always manage to resolve OSGi dependencies during startup
> --------------------------------------------------------------------------------
>
>                 Key: JBOSGI-802
>                 URL: https://issues.jboss.org/browse/JBOSGI-802
>             Project: JBoss OSGi
>          Issue Type: Bug
>         Environment: Wildfly 10.1, JBoss Modules 1.5.2.Final, JBoss OSGi 2.5.2 Final
>            Reporter: Hannu Lahtinen
>            Assignee: Arcadiy Ivanov
>
> Originally discussion in thread: https://developer.jboss.org/thread/272591
> Setup:
> - webapp.war has "Dependencies: deployment.OSGI_BUNDLE_A" defined in its MANIFEST.MF.
> - deployment.OSGI_BUNDLE_A has "Import-Package: foo.bar.osgi.bundle.b.path" in its MANIFEST.mf.
> - Standalone.xml has
> -- automatic deployment-scanner enabled 
> -- OSGi bundles are eagerly started
> -- org.osgi.framework.startlevel.beginning is 2
> -- OSGI_BUNDLE_A defined as a OSGi subsystem capability with startlevel=1. 
> -- OSGI_BUNDLE_B defined as a OSGi subsystem capability with startlevel=1. 
> - webapp.war is placed in deployments folder.
> When Wildfly is started deployment-scanner starts to deploy webapp.war and OSGi subsystem starts to install bundles and solve dependencies. OSGi subsystem logs on INFO level that bundle A and bundle B have been installed. At this point an ERROR is logged that informs that webapp.war failed to start due to an ModuleNotFoundException. deployment.OSGI_BUNDLE_B was not found. After this OSGi bundle A and B are started and Wildfly finishes starting up. 
> At this point we can remove webapp.war.failed from deployments folder. Deployment scanner starts deploying webapp.war again. This time deployment succeeds without issues. All dependencies are resolved and system works without issues.
> This bug does not occur consistently. Sometimes webapp.war is deployed without issues when Wildfly is started. Also we can start Wildfly with the argument "-Djboss.msc.max.container.threads=1" and Wildfly always starts up cleanly (albeit slowly).
> This is highly simplified description of the scenario in which this bug occurs. In reality there are multiple WARs that are dependent on multiple OSGi bundles and those are dependent on multiple other OSGi bundles.
> Note that this has been mostly tested in an environment where every startup is on a "fresh" Wildfly installation. tmp and data directories have not been created and standalone.xml does not contain <deployment> -tags.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)