[
https://issues.jboss.org/browse/JBOSGI-802?page=com.atlassian.jira.plugin...
]
Arcadiy Ivanov commented on JBOSGI-802:
---------------------------------------
[~hannu1] FYI, I started JBOSGI-803 to upgrade to WildFly 10.1 and there are unit test
failures in the repository processing with 2.5.2. It'll be fixed as part of
JBOSGI-803, but you may be bumping into 10.1 issue.
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
Fix For: JBossOSGI 2.5.3
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)