[JBoss JIRA] (JBOSGI-746) Updating a configuration may deactivate/active component multiple times
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-746?page=com.atlassian.jira.plugin... ]
Thomas Diesler resolved JBOSGI-746.
-----------------------------------
Resolution: Done
Getting the service before we close the tracker in FrameworkUtils seems to resolve this
> Updating a configuration may deactivate/active component multiple times
> -----------------------------------------------------------------------
>
> Key: JBOSGI-746
> URL: https://issues.jboss.org/browse/JBOSGI-746
> Project: JBoss OSGi
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> * ServiceD has a mandatory unary reference to ServiceD1
> * ServiceD1 is backed by a configuration in ConfigurationAdmin (1.6.0)
> * Activate the services with no configuration
> * Create and update the configuration for ServiceD1
> The observed behaviour is
> * ServiceD gets deactivated
> * ServiceD1 gets deactivated
> * New instance of ServiceD1 is constructed and activated with the configuration
> * ServiceD1 is bound to to a new instance of ServiceD and ServiceD gets activated
> following this ServiceD1 may get deactivated again causing the above sequence to get repeated.
> In a large dependency graph this would deactivate/activate all components in the graph. Component activation may not be cheap and should not be done repeatedly with the same configuration passed in.
--
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
10 years, 8 months
[JBoss JIRA] (JBOSGI-746) Updating a configuration may deactivate/active component multiple times
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-746?page=com.atlassian.jira.plugin... ]
Thomas Diesler commented on JBOSGI-746:
---------------------------------------
CrossRef: https://issues.apache.org/jira/browse/FELIX-4237
> Updating a configuration may deactivate/active component multiple times
> -----------------------------------------------------------------------
>
> Key: JBOSGI-746
> URL: https://issues.jboss.org/browse/JBOSGI-746
> Project: JBoss OSGi
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
>
> * ServiceD has a mandatory unary reference to ServiceD1
> * ServiceD1 is backed by a configuration in ConfigurationAdmin (1.6.0)
> * Activate the services with no configuration
> * Create and update the configuration for ServiceD1
> The observed behaviour is
> * ServiceD gets deactivated
> * ServiceD1 gets deactivated
> * New instance of ServiceD1 is constructed and activated with the configuration
> * ServiceD1 is bound to to a new instance of ServiceD and ServiceD gets activated
> following this ServiceD1 may get deactivated again causing the above sequence to get repeated.
> In a large dependency graph this would deactivate/activate all components in the graph. Component activation may not be cheap and should not be done repeatedly with the same configuration passed in.
--
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
10 years, 8 months
[JBoss JIRA] (JBOSGI-746) Updating a configuration may deactivate/active component multiple times
by Thomas Diesler (JIRA)
Thomas Diesler created JBOSGI-746:
-------------------------------------
Summary: Updating a configuration may deactivate/active component multiple times
Key: JBOSGI-746
URL: https://issues.jboss.org/browse/JBOSGI-746
Project: JBoss OSGi
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assignee: Thomas Diesler
* ServiceD has a mandatory unary reference to ServiceD1
* ServiceD1 is backed by a configuration in ConfigurationAdmin (1.6.0)
* Activate the services with no configuration
* Create and update the configuration for ServiceD1
The observed behaviour is
* ServiceD gets deactivated
* ServiceD1 gets deactivated
* New instance of ServiceD1 is constructed and activated with the configuration
* ServiceD1 is bound to to a new instance of ServiceD and ServiceD gets activated
following this ServiceD1 may get deactivated again causing the above sequence to get repeated.
In a large dependency graph this would deactivate/activate all components in the graph. Component activation may not be cheap and should not be done repeatedly with the same configuration passed in.
--
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
10 years, 8 months
[JBoss JIRA] (JBOSGI-744) JBAS011910 Cannot resolve requirements: [XPackageRequirement[atts={osgi.wiring.package=org.hibernate.criterion}
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-744?page=com.atlassian.jira.plugin... ]
Darryl Miles commented on JBOSGI-744:
-------------------------------------
Steve, I believe this is an OSGi (or OSGi-JPA) matter too.
Thomas, and when you looked at the OSGi meta-data of the hibernate shipped with EAP, what did you see wrong ?
> JBAS011910 Cannot resolve requirements: [XPackageRequirement[atts={osgi.wiring.package=org.hibernate.criterion}
> ---------------------------------------------------------------------------------------------------------------
>
> Key: JBOSGI-744
> URL: https://issues.jboss.org/browse/JBOSGI-744
> Project: JBoss OSGi
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Darryl Miles
> Assignee: Thomas Diesler
>
> EAP 6.1 with upgraded org.hibernate:main jars to 4.2.0.Final (to fix classloading issue HHH-8015 which I did observe).
> JPA has META-INF/jboss-deployment-structure.xml which has entry (amongst other things):
> <module name="org.hibernate" />
> <module name="org.hibernate.validator" />
> JPA has OSGi meta-data including OSGi-JPA:
> Meta-Persistence: META-INF/persistence.xml
> 23:00:16,860 INFO [org.jboss.osgi.framework] (MSC service thread 1-15) JBOSGI011005: Bundle uninstalled: com.domain.jpa:0.0.1.SNAPSHOT
> 23:00:16,862 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment com.domain.jpa-0.0.1-SNAPSHOT.jar (runtime-name: com.domain.jpa-0.0.1-SNAPSHOT.jar) in 4ms
> 23:00:16,863 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "com.domain.jpa-0.0.1-SNAPSHOT.jar" (runtime-name: "com.domain.jpa-0.0.1-SNAPSHOT.jar")
> 23:00:16,876 INFO [org.jboss.as.jpa] (MSC service thread 1-15) JBAS011401: Read persistence.xml for com.domain.jpa
> 23:00:16,880 INFO [org.jboss.osgi.framework] (MSC service thread 1-9) JBOSGI011001: Bundle installed: com.domain.jpa:0.0.1.SNAPSHOT
> 23:00:16,884 WARN [org.jboss.as.osgi] (MSC service thread 1-14) JBAS011910: Cannot resolve requirements: [XPackageRequirement[atts={osgi.wiring.package=org.hibernate.criterion},[com.domain.jpa:0.0.1.SNAPSHOT]]]
> 23:00:16,884 INFO [org.jboss.as.server.deployment] (MSC service thread 1-14) JBAS015970: Defer FIRST_MODULE_USE for com.domain.jpa-0.0.1-SNAPSHOT.jar making it NEVER
> 23:00:16,908 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "com.domain.jpa-0.0.1-SNAPSHOT.jar" with deployment "com.domain.jpa-0.0.1-SNAPSHOT.jar"
> I would expect the OSGi subsystem to have been able to find the import package org.hibernate.criterion
--
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
10 years, 9 months
[JBoss JIRA] (JBOSGI-745) Support OSGi Bundle Native Libraries for Windows 8/2008 Server platforms
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-745?page=com.atlassian.jira.plugin... ]
Thomas Diesler reassigned JBOSGI-745:
-------------------------------------
Assignee: (was: Thomas Diesler)
Requires community involvement.
> Support OSGi Bundle Native Libraries for Windows 8/2008 Server platforms
> ------------------------------------------------------------------------
>
> Key: JBOSGI-745
> URL: https://issues.jboss.org/browse/JBOSGI-745
> Project: JBoss OSGi
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: framework
> Affects Versions: JBossOSGi 2.1.1
> Environment: Windows 8, JDK 7.0_13
> Reporter: Ed Roberts
> Labels: native_libraries, osgi, windows2008Server, windows8
>
> I need to refactor the current jdbc driver modules as OSGi bundles. One particular bundle which contains supporting native libraries caused a startup issue in JBoss 7.2.0.Final. However, the only lead I had was the warning message "JBAS011910: Cannot resolve requirements: []", which appeared several times.
> After enabling debug for the framework, I could see that a jdbc driver bundle containing supporting native libraries was the cause.
> {code}
> 2013-08-30 10:15:07,518 DEBUG [org.jboss.osgi.framework](ClassLoader Thread) Cannot resolve bundle: x:1.0.0.SNAPSHOT: org.osgi.service.resolver.ResolutionException: org.osgi.framework.BundleException: JBOSGI011260: No native code clause selected for: [lib/windows/32/sqljdbc_auth.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86]},dirs={}], lib/windows/32/sqljdbc_xa.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86]},dirs={}], lib/windows/64/sqljdbc_auth.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86-64]},dirs={}], lib/windows/64/sqljdbc_xa.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86-64]},dirs={}]]
> at org.jboss.osgi.framework.internal.ResolverImpl.applyResolverResults(ResolverImpl.java:245)
> at org.jboss.osgi.framework.internal.ResolverImpl.resolveAndApply(ResolverImpl.java:138)
> at org.jboss.osgi.framework.spi.BundleLifecyclePlugin$BundleLifecycleImpl.resolve(BundleLifecyclePlugin.java:97)
> at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.resolve(BundleLifecycleIntegration.java:180)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:624)
> at org.jboss.osgi.framework.internal.FallbackLoader.findInUnresolvedRevisions(FallbackLoader.java:285)
> at org.jboss.osgi.framework.internal.FallbackLoader.findRevisionDynamically(FallbackLoader.java:192)
> at org.jboss.osgi.framework.internal.FallbackLoader.loadClassLocal(FallbackLoader.java:112)
> at org.jboss.modules.Module.loadModuleClass(Module.java:526)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.access$400(ConcurrentClassLoader.java:52)
> at org.jboss.modules.ConcurrentClassLoader$LoaderThread.run(ConcurrentClassLoader.java:627)
> Caused by: org.osgi.framework.BundleException: JBOSGI011260: No native code clause selected for: [lib/windows/32/sqljdbc_auth.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86]},dirs={}], lib/windows/32/sqljdbc_xa.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86]},dirs={}], lib/windows/64/sqljdbc_auth.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86-64]},dirs={}], lib/windows/64/sqljdbc_xa.dll[attr={osname=[[WindowsVista, Windows2003, Windows7, WindowsXP, Windows2000, WindowsNT]], processor=[x86-64]},dirs={}]]
> at org.jboss.osgi.framework.internal.NativeCodeImpl.resolveNativeCode(NativeCodeImpl.java:165)
> at org.jboss.osgi.framework.internal.ResolverImpl.resolveNativeCodeLibraries(ResolverImpl.java:296)
> at org.jboss.osgi.framework.internal.ResolverImpl.applyResolverResults(ResolverImpl.java:243)
> ... 13 more
> {code}
> This is due to the NativeCodeImpl which does not yet include support for the two operating system mentioned above.
--
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
10 years, 9 months
[JBoss JIRA] (JBOSGI-744) JBAS011910 Cannot resolve requirements: [XPackageRequirement[atts={osgi.wiring.package=org.hibernate.criterion}
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-744?page=com.atlassian.jira.plugin... ]
Thomas Diesler resolved JBOSGI-744.
-----------------------------------
Resolution: Won't Fix
OSGi has been removed from EAP.
This only qualifies as an OSGi issue if Hibernate properly exports that package. The framework does not make assumptions on where a required import may come from.
> JBAS011910 Cannot resolve requirements: [XPackageRequirement[atts={osgi.wiring.package=org.hibernate.criterion}
> ---------------------------------------------------------------------------------------------------------------
>
> Key: JBOSGI-744
> URL: https://issues.jboss.org/browse/JBOSGI-744
> Project: JBoss OSGi
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Darryl Miles
> Assignee: Thomas Diesler
>
> EAP 6.1 with upgraded org.hibernate:main jars to 4.2.0.Final (to fix classloading issue HHH-8015 which I did observe).
> JPA has META-INF/jboss-deployment-structure.xml which has entry (amongst other things):
> <module name="org.hibernate" />
> <module name="org.hibernate.validator" />
> JPA has OSGi meta-data including OSGi-JPA:
> Meta-Persistence: META-INF/persistence.xml
> 23:00:16,860 INFO [org.jboss.osgi.framework] (MSC service thread 1-15) JBOSGI011005: Bundle uninstalled: com.domain.jpa:0.0.1.SNAPSHOT
> 23:00:16,862 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment com.domain.jpa-0.0.1-SNAPSHOT.jar (runtime-name: com.domain.jpa-0.0.1-SNAPSHOT.jar) in 4ms
> 23:00:16,863 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "com.domain.jpa-0.0.1-SNAPSHOT.jar" (runtime-name: "com.domain.jpa-0.0.1-SNAPSHOT.jar")
> 23:00:16,876 INFO [org.jboss.as.jpa] (MSC service thread 1-15) JBAS011401: Read persistence.xml for com.domain.jpa
> 23:00:16,880 INFO [org.jboss.osgi.framework] (MSC service thread 1-9) JBOSGI011001: Bundle installed: com.domain.jpa:0.0.1.SNAPSHOT
> 23:00:16,884 WARN [org.jboss.as.osgi] (MSC service thread 1-14) JBAS011910: Cannot resolve requirements: [XPackageRequirement[atts={osgi.wiring.package=org.hibernate.criterion},[com.domain.jpa:0.0.1.SNAPSHOT]]]
> 23:00:16,884 INFO [org.jboss.as.server.deployment] (MSC service thread 1-14) JBAS015970: Defer FIRST_MODULE_USE for com.domain.jpa-0.0.1-SNAPSHOT.jar making it NEVER
> 23:00:16,908 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "com.domain.jpa-0.0.1-SNAPSHOT.jar" with deployment "com.domain.jpa-0.0.1-SNAPSHOT.jar"
> I would expect the OSGi subsystem to have been able to find the import package org.hibernate.criterion
--
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
10 years, 9 months