[JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles using the deployments folder
5:13 a.m.
Paul Illingworth created AS7-5951:
-------------------------------------
Summary: Cannot reliably deploy OSGi host and fragment bundles using the
deployments folder
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:59 a.m.
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler updated AS7-5951:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
Cannot reliably deploy OSGi host and fragment bundles using the
deployments folder
----------------------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:18 a.m.
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler commented on AS7-5951:
-------------------------------------
With bundle hot-deployment to the deployments folder their is no notion of set. The
deployments race independently and it is possible that the host resolves before the
fragment is installed in which case the fragment would not attach.
On server restart however, there is a guarantee that all bundle deployments get installed
before any of them resolves. Is this not the case?
We also support nested deployments - when you put your host+fragments in an EAR this
should also work
Cannot reliably deploy OSGi host and fragment bundles using the
deployments folder
----------------------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:20 a.m.
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler edited comment on AS7-5951 at 11/15/12 8:18 AM:
---------------------------------------------------------------
With bundle hot-deployment to the deployments folder their is no notion of set. The
deployments race independently and it is possible that the host resolves before the
fragment is installed in which case the fragment would not attach.
On server restart however, there is a guarantee that all bundle deployments get installed
before any of them resolves. Is this not the case?
We also support nested deployments. When you put your host+fragments in an EAR this should
also work
was (Author: thomas.diesler):
With bundle hot-deployment to the deployments folder their is no notion of set. The
deployments race independently and it is possible that the host resolves before the
fragment is installed in which case the fragment would not attach.
On server restart however, there is a guarantee that all bundle deployments get installed
before any of them resolves. Is this not the case?
We also support nested deployments - when you put your host+fragments in an EAR this
should also work
Cannot reliably deploy OSGi host and fragment bundles using the
deployments folder
----------------------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:05 a.m.
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth commented on AS7-5951:
---------------------------------------
I understand that hot deployment would be independent but I am seeing the problem on
server restart. I have turned on logging for the deployer/resolver etc and I have seen the
host resolving before the fragment is installed.
This is the log from the a case where guice-servlet was attached but not guice-persist.
Like I said, the build I am using is from a few weeks ago. I plan on moving to the latest
version later on today.
{noformat}
2012-11-15 09:59:59,622 TRACE [org.jboss.as.osgi](MSC service thread 1-3) Starting:
service jboss.osgi.as.module.registration in mode ON_DEMAND
2012-11-15 09:59:59,622 TRACE [org.jboss.osgi.resolver](MSC service thread 1-1) Resource
identifier for com.google.inject.servlet: [null,72]
2012-11-15 09:59:59,622 TRACE [org.jboss.osgi.resolver](MSC service thread 1-2) Resource
identifier for com.google.inject.persist: [null,73]
2012-11-15 09:59:59,622 TRACE [org.jboss.osgi.resolver](MSC service thread 1-4) Resource
identifier for com.google.inject: [null,74]
2012-11-15 09:59:59,622 TRACE [org.jboss.osgi.framework](MSC service thread 1-1)
ServiceTracker transition to UP: service
jboss.deployment.unit."guice-servlet-3.0.jar".REGISTER
2012-11-15 09:59:59,622 DEBUG [org.jboss.as.osgi](MSC service thread 1-1) ServiceStarted:
service jboss.deployment.unit."guice-servlet-3.0.jar".REGISTER
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) new
RevisionContent: com.google.inject.servlet-72-0-0
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-4)
ServiceTracker transition to UP: service
jboss.deployment.unit."guice-3.0.jar".REGISTER
2012-11-15 09:59:59,638 DEBUG [org.jboss.as.osgi](MSC service thread 1-4) ServiceStarted:
service jboss.deployment.unit."guice-3.0.jar".REGISTER
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Aquire
framework lock
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) new
RevisionContent: com.google.inject-74-0-0
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1) Install
resource: FragmentBundleRevision[com.google.inject.servlet:3.0.0]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1)
XIdentityCapability[atts={osgi.identity=com.google.inject.servlet, type=osgi.fragment,
version=3.0.0},[anonymous]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.servlet,
version=1.3},[com.google.inject.servlet:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1)
XHostRequirement[atts={osgi.wiring.host=com.google.inject},[com.google.inject.servlet:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1)
XPackageRequirement[atts={osgi.wiring.package=javax.servlet},[com.google.inject.servlet:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1)
XPackageRequirement[atts={osgi.wiring.package=javax.servlet.http},[com.google.inject.servlet:3.0.0]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Release
framework lock
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1)
changeState: com.google.inject.servlet:3.0.0 -> INSTALLED
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.deployment](MSC service thread 1-1) Invoke:
[org.jboss.as.osgi.web.WebContextLifecycleInterceptor,order=1000] with state INSTALLED on
guice-servlet-3.0.jar
2012-11-15 09:59:59,638 INFO [org.jboss.osgi.framework](MSC service thread 1-1)
JBOSGI011001: Bundle installed: com.google.inject.servlet:3.0.0
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) Aquire
framework lock
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3) Install
resource: HostBundleRevision[com.google.inject:3.0.0]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1)
ServiceTracker transition to UP: service
jboss.deployment.unit."guice-persist-3.0.jar".REGISTER
2012-11-15 09:59:59,638 DEBUG [org.jboss.as.osgi](MSC service thread 1-1) ServiceStarted:
service jboss.deployment.unit."guice-persist-3.0.jar".REGISTER
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1)
ServiceTracker complete: org.jboss.as.osgi.service.InitialDeploymentTracker
2012-11-15 09:59:59,638 DEBUG [org.jboss.as.osgi](MSC service thread 1-1) Initial
deployments complete
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XIdentityCapability[atts={osgi.identity=com.google.inject, type=osgi.bundle,
version=3.0.0},[anonymous]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.as.osgi](MSC service thread 1-1)
addPhaseCompleteService: service jboss.osgi.as.initial.deployments.COMPLETE
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XResourceCapability[atts={osgi.wiring.bundle=com.google.inject,
bundle-version=3.0.0},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XHostCapability[atts={osgi.wiring.host=com.google.inject,
bundle-version=3.0.0},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.matcher,
version=1.3},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.name,
version=1.3},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-2)
ServiceTracker complete: org.jboss.osgi.framework.spi.BootstrapBundlesInstall$1
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.spi,
version=1.3},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.binder,
version=1.3},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.util,
version=1.3},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageCapability[atts={osgi.wiring.package=com.google.inject,
version=1.3},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageRequirement[atts={osgi.wiring.package=javax.inject},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageRequirement[atts={osgi.wiring.package=org.aopalliance.intercept},[com.google.inject:3.0.0]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) Release
framework lock
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
changeState: com.google.inject:3.0.0 -> INSTALLED
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.deployment](MSC service thread 1-3) Invoke:
[org.jboss.as.osgi.web.WebContextLifecycleInterceptor,order=1000] with state INSTALLED on
guice-3.0.jar
2012-11-15 09:59:59,638 INFO [org.jboss.osgi.framework](MSC service thread 1-3)
JBOSGI011001: Bundle installed: com.google.inject:3.0.0
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) Aquire
framework lock
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3) Resolve:
[], []
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3) Resolution
result: 0
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) Release
framework lock
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
ServiceTracker complete: org.jboss.osgi.framework.spi.BootstrapBundlesResolve$1
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.framework](MSC service thread 1-1) OSGi
Framework initialized
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Aquire
framework lock
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1) Resolve:
[SystemBundleRevision[system.bundle:0.0.0]], []
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-1) Resolution
result: 0
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Release
framework lock
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-1)
changeState: system.bundle:0.0.0 -> ACTIVE
2012-11-15 09:59:59,638 INFO [org.jboss.osgi.framework](MSC service thread 1-1)
JBOSGI011011: Starting bundles for start level: 1
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.framework](MSC service thread 1-3) Adding
attachable fragments: [FragmentBundleRevision[com.google.inject.servlet:3.0.0]]
2012-11-15 09:59:59,638 DEBUG [org.jboss.as.osgi](MSC service thread 1-3) Resolve:
guice-3.0.jar
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) Aquire
framework lock
2012-11-15 09:59:59,638 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3) Resolve:
[HostBundleRevision[com.google.inject:3.0.0]],
[FragmentBundleRevision[com.google.inject.servlet:3.0.0]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Env
provides:
XPackageRequirement[atts={osgi.wiring.package=javax.inject},[com.google.inject:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=javax.inject},[system.bundle:0.0.0]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Ctx
provides:
XPackageRequirement[atts={osgi.wiring.package=javax.inject},[com.google.inject:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=javax.inject},[system.bundle:0.0.0]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Env
provides:
XPackageRequirement[atts={osgi.wiring.package=org.aopalliance.intercept},[com.google.inject:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=org.aopalliance.intercept,
version=1.0.0},[com.springsource.org.aopalliance:1.0.0]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Ctx
provides:
XPackageRequirement[atts={osgi.wiring.package=org.aopalliance.intercept},[com.google.inject:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=org.aopalliance.intercept,
version=1.0.0},[com.springsource.org.aopalliance:1.0.0]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Env
provides:
XHostRequirement[atts={osgi.wiring.host=com.google.inject},[com.google.inject.servlet:3.0.0]]
=> [XHostCapability[atts={osgi.wiring.host=com.google.inject,
bundle-version=3.0.0},[com.google.inject:3.0.0]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Ctx
provides:
XHostRequirement[atts={osgi.wiring.host=com.google.inject},[com.google.inject.servlet:3.0.0]]
=> [XHostCapability[atts={osgi.wiring.host=com.google.inject,
bundle-version=3.0.0},[com.google.inject:3.0.0]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Env
provides:
XPackageRequirement[atts={osgi.wiring.package=javax.servlet},[com.google.inject.servlet:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=javax.servlet,
version=2.5},[org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Ctx
provides:
XPackageRequirement[atts={osgi.wiring.package=javax.servlet},[com.google.inject.servlet:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=javax.servlet,
version=2.5},[org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Env
provides:
XPackageRequirement[atts={osgi.wiring.package=javax.servlet.http},[com.google.inject.servlet:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=javax.servlet.http,
version=2.5},dirs={uses=javax.servlet},[org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final]]]
2012-11-15 09:59:59,638 TRACE [org.jboss.osgi.resolver](MSC service thread 1-3) Ctx
provides:
XPackageRequirement[atts={osgi.wiring.package=javax.servlet.http},[com.google.inject.servlet:3.0.0]]
=> [XPackageCapability[atts={osgi.wiring.package=javax.servlet.http,
version=2.5},dirs={uses=javax.servlet},[org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final]]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3) Resolution
result: 2
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
HostBundleRevision[com.google.inject:3.0.0]: 4 wires
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageRequirement[atts={osgi.wiring.package=javax.inject},[com.google.inject:3.0.0]]
-> [SystemBundleRevision[system.bundle:0.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageRequirement[atts={osgi.wiring.package=org.aopalliance.intercept},[com.google.inject:3.0.0]]
-> [HostBundleRevision[com.springsource.org.aopalliance:1.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageRequirement[atts={osgi.wiring.package=javax.servlet},[com.google.inject.servlet:3.0.0]]
->
[HostBundleRevision[org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XPackageRequirement[atts={osgi.wiring.package=javax.servlet.http},[com.google.inject.servlet:3.0.0]]
->
[HostBundleRevision[org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
FragmentBundleRevision[com.google.inject.servlet:3.0.0]: 1 wires
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-3)
XHostRequirement[atts={osgi.wiring.host=com.google.inject},[com.google.inject.servlet:3.0.0]]
-> [HostBundleRevision[com.google.inject:3.0.0]]
2012-11-15 09:59:59,653 WARN [org.jboss.as.server.deployment](MSC service thread 1-2)
JBAS015967: Cannot install reflection index for unresolved bundle: guice-servlet-3.0.jar
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
createModuleDependencySpec: [id=jbosgi.framework:main,if=in
{javax/inject},ef=Reject,loader=FrameworkModuleLoader,optional=false]
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
createModuleDependencySpec: [id=deployment.com.springsource.org.aopalliance:1.0.0,if=in
{org/aopalliance/intercept},ef=Reject,loader=ModuleLoaderIntegration,optional=false]
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
createModuleDependencySpec:
[id=deployment.org.jboss.spec.javax.servlet.jboss-servlet-api_2.5_spec:1.0.1.Final,if=in
{javax/servlet,
javax/servlet/http},ef=Reject,loader=ModuleLoaderIntegration,optional=false]
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
createLocalDependencySpec: [if=not in {javax/servlet, org/aopalliance/intercept,
javax/inject, javax/servlet/http},ef=Accept,rif=Accept,ref=Accept,cf=Accept]
2012-11-15 09:59:59,653 TRACE [org.jboss.as.osgi](MSC service thread 1-3) Add module spec
to loader: deployment.guice-3.0.jar:main
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Aquire
START lock on: org.apache.felix.configadmin:1.2.8
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.framework](MSC service thread 1-1) Starting
bundle: org.apache.felix.configadmin:1.2.8
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Aquire
RESOLVE lock on: org.apache.felix.configadmin:1.2.8
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
changeState: com.google.inject:3.0.0 -> RESOLVED
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Release
RESOLVE lock on: org.apache.felix.configadmin:1.2.8
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.deployment](MSC service thread 1-3) Invoke:
[org.jboss.as.osgi.web.WebContextLifecycleInterceptor,order=1000] with state RESOLVED on
guice-3.0.jar
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Release
START lock on: org.apache.felix.configadmin:1.2.8
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3)
changeState: com.google.inject.servlet:3.0.0 -> RESOLVED
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.deployment](MSC service thread 1-3) Invoke:
[org.jboss.as.osgi.web.WebContextLifecycleInterceptor,order=1000] with state RESOLVED on
guice-servlet-3.0.jar
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) Release
framework lock
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-3) Set mode
ACTIVE on service: service
jbosgi.bundle.74."com.google.inject"."3.0.0".RESOLVED
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-1) Aquire
START lock on: org.apache.felix.configadmin:1.2.8
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.framework](MSC service thread 1-3) Cannot
set mode ACTIVE on non-existing service: service
jbosgi.bundle.72."com.google.inject.servlet"."3.0.0".RESOLVED
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-4) new
RevisionContent: com.google.inject.persist-73-0-0
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-4) Aquire
framework lock
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4) Install
resource: FragmentBundleRevision[com.google.inject.persist:3.0.0]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XIdentityCapability[atts={osgi.identity=com.google.inject.persist, type=osgi.fragment,
version=3.0.0},[anonymous]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.persist.finder,
version=1.3},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.persist.jpa,
version=1.3},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XPackageCapability[atts={osgi.wiring.package=com.google.inject.persist,
version=1.3},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XHostRequirement[atts={osgi.wiring.host=com.google.inject},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XPackageRequirement[atts={osgi.wiring.package=javax.inject},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XPackageRequirement[atts={osgi.wiring.package=javax.persistence},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XPackageRequirement[atts={osgi.wiring.package=javax.servlet},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 DEBUG [org.jboss.osgi.resolver](MSC service thread 1-4)
XPackageRequirement[atts={osgi.wiring.package=org.aopalliance.intercept},[com.google.inject.persist:3.0.0]]
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-4) Release
framework lock
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.framework](MSC service thread 1-4)
changeState: com.google.inject.persist:3.0.0 -> INSTALLED
2012-11-15 09:59:59,653 TRACE [org.jboss.osgi.deployment](MSC service thread 1-4) Invoke:
[org.jboss.as.osgi.web.WebContextLifecycleInterceptor,order=1000] with state INSTALLED on
guice-persist-3.0.jar
2012-11-15 09:59:59,653 INFO [org.jboss.osgi.framework](MSC service thread 1-4)
JBOSGI011001: Bundle installed: com.google.inject.persist:3.0.0
2012-11-15 09:59:59,653 WARN [org.jboss.as.server.deployment](MSC service thread 1-4)
JBAS015967: Cannot install reflection index for unresolved bundle: guice-persist-3.0.jar
{noformat}
Cannot reliably deploy OSGi host and fragment bundles using the
deployments folder
----------------------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:57 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler updated AS7-5951:
--------------------------------
Summary: Cannot reliably deploy OSGi host and fragment bundles on server restart
(was: Cannot reliably deploy OSGi host and fragment bundles using the deployments folder)
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:08 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth commented on AS7-5951:
---------------------------------------
I have now tried an EAR. This has the same issue - sometimes it's ok and sometimes
it's not.
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:33 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth edited comment on AS7-5951 at 11/20/12 9:32 AM:
-----------------------------------------------------------------
I have pulled ed2bc551a55ec6a8167a8657cbb5d8abc6e07748 from Github.
To my installation I have added pax-web and the felix web console so I can see what is
going on. These are in the bundles folder structure and exposed as capabilities.
Adding in all my applications bundles into the deployments folder and starting up I am
getting the same as before. Sometimes the fragments attach sometimes they don't.
Deploying guice in an EAR doesn't improve matters.
Removing all my applications bundles and just having guice, guice-server and guice-persist
jars in the deployments folder these correctly attached every time (6 out of 6). Wrapping
up the three guice jars in an EAR and having just the EAR in the deployments folder again
it started 6 out of 6 times.
was (Author: pillingworth):
I have pulled ed2bc551a55ec6a8167a8657cbb5d8abc6e07748 from Github.
To my installation I have added pax-web and the felix we console so I can see what is
going on. These are in the bundles folder structure and exposed as capabilities.
Adding in all my applications bundles into the deployments folder and starting up I am
getting the same as before. Sometimes the fragments attach sometimes they don't.
Deploying guice in an EAR doesn't improve matters.
Removing all my applications bundles and just having guice, guice-server and guice-persist
jars in the deployments folder these correctly attached every time (6 out of 6). Wrapping
up the three guice jars in an EAR and having just the EAR in the deployments folder again
it started 6 out of 6 times.
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:33 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth commented on AS7-5951:
---------------------------------------
I have pulled ed2bc551a55ec6a8167a8657cbb5d8abc6e07748 from Github.
To my installation I have added pax-web and the felix we console so I can see what is
going on. These are in the bundles folder structure and exposed as capabilities.
Adding in all my applications bundles into the deployments folder and starting up I am
getting the same as before. Sometimes the fragments attach sometimes they don't.
Deploying guice in an EAR doesn't improve matters.
Removing all my applications bundles and just having guice, guice-server and guice-persist
jars in the deployments folder these correctly attached every time (6 out of 6). Wrapping
up the three guice jars in an EAR and having just the EAR in the deployments folder again
it started 6 out of 6 times.
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:07 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth updated AS7-5951:
----------------------------------
Attachment: this_one_failed.txt
This is a trace of the startup when the fragments do not attach (according to the felix
web console). There is also a JBAS011910: Cannot resolve requirements WARN at the end.
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
Attachments: this_one_failed.txt
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:09 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth edited comment on AS7-5951 at 11/20/12 10:08 AM:
------------------------------------------------------------------
"this_one_failed.txt" attachment is a trace of the startup when the fragments do
not attach (according to the felix web console). There is also a JBAS011910: Cannot
resolve requirements WARN at the end.
was (Author: pillingworth):
This is a trace of the startup when the fragments do not attach (according to the
felix web console). There is also a JBAS011910: Cannot resolve requirements WARN at the
end.
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
Attachments: this_one_failed.txt, this_one_worked.txt
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:09 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth updated AS7-5951:
----------------------------------
Attachment: this_one_worked.txt
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
Attachments: this_one_failed.txt, this_one_worked.txt
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:11 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth edited comment on AS7-5951 at 11/20/12 10:09 AM:
------------------------------------------------------------------
"this_one_failed.txt" attachment is a trace of the startup when the fragments do
not attach (according to the felix web console). There is also a JBAS011910: Cannot
resolve requirements WARN at the end.
"this_one_worked.txt" attachment is a trace of the startup when the fragments
did attach.
was (Author: pillingworth):
"this_one_failed.txt" attachment is a trace of the startup when the
fragments do not attach (according to the felix web console). There is also a JBAS011910:
Cannot resolve requirements WARN at the end.
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
Attachments: this_one_failed.txt, this_one_worked.txt
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:58 a.m.
New subject: [JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
[
https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler reopened AS7-5951:
---------------------------------
Cannot reliably deploy OSGi host and fragment bundles on server
restart
-----------------------------------------------------------------------
Key: AS7-5951
URL: https://issues.jboss.org/browse/AS7-5951
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
Attachments: this_one_failed.txt, this_one_worked.txt
If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist
(fragment) into the "deployments" folder then the there is no guarantee the
fragments will be installed before the host and so they may not be attached to the host
when it resolves.
This happens on starting the application server. Sometimes the fragments are attached,
sometimes they aren't.
If I install the bundles into the "bundles" folder structure and add capability
entries to the standalone.xml file then it works as expected.
I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4433
days inactive
4439
days old
13 comments
2 participants
participants (2)
-
Paul Illingworth (JIRA) -
Thomas Diesler (JIRA)