[jira] [Created] (FELIX-5905) SCR cannot access method getLogger from LogService R7
Alexandre Roman created FELIX-5905: -- Summary: SCR cannot access method getLogger from LogService R7 Key: FELIX-5905 URL: https://issues.apache.org/jira/browse/FELIX-5905 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-2.1.2 Reporter: Alexandre Roman I'm using SCR 2.1.5-SNAPSHOT with Felix LogService R7 and Felix Log-Extension. The LogService bundle is installed in the boot classpath (with Felix Logback & SLF4J APIs), and I'm using Log-Extension to expose LogService services to the OSGi environment. When using SCR, the method ValueUtils#getLogger cannot get access to the method LogService#getLogger using reflection for unknown reason: IllegalAccessException. The LogService implementation used as argument (coming from Felix LogService) owns the right method, but the reflection code failed with this exception. I tried a "workaround", using "setAccessible(true)" to the method handle, before invoking the method on the LogService implementation: now it works as expected. I'm not sure if it's related to my setup, meanwhile I need this call to "setAccessible" in order to get the expected behaviour. Without it, SCR failed to get a logger instance, and my components fail with a NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5904) SCR is creating a logger instance using name "null"
[
https://issues.apache.org/jira/browse/FELIX-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577953#comment-16577953
]
Alexandre Roman commented on FELIX-5904:
Looks good to me!
> SCR is creating a logger instance using name "null"
> ---
>
> Key: FELIX-5904
> URL: https://issues.apache.org/jira/browse/FELIX-5904
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.6
>Reporter: Alexandre Roman
>Assignee: Carsten Ziegeler
>Priority: Blocker
> Fix For: scr-2.1.6
>
>
> When using LogService 1.2 from OSGi r7 together with SCR 2.1.4, the following
> error happens:
> {{org.osgi.framework.BundleException: Activator start error in bundle
> org.apache.felix.scr [8].}}
> {{ at org.apache.felix.framework.Felix.activateBundle(Felix.java:2448)}}
> {{ at org.apache.felix.framework.Felix.startBundle(Felix.java:2304)}}
> {{ at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1535)}}
> {{ at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)}}
> {{ at java.lang.Thread.run(Thread.java:748)}}
> {{Caused by: java.lang.NullPointerException}}
> {{ at
> org.apache.felix.log.RootLoggerContextImpl.getEffectiveLogLevel(RootLoggerContextImpl.java:53)}}
> {{ at
> org.apache.felix.log.LoggerContextImpl.getEffectiveLogLevel(LoggerContextImpl.java:70)}}
> {{ at org.apache.felix.log.LoggerImpl.isErrorEnabled(LoggerImpl.java:216)}}
> {{ at
> org.apache.felix.scr.impl.logger.R7LogServiceLogger.isLogEnabled(R7LogServiceLogger.java:48)}}
> {{ at
> org.apache.felix.scr.impl.logger.AbstractLogger.isLogEnabled(AbstractLogger.java:72)}}
> {{ at
> org.apache.felix.scr.impl.logger.AbstractLogger.log(AbstractLogger.java:110)}}
> {{ at org.apache.felix.scr.impl.Activator.restart(Activator.java:143)}}
> {{ at
> org.apache.felix.scr.impl.config.ScrConfigurationImpl.configure(ScrConfigurationImpl.java:213)}}
> {{ at
> org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:118)}}
> {{ at org.apache.felix.scr.impl.Activator.start(Activator.java:100)}}
> {{ at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)}}
> {{ at org.apache.felix.framework.Felix.activateBundle(Felix.java:2398)}}
> {{ ... 4 more}}
> It looks like SCR is trying to create a Logger instance through LoggerFactory
> with name=null.
> Specs from OSGi r7 do not clearly specify what happens when the logger name
> is null.
> The LogService implementation from Felix does not check whether the value is
> null or not. I think this behaviour is normal: one should not expect a method
> to work normally if nothing in the documentation say anything about
> nullability.
> The Logger instance is created from R7LogServiceLogger, which is created by
> LogServiceSupport#getLogger. This instance is internally used by the bundle.
> I think a default logger name should be set for this internal logger.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5904) SCR is creating a logger instance using name "null"
Alexandre Roman created FELIX-5904:
--
Summary: SCR is creating a logger instance using name "null"
Key: FELIX-5904
URL: https://issues.apache.org/jira/browse/FELIX-5904
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-2.1.4
Reporter: Alexandre Roman
When using LogService 1.2 from OSGi r7 together with SCR 2.1.4, the following
error happens:
{{org.osgi.framework.BundleException: Activator start error in bundle
org.apache.felix.scr [8].}}
{{ at org.apache.felix.framework.Felix.activateBundle(Felix.java:2448)}}
{{ at org.apache.felix.framework.Felix.startBundle(Felix.java:2304)}}
{{ at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1535)}}
{{ at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)}}
{{ at java.lang.Thread.run(Thread.java:748)}}
{{Caused by: java.lang.NullPointerException}}
{{ at
org.apache.felix.log.RootLoggerContextImpl.getEffectiveLogLevel(RootLoggerContextImpl.java:53)}}
{{ at
org.apache.felix.log.LoggerContextImpl.getEffectiveLogLevel(LoggerContextImpl.java:70)}}
{{ at org.apache.felix.log.LoggerImpl.isErrorEnabled(LoggerImpl.java:216)}}
{{ at
org.apache.felix.scr.impl.logger.R7LogServiceLogger.isLogEnabled(R7LogServiceLogger.java:48)}}
{{ at
org.apache.felix.scr.impl.logger.AbstractLogger.isLogEnabled(AbstractLogger.java:72)}}
{{ at
org.apache.felix.scr.impl.logger.AbstractLogger.log(AbstractLogger.java:110)}}
{{ at org.apache.felix.scr.impl.Activator.restart(Activator.java:143)}}
{{ at
org.apache.felix.scr.impl.config.ScrConfigurationImpl.configure(ScrConfigurationImpl.java:213)}}
{{ at
org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:118)}}
{{ at org.apache.felix.scr.impl.Activator.start(Activator.java:100)}}
{{ at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)}}
{{ at org.apache.felix.framework.Felix.activateBundle(Felix.java:2398)}}
{{ ... 4 more}}
It looks like SCR is trying to create a Logger instance through LoggerFactory
with name=null.
Specs from OSGi r7 do not clearly specify what happens when the logger name is
null.
The LogService implementation from Felix does not check whether the value is
null or not. I think this behaviour is normal: one should not expect a method
to work normally if nothing in the documentation say anything about nullability.
The Logger instance is created from R7LogServiceLogger, which is created by
LogServiceSupport#getLogger. This instance is internally used by the bundle.
I think a default logger name should be set for this internal logger.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5170) Missing toString in FelixRequirementAdapter makes missing dep error impossible to solve
Alexandre Roman created FELIX-5170: -- Summary: Missing toString in FelixRequirementAdapter makes missing dep error impossible to solve Key: FELIX-5170 URL: https://issues.apache.org/jira/browse/FELIX-5170 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-2.0.6 Reporter: Alexandre Roman While using OBR, a missing dependency will raise this error in logs: org.osgi.service.subsystem.SubsystemException: org.osgi.service.resolver.ResolutionException: Unable to resolve XXX;osgi.bundle: missing requirement org.apache.felix.bundlerepository.impl.FelixRequirementAdapter@ee869b56 [caused by: Unable to resolve XXX;osgi.bundle: missing requirement org.apache.felix.bundlerepository.impl.FelixRequirementAdapter@863065e7] at org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:395) ~[na:na] at org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:356) ~[na:na] at org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:98) ~[na:na] at org.apache.aries.subsystem.core.internal.SubsystemResource.(SubsystemResource.java:90) ~[na:na] at org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:54) ~[na:na] at org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:30) ~[na:na] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_66] at org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:646) ~[na:na] at org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:690) ~[na:na] at org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:278) ~[na:na] at org.apache.aries.subsystem.core.internal.BasicSubsystem.install(BasicSubsystem.java:65) ~[na:na] ... at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_66] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_66] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_66] at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66] at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222) [2.0.2:na] at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37) [2.0.2:na] at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615) [2.0.2:na] at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499) [2.0.2:na] at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295) [2.0.2:na] at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:302) [2.0.2:na] at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:113) [2.0.2:na] at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:866) [2.0.2:na] at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:833) [2.0.2:na] at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724) [2.0.2:na] at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:399) [2.0.2:na] at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:676) [2.0.2:na] at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339) [2.0.2:na] at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:360) [2.0.2:na] at org.apache.felix.scr.impl.Activator.access$000(Activator.java:53) [2.0.2:na] at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:260) [2.0.2:na] at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259) [2.0.2:na] at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232) [2.0.2:na] at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482) [org.apache.felix.framework-5.4.0.jar:na] at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415) [org.apache.felix.framework-5.4.0.jar:na] at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
[jira] [Created] (FELIX-5125) NPE in ConfigInstaller
Alexandre Roman created FELIX-5125: -- Summary: NPE in ConfigInstaller Key: FELIX-5125 URL: https://issues.apache.org/jira/browse/FELIX-5125 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.5.0 Reporter: Alexandre Roman Configuration values returned by getProperties may be null if the method update was not called (according to OSGi specs). There is a NPE in ConfigInstaller line 106. I got this error while testing my application with subsystems (after a bundle refresh). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5015) NPE in ResolverImpl
[ https://issues.apache.org/jira/browse/FELIX-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954807#comment-14954807 ] Alexandre Roman commented on FELIX-5015: Any idea when the next version of Resolver will be out? The new Karaf 4.0.2 is out with Felix 5.2.0, and this bug prevents me from using Subsystems in this release (it used to work in Karaf 4.0.1). > NPE in ResolverImpl > --- > > Key: FELIX-5015 > URL: https://issues.apache.org/jira/browse/FELIX-5015 > Project: Felix > Issue Type: Bug > Components: Resolver >Affects Versions: resolver-1.6.0 >Reporter: Alexandre Roman >Assignee: David Bosschaert > Fix For: resolver-1.8.0 > > Attachments: FELIX-5015.patch.gz > > > The method getPackageSources in ResolverImpl.java returns a Set. > This collection is used in mergeUses (line 1039) in a foreach loop. > A null value may be returned by getPackageSources, as a result of querying a > Map. In this case, the foreach loop in mergeUses will trigger a NPE. > The method getPackageSources should return an empty Set when there is no > result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5015) NPE in ResolverImpl
Alexandre Roman created FELIX-5015: -- Summary: NPE in ResolverImpl Key: FELIX-5015 URL: https://issues.apache.org/jira/browse/FELIX-5015 Project: Felix Issue Type: Bug Components: Resolver Affects Versions: resolver-1.6.0 Reporter: Alexandre Roman The method getPackageSources in ResolverImpl.java returns a Set. This collection is used in mergeUses (line 1039) in a foreach loop. A null value may be returned by getPackageSources, as a result of querying a Map. In this case, the foreach loop in mergeUses will trigger a NPE. The method getPackageSources should return an empty Set when there is no result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5006) EventAdmin threads should be named
Alexandre Roman created FELIX-5006: -- Summary: EventAdmin threads should be named Key: FELIX-5006 URL: https://issues.apache.org/jira/browse/FELIX-5006 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.4 Reporter: Alexandre Roman Priority: Minor Threads created by EventAdmin have no name. The ThreadFactory used in DefaultThreadPool.java does not assign a name to new threads. Anonymous threads make debugging harder, since we have to guess which thread is running our event handlers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
