[jira] [Work started] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[ https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4883 started by David Bosschaert. --- > ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException > -- > > Key: FELIX-4883 > URL: https://issues.apache.org/jira/browse/FELIX-4883 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version > 1.8.3-R1658944 >Reporter: Rob Ryan >Assignee: David Bosschaert >Priority: Minor > Fix For: scr-2.0.0 > > Attachments: scrtest.zip > > > In our test automation we install a large set of bundles after our also large > 'main' app starts up. This causes significant churn as bundles and components > are stopped and potentially new versions are started. Unfortunately the coded > involved is not open source, so I cannot deliver the full data required to > reproduce the failure described here. > What I can share is that after all this churn of bundles and components being > stopped and started the ScrComponentRuntime service starts to fail with a > NullPointerException in getComponentConfigurationDTOs. This was initially > noticed as an NPE being reported when visiting the felix console at > /system/console/components. > The stack at the point of failure is: > java.lang.NullPointerException > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119) > at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37) > ... > The NPE occurs because a > org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being > processed in > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference) > line: 205 > has a m_svcObj of null. So even though the bundle is actually available in > the object the getBundle() method returns null. > [~cziegeler] [~bosschaert] I can investigate further to ideally narrow this > down further, but any pointers would be much appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4892) NPE in maven-bundle-plugin
[
https://issues.apache.org/jira/browse/FELIX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14551941#comment-14551941
]
David Bosschaert commented on FELIX-4892:
-
[~kwin] you are correct. I have updated the version info. Thanks for pointing
this out.
> NPE in maven-bundle-plugin
> --
>
> Key: FELIX-4892
> URL: https://issues.apache.org/jira/browse/FELIX-4892
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.4
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: maven-bundle-plugin-2.5.5
>
>
> I am getting an NPE with the (as yet unreleased version of) the
> maven-bundle-plugin:
> {code}[ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
> project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline)
> on project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> baseline of goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:164)
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:136)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4892) NPE in maven-bundle-plugin
[
https://issues.apache.org/jira/browse/FELIX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4892:
Affects Version/s: (was: maven-bundle-plugin-2.5.5)
maven-bundle-plugin-2.5.4
> NPE in maven-bundle-plugin
> --
>
> Key: FELIX-4892
> URL: https://issues.apache.org/jira/browse/FELIX-4892
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.4
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: maven-bundle-plugin-2.5.5
>
>
> I am getting an NPE with the (as yet unreleased version of) the
> maven-bundle-plugin:
> {code}[ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
> project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline)
> on project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> baseline of goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:164)
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:136)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4892) NPE in maven-bundle-plugin
[
https://issues.apache.org/jira/browse/FELIX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4892.
-
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revision&revision=1680303
> NPE in maven-bundle-plugin
> --
>
> Key: FELIX-4892
> URL: https://issues.apache.org/jira/browse/FELIX-4892
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.5
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: maven-bundle-plugin-2.5.5
>
>
> I am getting an NPE with the (as yet unreleased version of) the
> maven-bundle-plugin:
> {code}[ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
> project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline)
> on project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> baseline of goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:164)
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:136)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FELIX-4892) NPE in maven-bundle-plugin
[
https://issues.apache.org/jira/browse/FELIX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-4892:
---
Assignee: David Bosschaert
> NPE in maven-bundle-plugin
> --
>
> Key: FELIX-4892
> URL: https://issues.apache.org/jira/browse/FELIX-4892
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.5
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: maven-bundle-plugin-2.5.5
>
>
> I am getting an NPE with the (as yet unreleased version of) the
> maven-bundle-plugin:
> {code}[ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
> project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline)
> on project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> baseline of goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:164)
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:136)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (FELIX-4892) NPE in maven-bundle-plugin
[
https://issues.apache.org/jira/browse/FELIX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4892 started by David Bosschaert.
---
> NPE in maven-bundle-plugin
> --
>
> Key: FELIX-4892
> URL: https://issues.apache.org/jira/browse/FELIX-4892
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.5
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: maven-bundle-plugin-2.5.5
>
>
> I am getting an NPE with the (as yet unreleased version of) the
> maven-bundle-plugin:
> {code}[ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
> project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline)
> on project myproject: Execution baseline of goal
> org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> baseline of goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline
> failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:164)
> at
> org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:136)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4892) NPE in maven-bundle-plugin
[
https://issues.apache.org/jira/browse/FELIX-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4892:
Description:
I am getting an NPE with the (as yet unreleased version of) the
maven-bundle-plugin:
{code}[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
project myproject: Execution baseline of goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
project myproject: Execution baseline of goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution baseline
of goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:164)
at
org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:136)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more{code}
was:
I am getting an NPE with the (as yet unreleased version of) the
maven-bundle-plugin:
{code}[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
project com.adobe.granite.containers.director: Execution baseline of goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
project com.adobe.granite.containers.director: Execution baseline of goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java
[jira] [Created] (FELIX-4892) NPE in maven-bundle-plugin
David Bosschaert created FELIX-4892:
---
Summary: NPE in maven-bundle-plugin
Key: FELIX-4892
URL: https://issues.apache.org/jira/browse/FELIX-4892
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.5.5
Reporter: David Bosschaert
Fix For: maven-bundle-plugin-2.5.5
I am getting an NPE with the (as yet unreleased version of) the
maven-bundle-plugin:
{code}[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
project com.adobe.granite.containers.director: Execution baseline of goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline (baseline) on
project com.adobe.granite.containers.director: Execution baseline of goal
org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution baseline
of goal org.apache.felix:maven-bundle-plugin:2.5.5-SNAPSHOT:baseline failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:164)
at
org.apache.felix.bundleplugin.baseline.AbstractBaselinePlugin.execute(AbstractBaselinePlugin.java:136)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4866) Improve service registry
[ https://issues.apache.org/jira/browse/FELIX-4866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4866. - Resolution: Fixed Many thanks Pierre for pointing this issue out! There was indeed a bug in the code that I modified. I have committed a fix in http://svn.apache.org/viewvc?view=revision&revision=1680258 I have also included you concurrency unit test (the second version) that you attached to this bug. Thanks again for your help on this! > Improve service registry > > > Key: FELIX-4866 > URL: https://issues.apache.org/jira/browse/FELIX-4866 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.0.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.2.0 > > Attachments: ConcurrencyTest.2.tgz, ConcurrencyTest.tgz > > > The current service registry is currently not using any of the Java 5 > concurrent data structures. Using those could improve the implementation, the > readibility of the code and potentially the performance of the service > registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (FELIX-4866) Improve service registry
[ https://issues.apache.org/jira/browse/FELIX-4866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4866 started by David Bosschaert. --- > Improve service registry > > > Key: FELIX-4866 > URL: https://issues.apache.org/jira/browse/FELIX-4866 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.0.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.2.0 > > Attachments: ConcurrencyTest.tgz > > > The current service registry is currently not using any of the Java 5 > concurrent data structures. Using those could improve the implementation, the > readibility of the code and potentially the performance of the service > registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4866) Improve service registry
[ https://issues.apache.org/jira/browse/FELIX-4866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4866. - Resolution: Fixed Fixed with http://svn.apache.org/viewvc?view=revision&revision=1679327 and http://svn.apache.org/viewvc?view=revision&revision=1679367 > Improve service registry > > > Key: FELIX-4866 > URL: https://issues.apache.org/jira/browse/FELIX-4866 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.0.0 >Reporter: Carsten Ziegeler >Assignee: David Bosschaert > Fix For: framework-5.2.0 > > > The current service registry is currently not using any of the Java 5 > concurrent data structures. Using those could improve the implementation, the > readibility of the code and potentially the performance of the service > registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[ https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-4883: --- Assignee: David Bosschaert > ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException > -- > > Key: FELIX-4883 > URL: https://issues.apache.org/jira/browse/FELIX-4883 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version > 1.8.3-R1658944 >Reporter: Rob Ryan >Assignee: David Bosschaert >Priority: Minor > Fix For: scr-2.0.0 > > Attachments: scrtest.zip > > > In our test automation we install a large set of bundles after our also large > 'main' app starts up. This causes significant churn as bundles and components > are stopped and potentially new versions are started. Unfortunately the coded > involved is not open source, so I cannot deliver the full data required to > reproduce the failure described here. > What I can share is that after all this churn of bundles and components being > stopped and started the ScrComponentRuntime service starts to fail with a > NullPointerException in getComponentConfigurationDTOs. This was initially > noticed as an NPE being reported when visiting the felix console at > /system/console/components. > The stack at the point of failure is: > java.lang.NullPointerException > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145) > at > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119) > at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37) > ... > The NPE occurs because a > org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being > processed in > org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference) > line: 205 > has a m_svcObj of null. So even though the bundle is actually available in > the object the getBundle() method returns null. > [~cziegeler] [~bosschaert] I can investigate further to ideally narrow this > down further, but any pointers would be much appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4867) Stale bundle revisions don't get cleaned up when last using bundle is gone
[ https://issues.apache.org/jira/browse/FELIX-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4867. - Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revision&revision=1676309 Also added unit test. I ran this version through the OSGi CT and that still passed. > Stale bundle revisions don't get cleaned up when last using bundle is gone > -- > > Key: FELIX-4867 > URL: https://issues.apache.org/jira/browse/FELIX-4867 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.6.1 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-5.2.0 > > > If another bundle is still using an uninstalled bundle, a bundle revision > remains for it. > However, once the using bundle gets uninstalled, the bundle revision does not > get cleaned up, so it remains in memory. This is a problem because the > packages exported by this orphaned revision are still visible via Package > Admin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (FELIX-4867) Stale bundle revisions don't get cleaned up when last using bundle is gone
[ https://issues.apache.org/jira/browse/FELIX-4867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4867 started by David Bosschaert. --- > Stale bundle revisions don't get cleaned up when last using bundle is gone > -- > > Key: FELIX-4867 > URL: https://issues.apache.org/jira/browse/FELIX-4867 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.6.1 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-5.2.0 > > > If another bundle is still using an uninstalled bundle, a bundle revision > remains for it. > However, once the using bundle gets uninstalled, the bundle revision does not > get cleaned up, so it remains in memory. This is a problem because the > packages exported by this orphaned revision are still visible via Package > Admin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4867) Stale bundle revisions don't get cleaned up when last using bundle is gone
David Bosschaert created FELIX-4867: --- Summary: Stale bundle revisions don't get cleaned up when last using bundle is gone Key: FELIX-4867 URL: https://issues.apache.org/jira/browse/FELIX-4867 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.6.1 Reporter: David Bosschaert Assignee: David Bosschaert Fix For: framework-5.2.0 If another bundle is still using an uninstalled bundle, a bundle revision remains for it. However, once the using bundle gets uninstalled, the bundle revision does not get cleaned up, so it remains in memory. This is a problem because the packages exported by this orphaned revision are still visible via Package Admin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4844) Store configuration data in a diff-tool friendly way
[ https://issues.apache.org/jira/browse/FELIX-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14510787#comment-14510787 ] David Bosschaert commented on FELIX-4844: - Hi [~balazs.zsoldos], I haven't looked at your patch yet but maybe you can tell me whether the old format of the configuration files can still be read with your changes? > Store configuration data in a diff-tool friendly way > > > Key: FELIX-4844 > URL: https://issues.apache.org/jira/browse/FELIX-4844 > Project: Felix > Issue Type: Wish > Components: Configuration Admin >Reporter: Balazs Zsoldos > > We store our configuration with the sources in the source-code control system > (git). It often happens that multiple developers work on the same project and > they modify the configuration parallel. It would not be a problem if the > config files were diff-tool friendly. To achieve this goal, two improvements > would be necessary: > *Store entries in ABC ordered list* > In the config files, the entries should be stored sorted by ABC. It is easy > to implement by overriding HashTable in the same way that LinkedHashMap > overrides HashMap. > *Store array values in multiple lines* > At the moment a setting with two values are stored like this: > key=["value1", "value2"] > Instead of this, I would store it in the following format (each entry on new > line): > key=[ \ > "value1", \ > "value2" \ > ] > *Question* > Do you think that if I prepare a patch for this, that would be accepted? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE
[
https://issues.apache.org/jira/browse/FELIX-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499777#comment-14499777
]
David Bosschaert commented on FELIX-4851:
-
> On a related note, the pax-exam integration tests on ConfigAdmin are failing
> with deployment errors using mvn clean install.
I'm not seeing this issue. For me 'mvn clean install' in the configadmin
directory completes successfully. (With Maven 3.0.5 and Java 1.7 on OSX)
> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and
> activates a component that creates a configuration which itself is a
> precondition for the instantiation of another component
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not
> deliver the configuration update event to SCR, although SCR has registered a
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE &&
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE
> state directly after all available components have been activated. Because of
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able
> to activate all those components whose preconditions are actually fulfilled.
> The problem does not occur in combination with the Equinox ConfigAdmin, which
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration
> events are considered to be important or not. In the SCR scenario, the
> developers rely on the fact that configuration events are delivered
> independently of their bundle state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE
[
https://issues.apache.org/jira/browse/FELIX-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4851.
-
Resolution: Fixed
Applied my fix in http://svn.apache.org/viewvc?view=revision&revision=1674284
I also added a unit test for this and ran it through the OSGi ConfigAdmin CT.
[~herr-herner], [~magnet] could you please check that this resolves the issue
for you?
> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and
> activates a component that creates a configuration which itself is a
> precondition for the instantiation of another component
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not
> deliver the configuration update event to SCR, although SCR has registered a
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE &&
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE
> state directly after all available components have been activated. Because of
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able
> to activate all those components whose preconditions are actually fulfilled.
> The problem does not occur in combination with the Equinox ConfigAdmin, which
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration
> events are considered to be important or not. In the SCR scenario, the
> developers rely on the fact that configuration events are delivered
> independently of their bundle state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE
[
https://issues.apache.org/jira/browse/FELIX-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reopened FELIX-4851:
-
Assignee: David Bosschaert (was: Guillaume Nodet)
I had actually worked on a slightly different fix. After discussing with [~gnt]
we decided to use my approach which allows events to be sent to bundles in
STARTING and ACTIVE states, but not in all other states. For example it is not
desirable to have events sent to bundles in the STOPPING state.
> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and
> activates a component that creates a configuration which itself is a
> precondition for the instantiation of another component
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not
> deliver the configuration update event to SCR, although SCR has registered a
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE &&
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE
> state directly after all available components have been activated. Because of
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able
> to activate all those components whose preconditions are actually fulfilled.
> The problem does not occur in combination with the Equinox ConfigAdmin, which
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration
> events are considered to be important or not. In the SCR scenario, the
> developers rely on the fact that configuration events are delivered
> independently of their bundle state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE
[
https://issues.apache.org/jira/browse/FELIX-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4851 started by David Bosschaert.
---
> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and
> activates a component that creates a configuration which itself is a
> precondition for the instantiation of another component
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not
> deliver the configuration update event to SCR, although SCR has registered a
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE &&
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE
> state directly after all available components have been activated. Because of
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able
> to activate all those components whose preconditions are actually fulfilled.
> The problem does not occur in combination with the Equinox ConfigAdmin, which
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration
> events are considered to be important or not. In the SCR scenario, the
> developers rely on the fact that configuration events are delivered
> independently of their bundle state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FELIX-4851) ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which are provided by bundles that are in state ACTIVE
[
https://issues.apache.org/jira/browse/FELIX-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-4851:
---
Assignee: David Bosschaert
> ConfigAdmin only forwards ConfigurationEvents to ConfigurationListeners which
> are provided by bundles that are in state ACTIVE
> --
>
> Key: FELIX-4851
> URL: https://issues.apache.org/jira/browse/FELIX-4851
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.2
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>Priority: Critical
> Fix For: configadmin-1.8.4
>
>
> I am facing a serious problem with the Felix ConfigAdmin in combination with
> Felix SCR. Let us assume that the SCR bundle becomes activated at last and
> activates a component that creates a configuration which itself is a
> precondition for the instantiation of another component
> (ConfigurationPolicy#REQUIRE). In this case the Felix ConfigAdmin does not
> deliver the configuration update event to SCR, although SCR has registered a
> ConfigurationListener in the OSGi Service Registry.
> The problem is caused by line 2029 of the class ConfigurationManager
> (Version: 1.8.3-SNAPSHOT):
> {code}
> if ( listenerProvider[serviceIndex].getState() == Bundle.ACTIVE &&
> this.listeners[serviceIndex] != null )
> {code}
> In this scenario, the SCR bundle is in state STARTING and reaches the ACTIVE
> state directly after all available components have been activated. Because of
> missing Configuration Events caused by the Felix ConfigAdmin, SCR is not able
> to activate all those components whose preconditions are actually fulfilled.
> The problem does not occur in combination with the Equinox ConfigAdmin, which
> does not make the problematic bundle state check.
> I highly recommend removing the bundle state check and change line 2029 into:
> {code}
> if ( this.listeners[serviceIndex] != null ).
> {code}
> It is up to the developer to decide, in which bundle state configuration
> events are considered to be important or not. In the SCR scenario, the
> developers rely on the fact that configuration events are delivered
> independently of their bundle state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4764) Add support to GZIP based compact index files
[ https://issues.apache.org/jira/browse/FELIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4764. - Resolution: Fixed Thanks [~cvgaviao]! I've committed your patch here: http://svn.apache.org/viewvc?view=revision&revision=1670365 > Add support to GZIP based compact index files > - > > Key: FELIX-4764 > URL: https://issues.apache.org/jira/browse/FELIX-4764 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-2.0.2 >Reporter: Cristiano Gavião >Assignee: David Bosschaert > > OSGi Alliance Repoindex tool uses the GZIP format for its compacted index > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4764) Add support to GZIP based compact index files
[ https://issues.apache.org/jira/browse/FELIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14386475#comment-14386475 ] David Bosschaert commented on FELIX-4764: - Hi [~cvgaviao], are you still interested in providing a test case? Thanks! > Add support to GZIP based compact index files > - > > Key: FELIX-4764 > URL: https://issues.apache.org/jira/browse/FELIX-4764 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-2.0.2 >Reporter: Cristiano Gavião >Assignee: David Bosschaert > > OSGi Alliance Repoindex tool uses the GZIP format for its compacted index > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4838) Deadlock in Service Registry
[ https://issues.apache.org/jira/browse/FELIX-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4838. - Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revision&revision=r1668495 > Deadlock in Service Registry > > > Key: FELIX-4838 > URL: https://issues.apache.org/jira/browse/FELIX-4838 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.6.1 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.8.0 > > > As described http://www.mail-archive.com/dev%40felix.apache.org/msg35998.html > An endless loop situation which looks very much like a deadlock occasionally > happens with the Service Registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4838) Deadlock in Service Registry
David Bosschaert created FELIX-4838: --- Summary: Deadlock in Service Registry Key: FELIX-4838 URL: https://issues.apache.org/jira/browse/FELIX-4838 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.6.1 Reporter: David Bosschaert Assignee: David Bosschaert Fix For: framework-4.8.0 As described http://www.mail-archive.com/dev%40felix.apache.org/msg35998.html An endless loop situation which looks very much like a deadlock occasionally happens with the Service Registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4501) Impossible to set the felix.fileinstall.optionalImportRefreshScope property from startup
[
https://issues.apache.org/jira/browse/FELIX-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4501.
-
Resolution: Fixed
Thanks [~rotty3000]! I've committed your fix in
http://svn.apache.org/viewvc?view=revision&revision=1669527
> Impossible to set the felix.fileinstall.optionalImportRefreshScope property
> from startup
>
>
> Key: FELIX-4501
> URL: https://issues.apache.org/jira/browse/FELIX-4501
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.4.0
> Environment: confirmed on equinox 3.8.0.v20120529-1548
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>Priority: Minor
> Attachments: FELIX-4501.patch, FELIX-4501.patch
>
>
> I'm seeing a deadlock where on first start the fileinstall bundle is getting
> stuck with itself
> as per the following two stack traces:
> {code}
> "Refresh Packages" daemon prio=10 tid=0x7fc29c0f6800 nid=0x94c waiting on
> condition [0x7fc2b9c15000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc095f950> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
> at
> org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
> - locked <0xc0cbc1f8> (a
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
> at java.lang.Thread.run(Thread.java:744)
>Locked ownable synchronizers:
> - None
> {code}
> {code}
> "fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10
> tid=0x7fc2ac01a000 nid=0x920 waiting on condition [0x7fc2ba721000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc51bd048> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
>Locked ownable synchronizers:
> - None
> {code}
> You can see that the refresh event will never return (to tear down the
> latch) as long as the {{FileInstall.stop}} operation can't get the lock in to
> directory which
[jira] [Assigned] (FELIX-4501) Impossible to set the felix.fileinstall.optionalImportRefreshScope property from startup
[
https://issues.apache.org/jira/browse/FELIX-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-4501:
---
Assignee: David Bosschaert
> Impossible to set the felix.fileinstall.optionalImportRefreshScope property
> from startup
>
>
> Key: FELIX-4501
> URL: https://issues.apache.org/jira/browse/FELIX-4501
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.4.0
> Environment: confirmed on equinox 3.8.0.v20120529-1548
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>Priority: Minor
> Attachments: FELIX-4501.patch, FELIX-4501.patch
>
>
> I'm seeing a deadlock where on first start the fileinstall bundle is getting
> stuck with itself
> as per the following two stack traces:
> {code}
> "Refresh Packages" daemon prio=10 tid=0x7fc29c0f6800 nid=0x94c waiting on
> condition [0x7fc2b9c15000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc095f950> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
> at
> org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
> - locked <0xc0cbc1f8> (a
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
> at java.lang.Thread.run(Thread.java:744)
>Locked ownable synchronizers:
> - None
> {code}
> {code}
> "fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10
> tid=0x7fc2ac01a000 nid=0x920 waiting on condition [0x7fc2ba721000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc51bd048> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
>Locked ownable synchronizers:
> - None
> {code}
> You can see that the refresh event will never return (to tear down the
> latch) as long as the {{FileInstall.stop}} operation can't get the lock in to
> directory which it's currently holding during the refresh operation!
> What seems strange is that fileinstall is
[jira] [Commented] (FELIX-4501) Impossible to set the felix.fileinstall.optionalImportRefreshScope property from startup
[
https://issues.apache.org/jira/browse/FELIX-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382031#comment-14382031
]
David Bosschaert commented on FELIX-4501:
-
Hmmm, {{mvn clean install}} works fine for me with Java 7 and Java 8 (and Maven
3.0.5). What are the actual signatures it complains about?
> Impossible to set the felix.fileinstall.optionalImportRefreshScope property
> from startup
>
>
> Key: FELIX-4501
> URL: https://issues.apache.org/jira/browse/FELIX-4501
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.4.0
> Environment: confirmed on equinox 3.8.0.v20120529-1548
>Reporter: Raymond Augé
>Priority: Minor
>
> I'm seeing a deadlock where on first start the fileinstall bundle is getting
> stuck with itself
> as per the following two stack traces:
> {code}
> "Refresh Packages" daemon prio=10 tid=0x7fc29c0f6800 nid=0x94c waiting on
> condition [0x7fc2b9c15000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc095f950> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
> at
> org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
> - locked <0xc0cbc1f8> (a
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
> at java.lang.Thread.run(Thread.java:744)
>Locked ownable synchronizers:
> - None
> {code}
> {code}
> "fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10
> tid=0x7fc2ac01a000 nid=0x920 waiting on condition [0x7fc2ba721000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc51bd048> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
>Locked ownable synchronizers:
> - None
> {code}
> You can see that the refresh event will never return (to tear down the
> latch) as long as the {{FileInstall.stop}} operation can't get the lock in to
> directory which it's currently holding during the re
[jira] [Commented] (FELIX-4501) Impossible to set the felix.fileinstall.optionalImportRefreshScope property from startup
[
https://issues.apache.org/jira/browse/FELIX-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381999#comment-14381999
]
David Bosschaert commented on FELIX-4501:
-
[~rotty3000] would you maybe have a patch that implements a potential solution
to this?
> Impossible to set the felix.fileinstall.optionalImportRefreshScope property
> from startup
>
>
> Key: FELIX-4501
> URL: https://issues.apache.org/jira/browse/FELIX-4501
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.4.0
> Environment: confirmed on equinox 3.8.0.v20120529-1548
>Reporter: Raymond Augé
>Priority: Minor
>
> I'm seeing a deadlock where on first start the fileinstall bundle is getting
> stuck with itself
> as per the following two stack traces:
> {code}
> "Refresh Packages" daemon prio=10 tid=0x7fc29c0f6800 nid=0x94c waiting on
> condition [0x7fc2b9c15000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc095f950> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)
> at
> org.apache.felix.fileinstall.internal.FileInstall.stop(FileInstall.java:171)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:771)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:764)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:510)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:566)
> at
> org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1207)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:326)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
> - locked <0xc0cbc1f8> (a
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl)
> at
> org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
> at java.lang.Thread.run(Thread.java:744)
>Locked ownable synchronizers:
> - None
> {code}
> {code}
> "fileinstall-/home/rotty/AS/liferay-portal/osgi/portal" daemon prio=10
> tid=0x7fc2ac01a000 nid=0x920 waiting on condition [0x7fc2ba721000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc51bd048> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:319)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:674)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:495)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)
>Locked ownable synchronizers:
> - None
> {code}
> You can see that the refresh event will never return (to tear down the
> latch) as long as the {{FileInstall.stop}} operation can't get the lock in to
> directory which it's currently holding during the refresh operation!
> What seems strange is that filei
[jira] [Commented] (FELIX-4640) missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in org.apache.felix.framework
[
https://issues.apache.org/jira/browse/FELIX-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367085#comment-14367085
]
David Bosschaert commented on FELIX-4640:
-
Hi [~jwausle] it has been released last week. You can download it from Maven
central here:
http://search.maven.org/#artifactdetails%7Corg.apache.felix%7Corg.apache.felix.bundlerepository%7C2.0.4%7Cbundle
I noticed that the Felix download area has not yet been updated with this
artifact. Hopefully that will be soon.
> missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in
> org.apache.felix.framework
> -
>
> Key: FELIX-4640
> URL: https://issues.apache.org/jira/browse/FELIX-4640
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR), Framework
> Environment: any
>Reporter: Jan Winter
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.4
>
> Attachments: cap.diff
>
>
> When I try to deploy a bundle from a OBRepo occur the below error
> 'Unsatisfied requirement'.
> g! obr:deploy any.bundle
> Unsatisfied requirement(s):
> ---
>(&(osgi.ee=JavaSE)(version=1.8))
> I would expect that this capability will be provided by system-bundle.
> g! felix:inspect capability osgi.ee
> org.apache.felix.framework [0] provides:
>
> osgi.ee; OSGi/Minimum [1.0.0, 1.1.0, 1.2.0] [UNUSED]
> osgi.ee; JavaSE [1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0,
> 1.8.0]
> *My full runtime environment is.*
> g! lb
> START LEVEL 1
>ID|State |Level|Name
> 0|Active |0|System Bundle (4.4.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.2)
> 2|Active |1|bndlib (2.3.0.201405100607)
> 3|Active |1|biz.aQute.repository (2.1.0.062515_230REL)
> 4|Active |1|Java XML Streaming API (1.0.1.v201004272200)
> 5|Active |1|JAXP XML (1.3.4.v201005080400)
> 6|Active |1|Apache Felix Gogo Command (0.14.0)
> 7|Active |1|Apache Felix Gogo Runtime (0.12.1)
> 8|Active |1|Apache Felix Gogo Shell (0.10.0.v201212101605)
> I found one related fact in
> 'org.apache.felix.bundlerepository-2.0.2/org.apache.felix.bundlerepository.impl.LocalResourceImpl.java'.
> - declared 'osgi.ee' capabilities from framework-bundle will realized as
> 'ee=JavaSE-1.8' capability
> - but the filter require 1 spitted capability ( and
> ) '(&(osgi.ee=JavaSE)(version=1.8))'
> *Here the patch who works for me.*
> 85c85,86
> < cap.addProperty(Capability.EXECUTIONENVIRONMENT,
> tokens.nextToken().trim());
> ---
> > String eeValue = tokens.nextToken().trim();
> >
> > cap.addProperty(Capability.EXECUTIONENVIRONMENT, eeValue);
> 86a88,100
> >
> > String[] split = eeValue.split("-");
> > switch (split.length) {
> > case 2:
> > String osgi_ee = "osgi." +
> > Capability.EXECUTIONENVIRONMENT;
> > CapabilityImpl cap2 = new
> > CapabilityImpl(osgi_ee, new PropertyImpl[]{
> > new
> > PropertyImpl(osgi_ee, null, split[0]),
> > new
> > PropertyImpl("version", null, split[1])
> > });
> > addCapability(cap2);
> > break;
> > }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4525) Refactor the Framework to use the Resolver module
[ https://issues.apache.org/jira/browse/FELIX-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358435#comment-14358435 ] David Bosschaert commented on FELIX-4525: - Thanks Guillaume for taking that stuff and completing it. It was on my radar, but not at the top of my list. > Refactor the Framework to use the Resolver module > - > > Key: FELIX-4525 > URL: https://issues.apache.org/jira/browse/FELIX-4525 > Project: Felix > Issue Type: Task > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: Guillaume Nodet > Fix For: framework-4.8.0 > > > Currently both the framework has a resolver implementation as well as the > resolver module, which has a separate resolver implementation. The resolver > module originates from the framework, but they are not the same any more. > It would be good to refactor the framework to use the resolver implementation > from the resolver module so that there is no code duplication any more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4765) RepositoryAdmin don´t discover my required resources.
[
https://issues.apache.org/jira/browse/FELIX-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345021#comment-14345021
]
David Bosschaert commented on FELIX-4765:
-
Hi [~jwausle], would you be able to also provide a unit test for the issue?
> RepositoryAdmin don´t discover my required resources.
> -
>
> Key: FELIX-4765
> URL: https://issues.apache.org/jira/browse/FELIX-4765
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.2
>Reporter: Jan Winter
>Priority: Minor
> Attachments: CapabilityDuplicator.java, index.xml, index.xml.patched
>
>
> I use 'org.apache.felix.bundlerepository-2.0.2.jar'
> I register a index.xml (@see attachement index.xml)
> - generated by 'org.osgi.impl.bundle.repoindex.lib-2.1.1.jar'
> - with content:
> bundle.1 `export` bundle.1.requieredpackage
> bundle.2
> bundle.3 `requiere` bundle.2
> bundle.3 `import` bundle.1.requieredpackage
> If I try to discover the requirements of bundle.3
> {code}
> Resource[] discoverResources =
> this.repositoryAdmin.discoverResources("(symbolicname=bundle.3)");
> for (Resource resource : discoverResources) {
> System.out.printf("Resources: %s. Require:\n",
> resource.getSymbolicName());
>
> for (final Requirement requirement :
> resource.getRequirements()) {
> Resource[] dependencies =
> this.repositoryAdmin.discoverResources(new Requirement[] { requirement });
>
> System.out.printf("\t%s: %s\n", requirement,
> Arrays.toString(dependencies));
> }
> }
> {code}
> Than I got no results for any requirement.
> I patch my index.xml file like this (@see attached index.xml.patch):
> {noformat}
> 50a51,54
> >
> >
> >
> >
> 85a90,95
> >
> >
> >
> >
> >
> >
> {noformat}
> Than I got results.
> Anything goes wrong while bindex.xml-generation or repoadmin-discovering.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4800) Bundle search in /system/console/bundles produces 405
[ https://issues.apache.org/jira/browse/FELIX-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4800. - Resolution: Fixed Fix Version/s: webconsole-4.2.8 The 405 issue is fixed in commit http://svn.apache.org/viewvc?view=revision&revision=1660639 The 500 issue I mentioned above was actually me using the plugin incorrectly. > Bundle search in /system/console/bundles produces 405 > - > > Key: FELIX-4800 > URL: https://issues.apache.org/jira/browse/FELIX-4800 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.2.4 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: webconsole-4.2.8 > > > Searching in the bundles list produces a 405. Enter any value in the bundle > search box and hit 'Apply Filter' and it will produce a 405 with as reason: > HTTP method POST is not supported by this URL > possibly related, when selecting 'Filter All' instead, I'm getting a 500 with > as message: > Problem accessing /system/console/bundles/.json. Reason: > Invalid LDAP filter specified -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4800) Bundle search in /system/console/bundles produces 405
[ https://issues.apache.org/jira/browse/FELIX-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-4800: --- Assignee: David Bosschaert > Bundle search in /system/console/bundles produces 405 > - > > Key: FELIX-4800 > URL: https://issues.apache.org/jira/browse/FELIX-4800 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.2.4 >Reporter: David Bosschaert >Assignee: David Bosschaert > > Searching in the bundles list produces a 405. Enter any value in the bundle > search box and hit 'Apply Filter' and it will produce a 405 with as reason: > HTTP method POST is not supported by this URL > possibly related, when selecting 'Filter All' instead, I'm getting a 500 with > as message: > Problem accessing /system/console/bundles/.json. Reason: > Invalid LDAP filter specified -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4800) Bundle search in /system/console/bundles produces 405
[ https://issues.apache.org/jira/browse/FELIX-4800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324855#comment-14324855 ] David Bosschaert commented on FELIX-4800: - I'm seeing that the 405 only happens in cases where the search produces nothing. In cases where the search has a result (a subset of bundles) these are correctly reported. > Bundle search in /system/console/bundles produces 405 > - > > Key: FELIX-4800 > URL: https://issues.apache.org/jira/browse/FELIX-4800 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.2.4 >Reporter: David Bosschaert > > Searching in the bundles list produces a 405. Enter any value in the bundle > search box and hit 'Apply Filter' and it will produce a 405 with as reason: > HTTP method POST is not supported by this URL > possibly related, when selecting 'Filter All' instead, I'm getting a 500 with > as message: > Problem accessing /system/console/bundles/.json. Reason: > Invalid LDAP filter specified -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4800) Bundle search in /system/console/bundles produces 405
David Bosschaert created FELIX-4800: --- Summary: Bundle search in /system/console/bundles produces 405 Key: FELIX-4800 URL: https://issues.apache.org/jira/browse/FELIX-4800 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-4.2.4 Reporter: David Bosschaert Searching in the bundles list produces a 405. Enter any value in the bundle search box and hit 'Apply Filter' and it will produce a 405 with as reason: HTTP method POST is not supported by this URL possibly related, when selecting 'Filter All' instead, I'm getting a 500 with as message: Problem accessing /system/console/bundles/.json. Reason: Invalid LDAP filter specified -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4793) Components with an empty configuration are created even if configuration is required or available
[ https://issues.apache.org/jira/browse/FELIX-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4793. - Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revision&revision=1658933 > Components with an empty configuration are created even if configuration is > required or available > - > > Key: FELIX-4793 > URL: https://issues.apache.org/jira/browse/FELIX-4793 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: scr-2.0.0 > > > We have a component which has one or more factory configurations in config > admin. > If the configuration policy is set to required, an instance is created > nevertheless with an empty configuration. > Similar, if the policy is optional there is a factory configuration in Config > Admin, two instances are created and both are kept active. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4412) Add Provide-Capability for declarative services bundle
[ https://issues.apache.org/jira/browse/FELIX-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307256#comment-14307256 ] David Bosschaert commented on FELIX-4412: - I also added the osgi.implementation capability which DS 1.3 implementations will need to have too. > Add Provide-Capability for declarative services bundle > -- > > Key: FELIX-4412 > URL: https://issues.apache.org/jira/browse/FELIX-4412 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.8.0 >Reporter: Alex Blewitt >Assignee: David Jencks >Priority: Minor > Fix For: scr-2.0.0 > > > To allow bundles to declare that they need declarative services, a > Provide-Capability should be defined on the DS bundle such that clients can > depend on it, for example: > Provide-Capability: > osgi.extender;osgi.extender="osgi.service.component";version:=1.1.0 > This would allow clients to require that there be a Declarative Services > bundle without actually declaring a package dependency: > Require-Capability: > osgi.extender;filter:="(&(osgi.extender=osgi.service.component")(version>1.0.0))" > The name of the declarative services component isn't well defined but > osgi.service.component or osgi.declarative.services might be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4789) SCR Felix4188Test fails when run with framework 4.4.1 or newer
[
https://issues.apache.org/jira/browse/FELIX-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4789.
-
Resolution: Fixed
Fix Version/s: scr-2.0.0
Fixed in http://svn.apache.org/viewvc?view=revision&revision=1657569
> SCR Felix4188Test fails when run with framework 4.4.1 or newer
> --
>
> Key: FELIX-4789
> URL: https://issues.apache.org/jira/browse/FELIX-4789
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: scr-2.0.0
>
>
> By default the SCR tests are run with Felix 4.0.2. When using a newer
> framework implementation (e.g. 4.4.1 or 4.6.0) the following failure starts
> appearing.
> BTW I didn't try it with any framework earlier than 4.4.1, so this failure
> might have been introduced before this version.
> The test fails as follows:
> {noformat}---
> Test set: org.apache.felix.scr.integration.Felix4188Test
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.916 sec <<<
> FAILURE!
> test_concurrent_deactivation(org.apache.felix.scr.integration.Felix4188Test)
> Time elapsed: 0.912 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.felix.scr.integration.ComponentTestBase.getServiceFromConfiguration(ComponentTestBase.java:380)
> at
> org.apache.felix.scr.integration.Felix4188Test.test_concurrent_deactivation(Felix4188Test.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:123)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:96)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:420)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:393)
> at sun.reflect.NativeMethodAcce
[jira] [Commented] (FELIX-4789) SCR Felix4188Test fails when run with framework 4.4.1 or newer
[
https://issues.apache.org/jira/browse/FELIX-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307221#comment-14307221
]
David Bosschaert commented on FELIX-4789:
-
The service that the test is looking for is in a different class space,
therefore the test (which uses getServiceReferences()) does not see it.
> SCR Felix4188Test fails when run with framework 4.4.1 or newer
> --
>
> Key: FELIX-4789
> URL: https://issues.apache.org/jira/browse/FELIX-4789
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>
> By default the SCR tests are run with Felix 4.0.2. When using a newer
> framework implementation (e.g. 4.4.1 or 4.6.0) the following failure starts
> appearing.
> BTW I didn't try it with any framework earlier than 4.4.1, so this failure
> might have been introduced before this version.
> The test fails as follows:
> {noformat}---
> Test set: org.apache.felix.scr.integration.Felix4188Test
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.916 sec <<<
> FAILURE!
> test_concurrent_deactivation(org.apache.felix.scr.integration.Felix4188Test)
> Time elapsed: 0.912 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.felix.scr.integration.ComponentTestBase.getServiceFromConfiguration(ComponentTestBase.java:380)
> at
> org.apache.felix.scr.integration.Felix4188Test.test_concurrent_deactivation(Felix4188Test.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:123)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:96)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:420)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:39
[jira] [Assigned] (FELIX-4789) SCR Felix4188Test fails when run with framework 4.4.1 or newer
[
https://issues.apache.org/jira/browse/FELIX-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-4789:
---
Assignee: David Bosschaert
> SCR Felix4188Test fails when run with framework 4.4.1 or newer
> --
>
> Key: FELIX-4789
> URL: https://issues.apache.org/jira/browse/FELIX-4789
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>
> By default the SCR tests are run with Felix 4.0.2. When using a newer
> framework implementation (e.g. 4.4.1 or 4.6.0) the following failure starts
> appearing.
> BTW I didn't try it with any framework earlier than 4.4.1, so this failure
> might have been introduced before this version.
> The test fails as follows:
> {noformat}---
> Test set: org.apache.felix.scr.integration.Felix4188Test
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.916 sec <<<
> FAILURE!
> test_concurrent_deactivation(org.apache.felix.scr.integration.Felix4188Test)
> Time elapsed: 0.912 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.felix.scr.integration.ComponentTestBase.getServiceFromConfiguration(ComponentTestBase.java:380)
> at
> org.apache.felix.scr.integration.Felix4188Test.test_concurrent_deactivation(Felix4188Test.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:123)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:96)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:420)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[jira] [Work started] (FELIX-4789) SCR Felix4188Test fails when run with framework 4.4.1 or newer
[
https://issues.apache.org/jira/browse/FELIX-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4789 started by David Bosschaert.
---
> SCR Felix4188Test fails when run with framework 4.4.1 or newer
> --
>
> Key: FELIX-4789
> URL: https://issues.apache.org/jira/browse/FELIX-4789
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>
> By default the SCR tests are run with Felix 4.0.2. When using a newer
> framework implementation (e.g. 4.4.1 or 4.6.0) the following failure starts
> appearing.
> BTW I didn't try it with any framework earlier than 4.4.1, so this failure
> might have been introduced before this version.
> The test fails as follows:
> {noformat}---
> Test set: org.apache.felix.scr.integration.Felix4188Test
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.916 sec <<<
> FAILURE!
> test_concurrent_deactivation(org.apache.felix.scr.integration.Felix4188Test)
> Time elapsed: 0.912 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.felix.scr.integration.ComponentTestBase.getServiceFromConfiguration(ComponentTestBase.java:380)
> at
> org.apache.felix.scr.integration.Felix4188Test.test_concurrent_deactivation(Felix4188Test.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:123)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:96)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:420)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> su
[jira] [Resolved] (FELIX-4790) SCR MutablePropertiesTest fails when run with framework 4.6.0
[ https://issues.apache.org/jira/browse/FELIX-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4790. - Resolution: Fixed Fix Version/s: scr-2.0.0 Fixed in http://svn.apache.org/viewvc?view=revision&revision=1657558 > SCR MutablePropertiesTest fails when run with framework 4.6.0 > - > > Key: FELIX-4790 > URL: https://issues.apache.org/jira/browse/FELIX-4790 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: scr-2.0.0 > > > When running the SCR integration tests with Felix 4.6.0 the > MutablePropertiesTest starts failing. With Felix 4.4.1 it is working fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4790) SCR MutablePropertiesTest fails when run with framework 4.6.0
[ https://issues.apache.org/jira/browse/FELIX-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307166#comment-14307166 ] David Bosschaert commented on FELIX-4790: - The problem is caused by the fact that the test is based on counting the number of properties on a service. This is a bad idea since the framework may add more properties to the service over time. This is exactly what happened with the R6 framework where the service.scope and service.bundleid properties are added to the service properties. This messes up the accounting in this test. > SCR MutablePropertiesTest fails when run with framework 4.6.0 > - > > Key: FELIX-4790 > URL: https://issues.apache.org/jira/browse/FELIX-4790 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > > When running the SCR integration tests with Felix 4.6.0 the > MutablePropertiesTest starts failing. With Felix 4.4.1 it is working fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (FELIX-4790) SCR MutablePropertiesTest fails when run with framework 4.6.0
[ https://issues.apache.org/jira/browse/FELIX-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4790 started by David Bosschaert. --- > SCR MutablePropertiesTest fails when run with framework 4.6.0 > - > > Key: FELIX-4790 > URL: https://issues.apache.org/jira/browse/FELIX-4790 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > > When running the SCR integration tests with Felix 4.6.0 the > MutablePropertiesTest starts failing. With Felix 4.4.1 it is working fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4790) SCR MutablePropertiesTest fails when run with framework 4.6.0
David Bosschaert created FELIX-4790: --- Summary: SCR MutablePropertiesTest fails when run with framework 4.6.0 Key: FELIX-4790 URL: https://issues.apache.org/jira/browse/FELIX-4790 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-2.0.0 Reporter: David Bosschaert Assignee: David Bosschaert When running the SCR integration tests with Felix 4.6.0 the MutablePropertiesTest starts failing. With Felix 4.4.1 it is working fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4789) SCR Felix4188Test fails when run with framework 4.4.1 or newer
[
https://issues.apache.org/jira/browse/FELIX-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4789:
Affects Version/s: scr-2.0.0
> SCR Felix4188Test fails when run with framework 4.4.1 or newer
> --
>
> Key: FELIX-4789
> URL: https://issues.apache.org/jira/browse/FELIX-4789
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.0
>Reporter: David Bosschaert
>
> By default the SCR tests are run with Felix 4.0.2. When using a newer
> framework implementation (e.g. 4.4.1 or 4.6.0) the following failure starts
> appearing.
> BTW I didn't try it with any framework earlier than 4.4.1, so this failure
> might have been introduced before this version.
> The test fails as follows:
> {noformat}---
> Test set: org.apache.felix.scr.integration.Felix4188Test
> ---
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.916 sec <<<
> FAILURE!
> test_concurrent_deactivation(org.apache.felix.scr.integration.Felix4188Test)
> Time elapsed: 0.912 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.felix.scr.integration.ComponentTestBase.getServiceFromConfiguration(ComponentTestBase.java:380)
> at
> org.apache.felix.scr.integration.Felix4188Test.test_concurrent_deactivation(Felix4188Test.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at
> org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:123)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:96)
> at
> org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:420)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAc
[jira] [Created] (FELIX-4789) SCR Felix4188Test fails when run with framework 4.4.1 or newer
David Bosschaert created FELIX-4789:
---
Summary: SCR Felix4188Test fails when run with framework 4.4.1 or
newer
Key: FELIX-4789
URL: https://issues.apache.org/jira/browse/FELIX-4789
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Reporter: David Bosschaert
By default the SCR tests are run with Felix 4.0.2. When using a newer framework
implementation (e.g. 4.4.1 or 4.6.0) the following failure starts appearing.
BTW I didn't try it with any framework earlier than 4.4.1, so this failure
might have been introduced before this version.
The test fails as follows:
{noformat}---
Test set: org.apache.felix.scr.integration.Felix4188Test
---
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.916 sec <<<
FAILURE!
test_concurrent_deactivation(org.apache.felix.scr.integration.Felix4188Test)
Time elapsed: 0.912 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at
org.apache.felix.scr.integration.ComponentTestBase.getServiceFromConfiguration(ComponentTestBase.java:380)
at
org.apache.felix.scr.integration.Felix4188Test.test_concurrent_deactivation(Felix4188Test.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:123)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:96)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:420)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:393)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport
[jira] [Resolved] (FELIX-4785) Incompatible SCR API
[ https://issues.apache.org/jira/browse/FELIX-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4785. - Resolution: Fixed Thanks [~pderop] that fixes it! I've committed the fix plus the extra service being registered in http://svn.apache.org/viewvc?view=revision&revision=1657539 > Incompatible SCR API > > > Key: FELIX-4785 > URL: https://issues.apache.org/jira/browse/FELIX-4785 > Project: Felix > Issue Type: Bug >Affects Versions: scr-2.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: scr-2.0.0 > > > Current trunk contains version 2.0.0 of the org.apache.felix.scr API package. > While this is a logical step, this makes the new implementation unusable as a > drop-in replacement into existing installations which might use the 1.x > version of that API. > I think we should go a more moderate way, leave the 1.x version in but > deprecate it and also provide the replacement API (if any). Then in one of > the further versions along the road, we can remove the API. This gives our > users a chance to migrate slowly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4785) Incompatible SCR API
[ https://issues.apache.org/jira/browse/FELIX-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303414#comment-14303414 ] David Bosschaert commented on FELIX-4785: - I also noticed that the bundle version is currently still at 1.8.3-SNAPSHOT. This should probably make a bigger jump given the changes... > Incompatible SCR API > > > Key: FELIX-4785 > URL: https://issues.apache.org/jira/browse/FELIX-4785 > Project: Felix > Issue Type: Bug >Affects Versions: scr-2.0.0 >Reporter: Carsten Ziegeler > Fix For: scr-2.0.0 > > > Current trunk contains version 2.0.0 of the org.apache.felix.scr API package. > While this is a logical step, this makes the new implementation unusable as a > drop-in replacement into existing installations which might use the 1.x > version of that API. > I think we should go a more moderate way, leave the 1.x version in but > deprecate it and also provide the replacement API (if any). Then in one of > the further versions along the road, we can remove the API. This gives our > users a chance to migrate slowly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4764) Add support to GZIP based compact index files
[ https://issues.apache.org/jira/browse/FELIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282843#comment-14282843 ] David Bosschaert commented on FELIX-4764: - Hi Christiano, Thanks for the patch. Would you be able to provide a unit test with it as well? Thanks, David > Add support to GZIP based compact index files > - > > Key: FELIX-4764 > URL: https://issues.apache.org/jira/browse/FELIX-4764 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-2.0.2 >Reporter: Cristiano Gavião >Assignee: David Bosschaert > > OSGi Alliance Repoindex tool uses the GZIP format for its compacted index > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4764) Add support to GZIP based compact index files
[ https://issues.apache.org/jira/browse/FELIX-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-4764: --- Assignee: David Bosschaert > Add support to GZIP based compact index files > - > > Key: FELIX-4764 > URL: https://issues.apache.org/jira/browse/FELIX-4764 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-2.0.2 >Reporter: Cristiano Gavião >Assignee: David Bosschaert > > OSGi Alliance Repoindex tool uses the GZIP format for its compacted index > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4502) [Core R6] Provide an OSGi R6 compliant framework implementation
[ https://issues.apache.org/jira/browse/FELIX-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4502. - Resolution: Fixed > [Core R6] Provide an OSGi R6 compliant framework implementation > --- > > Key: FELIX-4502 > URL: https://issues.apache.org/jira/browse/FELIX-4502 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert > Fix For: framework-4.6.0 > > > OSGi Core R6 compliance needs to be provided. > This is an umbrella issue to track the necessary tasks to make Felix R6 > compliant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4583) [Core R6] Ensure that all OSGi Core R6 CT tests pass
[ https://issues.apache.org/jira/browse/FELIX-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4583. - Resolution: Fixed > [Core R6] Ensure that all OSGi Core R6 CT tests pass > > > Key: FELIX-4583 > URL: https://issues.apache.org/jira/browse/FELIX-4583 > Project: Felix > Issue Type: Sub-task > Components: Framework >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4726) [Core R6] Update bundle and service hooks for the system bundle
[ https://issues.apache.org/jira/browse/FELIX-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4726. - Resolution: Fixed Changes for bundle hooks are done in http://svn.apache.org/viewvc?view=revision&revision=1644574 > [Core R6] Update bundle and service hooks for the system bundle > --- > > Key: FELIX-4726 > URL: https://issues.apache.org/jira/browse/FELIX-4726 > Project: Felix > Issue Type: Sub-task > Components: Framework >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > > The Core R6 spec has updates around Bundle and Service Hook behaviour in > relation to the system bundle. The Felix framework needs to be updated for > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4726) [Core R6] Update bundle and service hooks for the system bundle
[ https://issues.apache.org/jira/browse/FELIX-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242252#comment-14242252 ] David Bosschaert commented on FELIX-4726: - Changes for service hooks are done in http://svn.apache.org/viewvc?view=revision&revision=1644564 > [Core R6] Update bundle and service hooks for the system bundle > --- > > Key: FELIX-4726 > URL: https://issues.apache.org/jira/browse/FELIX-4726 > Project: Felix > Issue Type: Sub-task > Components: Framework >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > > The Core R6 spec has updates around Bundle and Service Hook behaviour in > relation to the system bundle. The Felix framework needs to be updated for > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (FELIX-4726) [Core R6] Update bundle and service hooks for the system bundle
[ https://issues.apache.org/jira/browse/FELIX-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4726 started by David Bosschaert. --- > [Core R6] Update bundle and service hooks for the system bundle > --- > > Key: FELIX-4726 > URL: https://issues.apache.org/jira/browse/FELIX-4726 > Project: Felix > Issue Type: Sub-task > Components: Framework >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > > The Core R6 spec has updates around Bundle and Service Hook behaviour in > relation to the system bundle. The Felix framework needs to be updated for > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4503) [Core R6] Support osgi.native capability
[ https://issues.apache.org/jira/browse/FELIX-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241252#comment-14241252 ] David Bosschaert commented on FELIX-4503: - Hi Bob, I'm not sure what the background of those Java 6 failures with native code are, maybe Richard remembers, but I guess you could try it with Java 5 and/or 7. When I ran the CT I used Java 7, so that might have cause some of these failures above... > [Core R6] Support osgi.native capability > > > Key: FELIX-4503 > URL: https://issues.apache.org/jira/browse/FELIX-4503 > Project: Felix > Issue Type: Sub-task > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: Bob Paulin > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4726) [Core R6] Update bundle and service hooks for the system bundle
David Bosschaert created FELIX-4726: --- Summary: [Core R6] Update bundle and service hooks for the system bundle Key: FELIX-4726 URL: https://issues.apache.org/jira/browse/FELIX-4726 Project: Felix Issue Type: Sub-task Components: Framework Reporter: David Bosschaert Assignee: David Bosschaert Fix For: framework-4.6.0 The Core R6 spec has updates around Bundle and Service Hook behaviour in relation to the system bundle. The Felix framework needs to be updated for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (FELIX-4503) [Core R6] Support osgi.native capability
[ https://issues.apache.org/jira/browse/FELIX-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reopened FELIX-4503: - I'm reopening this issue because in the Core R6 CT there are a lot of failures around native code, which I'm guessing relate to this issue: The following tests in DivTests fail: testNativeCode() testNativeCodeFilterOptional() testNativeCodeFilterNoOptional() testNativeCodeFilterAlias() testNativeCodeFragment() testNativeCodeLanguage() testNativeCodeLanguageSuccess() testNativeCodeVersion() testNativeCodeVersionSuccess() testNativeCodeNamespaceRequirement() testNativeCodeNamespaceCapability() Bob, would you have a moment to take a look? > [Core R6] Support osgi.native capability > > > Key: FELIX-4503 > URL: https://issues.apache.org/jira/browse/FELIX-4503 > Project: Felix > Issue Type: Sub-task > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: Bob Paulin > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4583) [Core R6] Ensure that all OSGi Core R6 CT tests pass
[ https://issues.apache.org/jira/browse/FELIX-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241207#comment-14241207 ] David Bosschaert commented on FELIX-4583: - There is one known deviation in the Core R6 CT: DTOTestCase.testArrayServiceReferenceDTO() fails, but the implementation in Felix is actually correct. > [Core R6] Ensure that all OSGi Core R6 CT tests pass > > > Key: FELIX-4583 > URL: https://issues.apache.org/jira/browse/FELIX-4583 > Project: Felix > Issue Type: Sub-task > Components: Framework >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4502) [Core R6] Provide an OSGi R6 compliant framework implementation
[ https://issues.apache.org/jira/browse/FELIX-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-4502: Assignee: (was: David Bosschaert) > [Core R6] Provide an OSGi R6 compliant framework implementation > --- > > Key: FELIX-4502 > URL: https://issues.apache.org/jira/browse/FELIX-4502 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert > Fix For: framework-4.6.0 > > > OSGi Core R6 compliance needs to be provided. > This is an umbrella issue to track the necessary tasks to make Felix R6 > compliant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (FELIX-4583) [Core R6] Ensure that all OSGi Core R6 CT tests pass
[ https://issues.apache.org/jira/browse/FELIX-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4583 started by David Bosschaert. --- > [Core R6] Ensure that all OSGi Core R6 CT tests pass > > > Key: FELIX-4583 > URL: https://issues.apache.org/jira/browse/FELIX-4583 > Project: Felix > Issue Type: Sub-task > Components: Framework >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4502) [Core R6] Provide an OSGi R6 compliant framework implementation
[ https://issues.apache.org/jira/browse/FELIX-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-4502: --- Assignee: David Bosschaert > [Core R6] Provide an OSGi R6 compliant framework implementation > --- > > Key: FELIX-4502 > URL: https://issues.apache.org/jira/browse/FELIX-4502 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > > OSGi Core R6 compliance needs to be provided. > This is an umbrella issue to track the necessary tasks to make Felix R6 > compliant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4583) [Core R6] Ensure that all OSGi Core R6 CT tests pass
[ https://issues.apache.org/jira/browse/FELIX-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-4583: --- Assignee: David Bosschaert > [Core R6] Ensure that all OSGi Core R6 CT tests pass > > > Key: FELIX-4583 > URL: https://issues.apache.org/jira/browse/FELIX-4583 > Project: Felix > Issue Type: Sub-task > Components: Framework >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (FELIX-4502) [Core R6] Provide an OSGi R6 compliant framework implementation
[ https://issues.apache.org/jira/browse/FELIX-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4502 started by David Bosschaert. --- > [Core R6] Provide an OSGi R6 compliant framework implementation > --- > > Key: FELIX-4502 > URL: https://issues.apache.org/jira/browse/FELIX-4502 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > > OSGi Core R6 compliance needs to be provided. > This is an umbrella issue to track the necessary tasks to make Felix R6 > compliant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4502) [Core R6] Provide an OSGi R6 compliant framework implementation
[ https://issues.apache.org/jira/browse/FELIX-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-4502: Assignee: (was: Karl Pauls) > [Core R6] Provide an OSGi R6 compliant framework implementation > --- > > Key: FELIX-4502 > URL: https://issues.apache.org/jira/browse/FELIX-4502 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert > Fix For: framework-4.6.0 > > > OSGi Core R6 compliance needs to be provided. > This is an umbrella issue to track the necessary tasks to make Felix R6 > compliant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4579) [Core R6] Support Framework Extension Bundle Activators
[
https://issues.apache.org/jira/browse/FELIX-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4579:
Assignee: Karl Pauls
> [Core R6] Support Framework Extension Bundle Activators
> ---
>
> Key: FELIX-4579
> URL: https://issues.apache.org/jira/browse/FELIX-4579
> Project: Felix
> Issue Type: Sub-task
> Components: Framework
>Reporter: David Bosschaert
>Assignee: Karl Pauls
> Fix For: framework-4.6.0
>
>
> See section 3.15.3 of the Core R6 spec for details.
> The manifest header for these activators is:
> {{ExtensionBundle-Activator: com.acme.Activator}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4502) [Core R6] Provide an OSGi R6 compliant framework implementation
[ https://issues.apache.org/jira/browse/FELIX-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-4502: Assignee: Karl Pauls > [Core R6] Provide an OSGi R6 compliant framework implementation > --- > > Key: FELIX-4502 > URL: https://issues.apache.org/jira/browse/FELIX-4502 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: Karl Pauls > Fix For: framework-4.6.0 > > > OSGi Core R6 compliance needs to be provided. > This is an umbrella issue to track the necessary tasks to make Felix R6 > compliant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4579) [Core R6] Support Framework Extension Bundle Activators
[
https://issues.apache.org/jira/browse/FELIX-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4579:
Assignee: (was: David Bosschaert)
> [Core R6] Support Framework Extension Bundle Activators
> ---
>
> Key: FELIX-4579
> URL: https://issues.apache.org/jira/browse/FELIX-4579
> Project: Felix
> Issue Type: Sub-task
> Components: Framework
>Reporter: David Bosschaert
> Fix For: framework-4.6.0
>
>
> See section 3.15.3 of the Core R6 spec for details.
> The manifest header for these activators is:
> {{ExtensionBundle-Activator: com.acme.Activator}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4370) Support Repository service as defined by OSGi spec
[
https://issues.apache.org/jira/browse/FELIX-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217601#comment-14217601
]
David Bosschaert commented on FELIX-4370:
-
Hi Enrique,
To install a public repository server, you might take the Felix Repository and
run it as a central remote server. For this is needs a remote version of the
OSGi Repository service, which I'm not sure it is implemented by anyone yet.
But it should not be hard to do.
What does work today to run the Felix Repository locally and feed it with a
repository.xml file that is made accessible centrally in your system, simply
via a URL.
Publishing bundles into a repository is a matter of feeding it additional
repository.xml files, or using another repository-specific API. If you're using
gogo, the 'obr:repos add' command does this for you.
On generating the R5 indexes. Repoindex does this. This project has recently
moved to https://github.com/bndtools/bnd I was looking for some documentation
around it but couldn't find it (https://github.com/bndtools/bnd/issues/695). I
have found out that if you run {{../gradlew}} in the
{{org.osgi.impl.bundle.repoindex.cli}} directory it will build the repoindex
binary in the {{generated}} directory.
> Support Repository service as defined by OSGi spec
> --
>
> Key: FELIX-4370
> URL: https://issues.apache.org/jira/browse/FELIX-4370
> Project: Felix
> Issue Type: Sub-task
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-1.6.6
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.2
>
>
> This API described in section 132.8.4 and throughout chapter 132.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (FELIX-4579) [Core R6] Support Framework Extension Bundle Activators
[
https://issues.apache.org/jira/browse/FELIX-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reopened FELIX-4579:
-
I'm reopening this issue as the OSGi CT reports quite a few issues that needs
to be addressed around this.
> [Core R6] Support Framework Extension Bundle Activators
> ---
>
> Key: FELIX-4579
> URL: https://issues.apache.org/jira/browse/FELIX-4579
> Project: Felix
> Issue Type: Sub-task
> Components: Framework
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-4.6.0
>
>
> See section 3.15.3 of the Core R6 spec for details.
> The manifest header for these activators is:
> {{ExtensionBundle-Activator: com.acme.Activator}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4579) [Core R6] Support Framework Extension Bundle Activators
[
https://issues.apache.org/jira/browse/FELIX-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4579.
-
Resolution: Fixed
Fix in http://svn.apache.org/viewvc?view=revision&revision=1640381
> [Core R6] Support Framework Extension Bundle Activators
> ---
>
> Key: FELIX-4579
> URL: https://issues.apache.org/jira/browse/FELIX-4579
> Project: Felix
> Issue Type: Sub-task
> Components: Framework
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-4.6.0
>
>
> See section 3.15.3 of the Core R6 spec for details.
> The manifest header for these activators is:
> {{ExtensionBundle-Activator: com.acme.Activator}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FELIX-4579) [Core R6] Support Framework Extension Bundle Activators
[
https://issues.apache.org/jira/browse/FELIX-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-4579:
---
Assignee: David Bosschaert
> [Core R6] Support Framework Extension Bundle Activators
> ---
>
> Key: FELIX-4579
> URL: https://issues.apache.org/jira/browse/FELIX-4579
> Project: Felix
> Issue Type: Sub-task
> Components: Framework
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-4.6.0
>
>
> See section 3.15.3 of the Core R6 spec for details.
> The manifest header for these activators is:
> {{ExtensionBundle-Activator: com.acme.Activator}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4504) [Core R6] Support Framework DTOs
[ https://issues.apache.org/jira/browse/FELIX-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4504. - Resolution: Fixed Fixed in svn.apache.org/viewvc?view=revision&revision=1640076 > [Core R6] Support Framework DTOs > > > Key: FELIX-4504 > URL: https://issues.apache.org/jira/browse/FELIX-4504 > Project: Felix > Issue Type: Sub-task > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (FELIX-4504) [Core R6] Support Framework DTOs
[ https://issues.apache.org/jira/browse/FELIX-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4504 started by David Bosschaert. --- > [Core R6] Support Framework DTOs > > > Key: FELIX-4504 > URL: https://issues.apache.org/jira/browse/FELIX-4504 > Project: Felix > Issue Type: Sub-task > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4504) [Core R6] Support Framework DTOs
[ https://issues.apache.org/jira/browse/FELIX-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-4504: --- Assignee: David Bosschaert > [Core R6] Support Framework DTOs > > > Key: FELIX-4504 > URL: https://issues.apache.org/jira/browse/FELIX-4504 > Project: Felix > Issue Type: Sub-task > Components: Framework >Affects Versions: framework-4.4.0 >Reporter: David Bosschaert >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4670:
Fix Version/s: http-2.3.2
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Fix For: http-2.3.2
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireServiceEvent(EventDispatcher.java:543(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4401(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.access$000(Felix.java:74(Compiled Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:390(Compiled
> Code))
> 4XESTACKTRA
[jira] [Resolved] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4670.
-
Resolution: Fixed
Resolved in http://svn.apache.org/viewvc?view=revision&revision=1632257
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireServiceEvent(EventDispatcher.java:543(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4401(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.access$000(Felix.java:74(Compiled Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:390(C
[jira] [Commented] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14173501#comment-14173501
]
David Bosschaert commented on FELIX-4670:
-
I've removed the attachments as I've made a few tiny tweaks and added unit
tests. If nobody complains I'll commit this soon.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireServiceEvent(EventDispatcher.java:543(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4401(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.access$000(Felix.java:74(Compiled Code))
> 4XESTACKTRACE
[jira] [Updated] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4670:
Attachment: (was: felix-4670.diff)
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireServiceEvent(EventDispatcher.java:543(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4401(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.access$000(Felix.java:74(Compiled Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:390(Compiled
> Code))
> 4XESTACKTRACEat
>
[jira] [Updated] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4670:
Attachment: (was: felix_4670_alt.diff)
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireServiceEvent(EventDispatcher.java:543(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4401(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.access$000(Felix.java:74(Compiled Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:390(Compiled
> Code))
> 4XESTACKTRACEa
[jira] [Comment Edited] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14173461#comment-14173461
]
David Bosschaert edited comment on FELIX-4670 at 10/16/14 7:08 AM:
---
[~jajans]
bq. A trick you could use is wrapping the actual servlet in an adapter class
that simply delegates all calls directly to the real servlet, but allows you to
add an additional method that returns whether or not init() has been called.
IIRC, this is also how Jetty does this.
Then you still need to keep track of what wrapper belongs to what servlet. User
code simply calls registerServlet() with the bare servlet, so you'd have to be
able to find the wrapper if you created before.
I think a slightly simpler solution would be to simply keep track of the
servlets that have been inited in the HandlerRegistry. I think it can be done
without synchronization but I wonder whether it's really worth the effort since
registering the same servlet instance is an error condition and an exception is
thrown directly after anyway.
was (Author: bosschaert):
[~jajans]
bq. A trick you could use is wrapping the actual servlet in an adapter class
that simply delegates all calls directly to the real servlet, but allows you to
add an additional method that returns whether or not init() has been called.
IIRC, this is also how Jetty does this.
The you still need to keep track of what wrapper belongs to what servlet. User
code simply calls registerServlet() with the bare servlet, so you'd have to be
able to find the wrapper if you created before.
I think a slightly simpler solution would be to simply keep track of the
servlets that have been inited in the HandlerRegistry. I think it can be done
without synchronization but I wonder whether it's really worth the effort since
registering the same servlet instance is an error condition and an exception is
thrown directly after anyway.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff, felix_4670_alt.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whi
[jira] [Commented] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14173461#comment-14173461
]
David Bosschaert commented on FELIX-4670:
-
[~jajans]
bq. A trick you could use is wrapping the actual servlet in an adapter class
that simply delegates all calls directly to the real servlet, but allows you to
add an additional method that returns whether or not init() has been called.
IIRC, this is also how Jetty does this.
The you still need to keep track of what wrapper belongs to what servlet. User
code simply calls registerServlet() with the bare servlet, so you'd have to be
able to find the wrapper if you created before.
I think a slightly simpler solution would be to simply keep track of the
servlets that have been inited in the HandlerRegistry. I think it can be done
without synchronization but I wonder whether it's really worth the effort since
registering the same servlet instance is an error condition and an exception is
thrown directly after anyway.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff, felix_4670_alt.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/Servic
[jira] [Commented] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14173457#comment-14173457
]
David Bosschaert commented on FELIX-4670:
-
[~cziegeler]
bq. I assume there is a clash if two servlets try to register for the same
path. The first one succeeds, the second one fails. If now the first one is
unregistered, is the second one registered?
The second one will receive an exception on registration. That should be enough
for the registering agent to know that it failed :) There's no automatic retry
in case the first one is removed. Or is that not what you meant?
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff, felix_4670_alt.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACE
[jira] [Commented] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172890#comment-14172890
]
David Bosschaert commented on FELIX-4670:
-
bq. I'll put some code in that makes sure that init() doesn't get called
multiple times without destroy in between.
Actually, that piece turns out to be quite tricky, as you don't know from a
Servlet itself whether it has been inited, which means you need to add
synchronization again to check this in a separate datastructure, and the
synchronization was what we were trying to remove.
So I think that there is a risk that init() gets called more than once if
someone tries to add the actual same servlet twice, but that is an error
condition anyway and an exception will get thrown, so I think it might be ok to
leave it at that.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff, felix_4670_alt.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatc
[jira] [Commented] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172832#comment-14172832
]
David Bosschaert commented on FELIX-4670:
-
I thought a little more about doing a get() call before doing the init() but I
think there is an issue with that. Basically there is a window of opportunity
where a servlet is removed between that get() call and the putIfAbsent() which
means that a servlet/filter may not get added even though the alias/servlet (or
filter) isn't there.
Therefore I think it might be better to not do the additional get() and simply
do the atomic putIfAbsent(). I'll put some code in that makes sure that init()
doesn't get called multiple times without destroy in between.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff, felix_4670_alt.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apac
[jira] [Commented] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14172324#comment-14172324
]
David Bosschaert commented on FELIX-4670:
-
bq. What about doing a get() call on the concurrent map before doing
handler.init() ? If get returns something, you can skip the rest. Otherwise you
do the optimistic init(), putIfAbsent() stuff
Right so that might save you from some unnecessary inits. There is still a
theoretic possibility that someone else adds the servlet/filter between doing
that get() and the putIfAbsent(), so I think that code should stay there but an
additional get in front might be good as it should catch >99% of the cases.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff, felix_4670_alt.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmed
[jira] [Updated] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4670:
Attachment: felix_4670_alt.diff
After some further feedback I have come up with an alternative implementation
(felix_4680_alt.diff) that does not involve separate threads. It removes the
need for synchronization on the HandlerRegistry, one of the locks in this
deadlock.
This is done by using concurrent maps. Note that the atomicity to ConcurrentMap
is only guaranteed per single call, therefore I had to move handler.init() in
the add methods to before the putIfAbsent call. An optimistic approach if you
like. However this means that if the handler cannot be added an extra destroy()
call was needed.
What do people think? Is this a better approach than with the threading? If
there is consensus that this is a better idea I'll also provide unit tests.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff, felix_4670_alt.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/
[jira] [Work started] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4670 started by David Bosschaert.
---
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireServiceEvent(EventDispatcher.java:543(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4401(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.access$000(Felix.java:74(Compiled Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:390(Compiled
> Code))
> 4XESTACKTRACE
[jira] [Updated] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4670:
Attachment: felix-4670.diff
This patch processes the handling of the tracker callbacks in a separate thread
which should break the deadlock.
The patch also brings the use of trackers in line with what the OSGi spec says
in section 701.2.5:
bq. Trackers use synchronous listeners; the callbacks are called on the same
thread as that of the initiating event. Care should be taken to not linger in
the callback and perform non-trivial work. Callbacks should return immediately
and move substantial work to other threads.
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
> Attachments: felix-4670.diff
>
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTA
[jira] [Commented] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171118#comment-14171118
]
David Bosschaert commented on FELIX-4670:
-
If I look at the latest codebase, the APIs are slightly different
(ExtenderManager.remove() has been replaced by ExtenderManager.removeServlet())
but in essence the locks seem to be the same.
Both stack traces originate from the AbstractTracker (which calls down into
ServletTracker/FilterTracker). These then call
ExtenderManager.removeServlet()/removeFilter().
I'm wondering whether it would help putting the calls to ExtenderManager from
ServletTracker/FilterTracker in a separate thread. That would allow the
initiating threads to continue and potentially release the locks that they have
been holding on to. I guess there would not be any issues in relation to
processing these servlet events asynchronously (note that the Trackers are
synchronous in nature, see OSGi Tracker spec section 701.2.5).
Any other thoughts?
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
>
[jira] [Assigned] (FELIX-4670) Deadlock in Felix HTTP service
[
https://issues.apache.org/jira/browse/FELIX-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-4670:
---
Assignee: David Bosschaert
> Deadlock in Felix HTTP service
> --
>
> Key: FELIX-4670
> URL: https://issues.apache.org/jira/browse/FELIX-4670
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
> Environment: Websphere 7.0, IBM Java 6.0
>Reporter: Jörg Hoh
>Assignee: David Bosschaert
>
> When we startup our webapplication, we sometimes run into a deadlock:
> {code}
> 1LKDEADLOCKDeadlock detected !!!
> NULL -
> NULL
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> 3LKDEADLOCKWTRis waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFBBB61F20 infl_mon_t:
> 0x7FFFBBB61F90:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager@0x0001014B3650/0x0001014B365C:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "FelixStartLevel" (0x02156100)
> 3LKDEADLOCKWTRwhich is waiting for:
> 4LKDEADLOCKMON sys_mon_t:0x7FFFA340 infl_mon_t:
> 0x7FFFA3B0:
> 4LKDEADLOCKOBJ
> org/apache/felix/http/base/internal/handler/HandlerRegistry@0x0001070D6EA0/0x0001070D6EAC:
>
> 3LKDEADLOCKOWNwhich is owned by:
> 2LKDEADLOCKTHR Thread "server.startup : 1" (0x01DDC800)
> NULL
> {code}
> The stacktrace of these 2 threads as indicated by the javacore file:
> {code}
> 3XMTHREADINFO "FelixStartLevel" J9VMThread:0x02156100,
> j9thread_t:0x7FFFC938B4B0, java/lang/Thread:0x000101580260, state:B,
> prio=5
> 3XMJAVALTHREAD(java/lang/Thread getId:0x70, isDaemon:true)
> 3XMTHREADINFO1(native thread ID:0x5D3A, native priority:0x5,
> native policy:UNKNOWN)
> 3XMTHREADINFO2(native stack address range
> from:0x7FFFC530A000, to:0x7FFFC534B000, size:0x41000)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:140)
>
> 4XESTACKTRACEat
> org/apache/felix/http/base/internal/service/HttpServiceImpl.unregisterFilter(HttpServiceImpl.java:76)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:90)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/FilterMapping.unregister(FilterMapping.java:83)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.unregisterMapping(ExtenderManager.java:270)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.removeMapping(ExtenderManager.java:252)
>
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/manager/ExtenderManager.remove(ExtenderManager.java:183)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:48)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/FilterTracker.removed(FilterTracker.java:24)
> 4XESTACKTRACEat
> org/apache/felix/http/whiteboard/internal/tracker/AbstractTracker.removedService(AbstractTracker.java:52)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)
> 4XESTACKTRACEat
> org/osgi/util/tracker/AbstractTracked.untrack(AbstractTracked.java:341(Compiled
> Code))
> 4XESTACKTRACEat
> org/osgi/util/tracker/ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireEventImmediately(EventDispatcher.java:793(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/util/EventDispatcher.fireServiceEvent(EventDispatcher.java:543(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.fireServiceEvent(Felix.java:4401(Compiled
> Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix.access$000(Felix.java:74(Compiled Code))
> 4XESTACKTRACEat
> org/apache/felix/framework/Felix$1.serviceChanged(Felix.java:390(Compiled
> Code))
> 4XESTACKTRACEat
> org/
[jira] [Resolved] (FELIX-4654) NullPointerException in BundleWiringImpl.findClassOrResourceByDelegation()
[
https://issues.apache.org/jira/browse/FELIX-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4654.
-
Resolution: Fixed
Fix Version/s: framework-4.4.1
> NullPointerException in BundleWiringImpl.findClassOrResourceByDelegation()
> --
>
> Key: FELIX-4654
> URL: https://issues.apache.org/jira/browse/FELIX-4654
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-4.2.0
>Reporter: Dirk Rudolph
> Fix For: framework-4.4.1
>
>
> There is a potential NPE in the implementation of
> BundleWiringImpl.findClassOrResourceByDelegation(). When the Implementation
> tries to load a class using the classloader of the wiring null can be
> returned in case when the wiring has been disposed. I think in this case the
> null pointer should be handled properly instead of throwing an exception.
> {code}
> java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at
> org.bouncycastle.jcajce.provider.asymmetric.rsa.KeyFactorySpi.generatePublic(Unknown
> Source)
> at
> org.bouncycastle.jce.provider.BouncyCastleProvider.getPublicKey(Unknown
> Source)
> at
> org.bouncycastle.jce.provider.X509CertificateObject.getPublicKey(Unknown
> Source)
> at
> org.bouncycastle.operator.jcajce.JceAsymmetricKeyWrapper.(Unknown
> Source)
> at
> org.bouncycastle.cms.jcajce.JceKeyTransRecipientInfoGenerator.(Unknown
> Source)
> {code}
> Unfortunately this is really hard to reproduce. The problem occurs for me
> when I use Apache Sling in combination with javax.security and bouncycastle
> (everything installed as bundles) but in my eyes its not (only) related to
> that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4654) NullPointerException in BundleWiringImpl.findClassOrResourceByDelegation()
[
https://issues.apache.org/jira/browse/FELIX-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14148224#comment-14148224
]
David Bosschaert commented on FELIX-4654:
-
Thanks Dirk for reporting this issue. Looking at the the source code of 4.2.0
line 1472 the issue seems to be the following:
{code}result = (isClass)
? (Object) ((BundleClassLoader) getClassLoader()).findClass(name)
: (Object) m_revision.getResourceLocal(name);
{code}
getClassLoader() seems to return null, which can cause the NPE (m_revision
cannot be null as it's a final field).
Looking at the latest trunk, this issue seems to have been resolved there. The
relevant code on trunk is on lines start at 1512:
{code}if (isClass)
{
ClassLoader cl = getClassLoaderInternal();
if (cl == null)
{
throw new ClassNotFoundException(
"Unable to load class '"
+ name
+ "' because the bundle wiring for "
+ m_revision.getSymbolicName()
+ " is no longer valid.");
}
result = ((BundleClassLoader) cl).findClass(name);
}
else
{
result = m_revision.getResourceLocal(name);
}
{code}
So if the classloader cannot be found, a CNFE is thrown which should be picked
up by the classloader as an ordinary signal that the class isn't available.
Is there any chance that you could check this with the latest Felix?
> NullPointerException in BundleWiringImpl.findClassOrResourceByDelegation()
> --
>
> Key: FELIX-4654
> URL: https://issues.apache.org/jira/browse/FELIX-4654
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-4.2.0
>Reporter: Dirk Rudolph
>
> There is a potential NPE in the implementation of
> BundleWiringImpl.findClassOrResourceByDelegation(). When the Implementation
> tries to load a class using the classloader of the wiring null can be
> returned in case when the wiring has been disposed. I think in this case the
> null pointer should be handled properly instead of throwing an exception.
> {code}
> java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at
> org.bouncycastle.jcajce.provider.asymmetric.rsa.KeyFactorySpi.generatePublic(Unknown
> Source)
> at
> org.bouncycastle.jce.provider.BouncyCastleProvider.getPublicKey(Unknown
> Source)
> at
> org.bouncycastle.jce.provider.X509CertificateObject.getPublicKey(Unknown
> Source)
> at
> org.bouncycastle.operator.jcajce.JceAsymmetricKeyWrapper.(Unknown
> Source)
> at
> org.bouncycastle.cms.jcajce.JceKeyTransRecipientInfoGenerator.(Unknown
> Source)
> {code}
> Unfortunately this is really hard to reproduce. The problem occurs for me
> when I use Apache Sling in combination with javax.security and bouncycastle
> (everything installed as bundles) but in my eyes its not (only) related to
> that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4640) missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in org.apache.felix.framework
[
https://issues.apache.org/jira/browse/FELIX-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-4640.
-
Resolution: Fixed
Fixed in http://svn.apache.org/viewvc?view=revision&revision=1627285
[~jwausle] it would be great if you could double-check once more that this
fixes the issue for you.
> missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in
> org.apache.felix.framework
> -
>
> Key: FELIX-4640
> URL: https://issues.apache.org/jira/browse/FELIX-4640
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR), Framework
> Environment: any
>Reporter: Jan Winter
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.4
>
> Attachments: cap.diff
>
>
> When I try to deploy a bundle from a OBRepo occur the below error
> 'Unsatisfied requirement'.
> g! obr:deploy any.bundle
> Unsatisfied requirement(s):
> ---
>(&(osgi.ee=JavaSE)(version=1.8))
> I would expect that this capability will be provided by system-bundle.
> g! felix:inspect capability osgi.ee
> org.apache.felix.framework [0] provides:
>
> osgi.ee; OSGi/Minimum [1.0.0, 1.1.0, 1.2.0] [UNUSED]
> osgi.ee; JavaSE [1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0,
> 1.8.0]
> *My full runtime environment is.*
> g! lb
> START LEVEL 1
>ID|State |Level|Name
> 0|Active |0|System Bundle (4.4.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.2)
> 2|Active |1|bndlib (2.3.0.201405100607)
> 3|Active |1|biz.aQute.repository (2.1.0.062515_230REL)
> 4|Active |1|Java XML Streaming API (1.0.1.v201004272200)
> 5|Active |1|JAXP XML (1.3.4.v201005080400)
> 6|Active |1|Apache Felix Gogo Command (0.14.0)
> 7|Active |1|Apache Felix Gogo Runtime (0.12.1)
> 8|Active |1|Apache Felix Gogo Shell (0.10.0.v201212101605)
> I found one related fact in
> 'org.apache.felix.bundlerepository-2.0.2/org.apache.felix.bundlerepository.impl.LocalResourceImpl.java'.
> - declared 'osgi.ee' capabilities from framework-bundle will realized as
> 'ee=JavaSE-1.8' capability
> - but the filter require 1 spitted capability ( and
> ) '(&(osgi.ee=JavaSE)(version=1.8))'
> *Here the patch who works for me.*
> 85c85,86
> < cap.addProperty(Capability.EXECUTIONENVIRONMENT,
> tokens.nextToken().trim());
> ---
> > String eeValue = tokens.nextToken().trim();
> >
> > cap.addProperty(Capability.EXECUTIONENVIRONMENT, eeValue);
> 86a88,100
> >
> > String[] split = eeValue.split("-");
> > switch (split.length) {
> > case 2:
> > String osgi_ee = "osgi." +
> > Capability.EXECUTIONENVIRONMENT;
> > CapabilityImpl cap2 = new
> > CapabilityImpl(osgi_ee, new PropertyImpl[]{
> > new
> > PropertyImpl(osgi_ee, null, split[0]),
> > new
> > PropertyImpl("version", null, split[1])
> > });
> > addCapability(cap2);
> > break;
> > }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4640) missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in org.apache.felix.framework
[
https://issues.apache.org/jira/browse/FELIX-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14145367#comment-14145367
]
David Bosschaert commented on FELIX-4640:
-
bq. with a little hint: append for (..) { ... addCapability(bcap);}
doh! yes adding that would be useful. I hope you tested it with that addition :)
> missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in
> org.apache.felix.framework
> -
>
> Key: FELIX-4640
> URL: https://issues.apache.org/jira/browse/FELIX-4640
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR), Framework
> Environment: any
>Reporter: Jan Winter
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.4
>
> Attachments: cap.diff
>
>
> When I try to deploy a bundle from a OBRepo occur the below error
> 'Unsatisfied requirement'.
> g! obr:deploy any.bundle
> Unsatisfied requirement(s):
> ---
>(&(osgi.ee=JavaSE)(version=1.8))
> I would expect that this capability will be provided by system-bundle.
> g! felix:inspect capability osgi.ee
> org.apache.felix.framework [0] provides:
>
> osgi.ee; OSGi/Minimum [1.0.0, 1.1.0, 1.2.0] [UNUSED]
> osgi.ee; JavaSE [1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0,
> 1.8.0]
> *My full runtime environment is.*
> g! lb
> START LEVEL 1
>ID|State |Level|Name
> 0|Active |0|System Bundle (4.4.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.2)
> 2|Active |1|bndlib (2.3.0.201405100607)
> 3|Active |1|biz.aQute.repository (2.1.0.062515_230REL)
> 4|Active |1|Java XML Streaming API (1.0.1.v201004272200)
> 5|Active |1|JAXP XML (1.3.4.v201005080400)
> 6|Active |1|Apache Felix Gogo Command (0.14.0)
> 7|Active |1|Apache Felix Gogo Runtime (0.12.1)
> 8|Active |1|Apache Felix Gogo Shell (0.10.0.v201212101605)
> I found one related fact in
> 'org.apache.felix.bundlerepository-2.0.2/org.apache.felix.bundlerepository.impl.LocalResourceImpl.java'.
> - declared 'osgi.ee' capabilities from framework-bundle will realized as
> 'ee=JavaSE-1.8' capability
> - but the filter require 1 spitted capability ( and
> ) '(&(osgi.ee=JavaSE)(version=1.8))'
> *Here the patch who works for me.*
> 85c85,86
> < cap.addProperty(Capability.EXECUTIONENVIRONMENT,
> tokens.nextToken().trim());
> ---
> > String eeValue = tokens.nextToken().trim();
> >
> > cap.addProperty(Capability.EXECUTIONENVIRONMENT, eeValue);
> 86a88,100
> >
> > String[] split = eeValue.split("-");
> > switch (split.length) {
> > case 2:
> > String osgi_ee = "osgi." +
> > Capability.EXECUTIONENVIRONMENT;
> > CapabilityImpl cap2 = new
> > CapabilityImpl(osgi_ee, new PropertyImpl[]{
> > new
> > PropertyImpl(osgi_ee, null, split[0]),
> > new
> > PropertyImpl("version", null, split[1])
> > });
> > addCapability(cap2);
> > break;
> > }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4640) missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in org.apache.felix.framework
[
https://issues.apache.org/jira/browse/FELIX-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-4640:
Attachment: cap.diff
While looking at it, I realized that we're basically constructing the
{{osgi.ee}} capability here for the system bundle, but the system bundle
already has this capability, so I thought it might be easier to copy it. For
example you can find the {{osgi.ee}} capability of the system bundle with the
following code:
{code}Bundle b = context.getBundle(0);
BundleRevision br = b.adapt(BundleRevision.class);
List caps = br.getCapabilities("osgi.ee");
System.out.println("caps);{code}
Which prints out:
{noformat}osgi.ee; {osgi.ee=OSGi/Minimum, version=[1.0.0, 1.1.0, 1.2.0]}, [0]
osgi.ee; {osgi.ee=JavaSE, version=[1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0,
1.6.0]}]{noformat}
So I started thinking, would it not be better to simply copy _all_ the
capabilities from the system bundle? I've attached {{cap.diff}} patch that does
this to this issue. This would create a *lot* of capabilities (e.g. every
exported package from the system bundle is also represented as a capability)
but I have the feeling that this is more generic and more complete...
Thoughts anyone?
> missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in
> org.apache.felix.framework
> -
>
> Key: FELIX-4640
> URL: https://issues.apache.org/jira/browse/FELIX-4640
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR), Framework
> Environment: any
>Reporter: Jan Winter
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.4
>
> Attachments: cap.diff
>
>
> When I try to deploy a bundle from a OBRepo occur the below error
> 'Unsatisfied requirement'.
> g! obr:deploy any.bundle
> Unsatisfied requirement(s):
> ---
>(&(osgi.ee=JavaSE)(version=1.8))
> I would expect that this capability will be provided by system-bundle.
> g! felix:inspect capability osgi.ee
> org.apache.felix.framework [0] provides:
>
> osgi.ee; OSGi/Minimum [1.0.0, 1.1.0, 1.2.0] [UNUSED]
> osgi.ee; JavaSE [1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0,
> 1.8.0]
> *My full runtime environment is.*
> g! lb
> START LEVEL 1
>ID|State |Level|Name
> 0|Active |0|System Bundle (4.4.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.2)
> 2|Active |1|bndlib (2.3.0.201405100607)
> 3|Active |1|biz.aQute.repository (2.1.0.062515_230REL)
> 4|Active |1|Java XML Streaming API (1.0.1.v201004272200)
> 5|Active |1|JAXP XML (1.3.4.v201005080400)
> 6|Active |1|Apache Felix Gogo Command (0.14.0)
> 7|Active |1|Apache Felix Gogo Runtime (0.12.1)
> 8|Active |1|Apache Felix Gogo Shell (0.10.0.v201212101605)
> I found one related fact in
> 'org.apache.felix.bundlerepository-2.0.2/org.apache.felix.bundlerepository.impl.LocalResourceImpl.java'.
> - declared 'osgi.ee' capabilities from framework-bundle will realized as
> 'ee=JavaSE-1.8' capability
> - but the filter require 1 spitted capability ( and
> ) '(&(osgi.ee=JavaSE)(version=1.8))'
> *Here the patch who works for me.*
> 85c85,86
> < cap.addProperty(Capability.EXECUTIONENVIRONMENT,
> tokens.nextToken().trim());
> ---
> > String eeValue = tokens.nextToken().trim();
> >
> > cap.addProperty(Capability.EXECUTIONENVIRONMENT, eeValue);
> 86a88,100
> >
> > String[] split = eeValue.split("-");
> > switch (split.length) {
> > case 2:
> > String osgi_ee = "osgi." +
> > Capability.EXECUTIONENVIRONMENT;
> > CapabilityImpl cap2 = new
> > CapabilityImpl(osgi_ee, new PropertyImpl[]{
> > new
> > PropertyImpl(osgi_ee, null, split[0]),
> > new
> > PropertyImpl("version", null, split[1])
> > });
> > addCapability(cap2);
> > break;
> > }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (FELIX-4640) missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in org.apache.felix.framework
[
https://issues.apache.org/jira/browse/FELIX-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4640 started by David Bosschaert.
---
> missing (&(osgi.ee=JavaSE)(version=1.8)) when embedding in
> org.apache.felix.framework
> -
>
> Key: FELIX-4640
> URL: https://issues.apache.org/jira/browse/FELIX-4640
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR), Framework
> Environment: any
>Reporter: Jan Winter
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.4
>
>
> When I try to deploy a bundle from a OBRepo occur the below error
> 'Unsatisfied requirement'.
> g! obr:deploy any.bundle
> Unsatisfied requirement(s):
> ---
>(&(osgi.ee=JavaSE)(version=1.8))
> I would expect that this capability will be provided by system-bundle.
> g! felix:inspect capability osgi.ee
> org.apache.felix.framework [0] provides:
>
> osgi.ee; OSGi/Minimum [1.0.0, 1.1.0, 1.2.0] [UNUSED]
> osgi.ee; JavaSE [1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0,
> 1.8.0]
> *My full runtime environment is.*
> g! lb
> START LEVEL 1
>ID|State |Level|Name
> 0|Active |0|System Bundle (4.4.0)
> 1|Active |1|Apache Felix Bundle Repository (2.0.2)
> 2|Active |1|bndlib (2.3.0.201405100607)
> 3|Active |1|biz.aQute.repository (2.1.0.062515_230REL)
> 4|Active |1|Java XML Streaming API (1.0.1.v201004272200)
> 5|Active |1|JAXP XML (1.3.4.v201005080400)
> 6|Active |1|Apache Felix Gogo Command (0.14.0)
> 7|Active |1|Apache Felix Gogo Runtime (0.12.1)
> 8|Active |1|Apache Felix Gogo Shell (0.10.0.v201212101605)
> I found one related fact in
> 'org.apache.felix.bundlerepository-2.0.2/org.apache.felix.bundlerepository.impl.LocalResourceImpl.java'.
> - declared 'osgi.ee' capabilities from framework-bundle will realized as
> 'ee=JavaSE-1.8' capability
> - but the filter require 1 spitted capability ( and
> ) '(&(osgi.ee=JavaSE)(version=1.8))'
> *Here the patch who works for me.*
> 85c85,86
> < cap.addProperty(Capability.EXECUTIONENVIRONMENT,
> tokens.nextToken().trim());
> ---
> > String eeValue = tokens.nextToken().trim();
> >
> > cap.addProperty(Capability.EXECUTIONENVIRONMENT, eeValue);
> 86a88,100
> >
> > String[] split = eeValue.split("-");
> > switch (split.length) {
> > case 2:
> > String osgi_ee = "osgi." +
> > Capability.EXECUTIONENVIRONMENT;
> > CapabilityImpl cap2 = new
> > CapabilityImpl(osgi_ee, new PropertyImpl[]{
> > new
> > PropertyImpl(osgi_ee, null, split[0]),
> > new
> > PropertyImpl("version", null, split[1])
> > });
> > addCapability(cap2);
> > break;
> > }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4571) NullPointerException when using Repository impl with Aries subsystem impl
[ https://issues.apache.org/jira/browse/FELIX-4571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4571. - Resolution: Fixed Fixed in http://svn.apache.org/viewvc?view=revision&revision=1626798 [~tjwatson] could you please double check that this fixes it for your scenario? > NullPointerException when using Repository impl with Aries subsystem impl > - > > Key: FELIX-4571 > URL: https://issues.apache.org/jira/browse/FELIX-4571 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Reporter: Thomas Watson >Assignee: David Bosschaert > Fix For: bundlerepository-2.0.4 > > Attachments: obr.test_1.0.0.201407241433.jar > > > I get the following while trying to use the OSGi Repository service > implementation with Apache Aries subsystems implementation: > Caused by: java.lang.NullPointerException > at > org.apache.felix.bundlerepository.impl.LazyHashMap.put(LazyHashMap.java:88) > at > org.apache.felix.bundlerepository.impl.OSGiRepositoryImpl.newOSGiContentCapability(OSGiRepositoryImpl.java:155) > at > org.apache.felix.bundlerepository.impl.FelixResourceAdapter.getCapabilities(FelixResourceAdapter.java:50) > at org.apache.felix.resolver.Util.isFragment(Util.java:62) > at > org.apache.felix.resolver.Candidates.processCandidates(Candidates.java:606) > at > org.apache.felix.resolver.Candidates.populateResource(Candidates.java:273) > at org.apache.felix.resolver.Candidates.populate(Candidates.java:161) > at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:146) > at > org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:410) > at > org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:393) > at > org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:101) > at > org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:92) > at > org.apache.aries.subsystem.core.internal.InstallAction.createSubsystemResource(InstallAction.java:114) > at > org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:52) > It appears a null capability size attribute is causing the exception: > contentAttrs.put(ContentNamespace.CAPABILITY_SIZE_ATTRIBUTE, > resource.getSize()); > I'm not sure why it is null or if it is not allowed to be null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
