[jira] [Resolved] (FELIX-6141) Risk of NPE when Maps containing null keys or values are converted
[ https://issues.apache.org/jira/browse/FELIX-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved FELIX-6141. - Resolution: Fixed Fixed in SVN revision r1860547 It would be good to get confirmation from [~bosschaert] that this is an acceptable fix as per the OSGi specification. > Risk of NPE when Maps containing null keys or values are converted > -- > > Key: FELIX-6141 > URL: https://issues.apache.org/jira/browse/FELIX-6141 > Project: Felix > Issue Type: Bug > Components: Converter >Affects Versions: converter-1.0.8 >Reporter: Timothy Ward >Assignee: Timothy Ward >Priority: Major > Fix For: converter-1.0.10 > > > The Converter code incorrectly calls Class#isAssignableFrom() using an > argument that may be null. This results in an NPE being thrown when > converting map-like values into scalars. Even if conversion should fail it > should never fail by throwing an NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6141) Risk of NPE when Maps containing null keys or values are converted
Timothy Ward created FELIX-6141: --- Summary: Risk of NPE when Maps containing null keys or values are converted Key: FELIX-6141 URL: https://issues.apache.org/jira/browse/FELIX-6141 Project: Felix Issue Type: Bug Components: Converter Affects Versions: converter-1.0.8 Reporter: Timothy Ward Assignee: Timothy Ward Fix For: converter-1.0.10 The Converter code incorrectly calls Class#isAssignableFrom() using an argument that may be null. This results in an NPE being thrown when converting map-like values into scalars. Even if conversion should fail it should never fail by throwing an NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6138) Missing support for temporal types
[ https://issues.apache.org/jira/browse/FELIX-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved FELIX-6138. - Resolution: Fixed Fixed in SVN revision r1860413 > Missing support for temporal types > -- > > Key: FELIX-6138 > URL: https://issues.apache.org/jira/browse/FELIX-6138 > Project: Felix > Issue Type: Bug > Components: Converter >Affects Versions: converter-1.0.8 >Reporter: Timothy Ward >Assignee: Timothy Ward >Priority: Major > Fix For: converter-1.0.10 > > > Table *707.2* of the compendium specification (in section 707.4.2.3) contains > mappings for a number of types from java.time. Several of these types are not > supported by the converter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6138) Missing support for temporal types
Timothy Ward created FELIX-6138: --- Summary: Missing support for temporal types Key: FELIX-6138 URL: https://issues.apache.org/jira/browse/FELIX-6138 Project: Felix Issue Type: Bug Components: Converter Affects Versions: converter-1.0.8 Reporter: Timothy Ward Assignee: Timothy Ward Fix For: converter-1.0.10 Table *707.2* of the compendium specification (in section 707.4.2.3) contains mappings for a number of types from java.time. Several of these types are not supported by the converter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6100) The converter fails to properly convert null to array types
Timothy Ward created FELIX-6100: --- Summary: The converter fails to properly convert null to array types Key: FELIX-6100 URL: https://issues.apache.org/jira/browse/FELIX-6100 Project: Felix Issue Type: Bug Components: Converter Affects Versions: converter-1.0.4 Reporter: Timothy Ward Assignee: Timothy Ward Fix For: converter-1.0.6 The Converter specification [says in 707.4.3.1|https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html#util.converter-arrays.collections] that null should be converted to an empty array, however the current implementation converts to an empty `Object[]` regardless of the target type, for example a `byte[]`. This is clearly wrong as the returned object cannot be assigned to the target type! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6065) The Converter doesn't support Wildcard types
Timothy Ward created FELIX-6065:
---
Summary: The Converter doesn't support Wildcard types
Key: FELIX-6065
URL: https://issues.apache.org/jira/browse/FELIX-6065
Project: Felix
Issue Type: Improvement
Components: Converter
Affects Versions: converter-1.0.2
Reporter: Timothy Ward
Fix For: converter-1.0.6
If you pass a wildcard type to the converter then it fails to do the
conversion. This is an odd thing to do, but it is definitely possible to work
out what the type is.
For example:
to(new TypeReference>(){});
can be converted to a Map, and
to(new TypeReference>>(){});
can be converted to a Map>
It is unclear what it would mean to use
{{ to(new TypeReference(){});}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-6064) Allow leniency when converting from DTO-like types with no public no-args constructor
[ https://issues.apache.org/jira/browse/FELIX-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved FELIX-6064. - Resolution: Fixed Fixed in SVN revision 1853957 > Allow leniency when converting from DTO-like types with no public no-args > constructor > - > > Key: FELIX-6064 > URL: https://issues.apache.org/jira/browse/FELIX-6064 > Project: Felix > Issue Type: Improvement > Components: Converter >Affects Versions: converter-1.0.2 >Reporter: Timothy Ward >Assignee: Timothy Ward >Priority: Major > Fix For: converter-1.0.6 > > > DTO types are supposed to have a public no-args constructor, but this is only > needed by the converter when converting *to* a DTO type. We should allow some > leniency when converting from a DTO like type because we don't need to > construct it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6064) Allow leniency when converting from DTO-like types with no public no-args constructor
Timothy Ward created FELIX-6064: --- Summary: Allow leniency when converting from DTO-like types with no public no-args constructor Key: FELIX-6064 URL: https://issues.apache.org/jira/browse/FELIX-6064 Project: Felix Issue Type: Improvement Components: Converter Affects Versions: converter-1.0.2 Reporter: Timothy Ward Assignee: Timothy Ward Fix For: converter-1.0.6 DTO types are supposed to have a public no-args constructor, but this is only needed by the converter when converting *to* a DTO type. We should allow some leniency when converting from a DTO like type because we don't need to construct it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6063) Avoid using reflection operations which require permissions
[ https://issues.apache.org/jira/browse/FELIX-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved FELIX-6063. - Resolution: Fixed Updated in SVN commit 1853936 > Avoid using reflection operations which require permissions > --- > > Key: FELIX-6063 > URL: https://issues.apache.org/jira/browse/FELIX-6063 > Project: Felix > Issue Type: Improvement > Components: Converter >Affects Versions: converter-1.0.2 >Reporter: Timothy Ward >Assignee: Timothy Ward >Priority: Major > Fix For: converter-1.0.4 > > > The Converter implementation uses lots of reflection as part of its > operation, however it is only expected to interact with public members. It > should therefore not use getDeclaredMethods() or getDeclaredFields(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6063) Avoid using reflection operations which require permissions
Timothy Ward created FELIX-6063: --- Summary: Avoid using reflection operations which require permissions Key: FELIX-6063 URL: https://issues.apache.org/jira/browse/FELIX-6063 Project: Felix Issue Type: Improvement Components: Converter Affects Versions: converter-1.0.2 Reporter: Timothy Ward Assignee: Timothy Ward Fix For: converter-1.0.4 The Converter implementation uses lots of reflection as part of its operation, however it is only expected to interact with public members. It should therefore not use getDeclaredMethods() or getDeclaredFields(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6061) Configuration Admin uses getDeclaredMethods without permission
[ https://issues.apache.org/jira/browse/FELIX-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved FELIX-6061. - Resolution: Fixed Changed to use getMethods() in SVN revision 1853885 > Configuration Admin uses getDeclaredMethods without permission > -- > > Key: FELIX-6061 > URL: https://issues.apache.org/jira/browse/FELIX-6061 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.9.10 >Reporter: Timothy Ward >Assignee: Timothy Ward >Priority: Blocker > Fix For: configadmin-1.9.12 > > > The use of getDeclaredMethods requires a security permission which > Configuration Admin doesn't have. This needs to be fixed by either using > getMethods (which doesn't need a permission) or adding the permission to > Configuration Admin's permissions.perm > Removing the call would be preferred. > > Note that this bug breaks the OSGi Compliance Tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-6061) Configuration Admin uses getDeclaredMethods without permission
[ https://issues.apache.org/jira/browse/FELIX-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated FELIX-6061: Issue Type: Bug (was: Improvement) > Configuration Admin uses getDeclaredMethods without permission > -- > > Key: FELIX-6061 > URL: https://issues.apache.org/jira/browse/FELIX-6061 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.9.10 >Reporter: Timothy Ward >Assignee: Timothy Ward >Priority: Blocker > > The use of getDeclaredMethods requires a security permission which > Configuration Admin doesn't have. This needs to be fixed by either using > getMethods (which doesn't need a permission) or adding the permission to > Configuration Admin's permissions.perm > Removing the call would be preferred. > > Note that this bug breaks the OSGi Compliance Tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6061) Configuration Admin uses getDeclaredMethods without permission
Timothy Ward created FELIX-6061: --- Summary: Configuration Admin uses getDeclaredMethods without permission Key: FELIX-6061 URL: https://issues.apache.org/jira/browse/FELIX-6061 Project: Felix Issue Type: Improvement Components: Configuration Admin Affects Versions: configadmin-1.9.10 Reporter: Timothy Ward Assignee: Timothy Ward The use of getDeclaredMethods requires a security permission which Configuration Admin doesn't have. This needs to be fixed by either using getMethods (which doesn't need a permission) or adding the permission to Configuration Admin's permissions.perm Removing the call would be preferred. Note that this bug breaks the OSGi Compliance Tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6029) Felix Http Jetty does not have a service capability for the HttpService
[ https://issues.apache.org/jira/browse/FELIX-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward resolved FELIX-6029. - Resolution: Fixed > Felix Http Jetty does not have a service capability for the HttpService > --- > > Key: FELIX-6029 > URL: https://issues.apache.org/jira/browse/FELIX-6029 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http.jetty-4.0.6 >Reporter: Timothy Ward >Priority: Major > Fix For: http.jetty-4.0.8 > > > The Felix Http Jetty bundle provides an HttpService service but does not have > a Provide-Capability for it. This prevents bundles which use the HttpService > from resolving when used with Felix Http Jetty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6029) Felix Http Jetty does not have a service capability for the HttpService
Timothy Ward created FELIX-6029: --- Summary: Felix Http Jetty does not have a service capability for the HttpService Key: FELIX-6029 URL: https://issues.apache.org/jira/browse/FELIX-6029 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http.jetty-4.0.6 Reporter: Timothy Ward Fix For: http.jetty-4.0.8 The Felix Http Jetty bundle provides an HttpService service but does not have a Provide-Capability for it. This prevents bundles which use the HttpService from resolving when used with Felix Http Jetty. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5970) Add requirement & capabilities model so gogo can be resolved
[
https://issues.apache.org/jira/browse/FELIX-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726870#comment-16726870
]
Timothy Ward commented on FELIX-5970:
-
{quote}If you want me to add an annotation for that too, I will.
{quote}
I see this as the primary usage pattern for people providing commands into
Gogo, so I think that something like a @RequireCommandWhiteboard or
@RequireCommandRuntime is pretty important.
I'd be happy to add the ComponentPropertyType annotations too, that way we can
make it really easy for people to build runtimes which provide custom Gogo
commands using DS.
> Add requirement & capabilities model so gogo can be resolved
>
>
> Key: FELIX-5970
> URL: https://issues.apache.org/jira/browse/FELIX-5970
> Project: Felix
> Issue Type: Improvement
> Components: Gogo Command, Gogo JLine, Gogo Runtime, Gogo Shell
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: gogo.command-1.1.0, gogo.runtime-1.1.2,
> gogo.shell-1.1.2, gogo.jline-1.1.2
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (FELIX-5970) Add requirement & capabilities model so gogo can be resolved
[
https://issues.apache.org/jira/browse/FELIX-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726854#comment-16726854
]
Timothy Ward edited comment on FELIX-5970 at 12/21/18 3:57 PM:
---
{quote}I've implemented it slightly differently. There's a gogo specific
namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo
_love triangle_ (runtime, shell impl, command.)
{quote}
I'm not sure why this approach was taken. Gogo commands use a whiteboard model
and so as someone contributing a Gogo command I would expect to use the
osgi.implementation namespace to pull in a whiteboard implementation.
I can understand that if you want to start doing *deep shell* work with live
input or changing the colour of the text then you need something more akin to
the model that you have defined, but what if I just want to provide a command
that could be used with vanilla Gogo or JLine Gogo?
For something nicely usable I would expect to see the following annotations:
{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command",
version=1.0.0)}}
{{public @interface RequireCommandWhiteboard \{ }}}
{{@RequireCommandWhiteboard}}
{{@ComponentPropertyType}}
{{public @interface GogoCommand {}}
{{ public static final String _PREFIX = "osgi.command.";}}{{ }}
{{ public String scope();}}
{{ public String[] function();}}
{{}}}
These would then be used as follows:
{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}
{{@Component(service=MyCommand.class)}}
{{public class MyCommand {}}
{{ public String bar() \{ ... }}}
{{ public String baz(int n) \{ ... }}}
{{}}}
was (Author: timothyjward):
{quote}I've implemented it slightly differently. There's a gogo specific
namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo
_love triangle_ (runtime, shell impl, command.)
{quote}
I'm not sure why this approach was taken. Gogo commands use a whiteboard model
and so as someone contributing a Gogo command I would expect to use the
osgi.implementation namespace to pull in a whiteboard implementation.
I can understand that if you want to start doing *deep shell* work with live
input or changing the colour of the text then you need something more akin to
the model that you have defined, but what if I just want to provide a command
that could be used with vanilla Gogo or JLine Gogo?
For something nicely usable I would expect to see the following annotations:
{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command",
version=1.0.0)}}
{{public @interface RequireCommandWhiteboard \{ }}}
{{@RequireCommandWhiteboard}}
{{@ComponentPropertyType}}
{{public @interface GogoCommand {}}{{ }}
{{ public static final String _PREFIX = "osgi.command.";}}{{ }}
{{ public String scope();}}{{ }}
{{ public String[] function();}}
{{}}}
These would then be used as follows:
{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}
{{@Component(service=MyCommand.class)}}
{{public class MyCommand {}}
{{ public String bar() \{ ... }}}
{{ public String baz(int n) \{ ... }}}
{{}}}
> Add requirement & capabilities model so gogo can be resolved
>
>
> Key: FELIX-5970
> URL: https://issues.apache.org/jira/browse/FELIX-5970
> Project: Felix
> Issue Type: Improvement
> Components: Gogo Command, Gogo JLine, Gogo Runtime, Gogo Shell
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: gogo.command-1.1.0, gogo.runtime-1.1.2,
> gogo.shell-1.1.2, gogo.jline-1.1.2
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5970) Add requirement & capabilities model so gogo can be resolved
[
https://issues.apache.org/jira/browse/FELIX-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726854#comment-16726854
]
Timothy Ward commented on FELIX-5970:
-
{quote}I've implemented it slightly differently. There's a gogo specific
namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo
_love triangle_ (runtime, shell impl, command.)
{quote}
I'm not sure why this approach was taken. Gogo commands use a whiteboard model
and so as someone contributing a Gogo command I would expect to use the
osgi.implementation namespace to pull in a whiteboard implementation.
I can understand that if you want to start doing *deep shell* work with live
input or changing the colour of the text then you need something more akin to
the model that you have defined, but what if I just want to provide a command
that could be used with vanilla Gogo or JLine Gogo?
For something nicely usable I would expect to see the following annotations:
{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command",
version=1.0.0)}}
{{public @interface RequireCommandWhiteboard \{ }}}
{{@RequireCommandWhiteboard}}
{{@ComponentPropertyType}}
{{public @interface GogoCommand {}}{{ }}
{{ public static final String _PREFIX = "osgi.command.";}}{{ }}
{{ public String scope();}}{{ }}
{{ public String[] function();}}
{{}}}
These would then be used as follows:
{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}
{{@Component(service=MyCommand.class)}}
{{public class MyCommand {}}
{{ public String bar() \{ ... }}}
{{ public String baz(int n) \{ ... }}}
{{}}}
> Add requirement & capabilities model so gogo can be resolved
>
>
> Key: FELIX-5970
> URL: https://issues.apache.org/jira/browse/FELIX-5970
> Project: Felix
> Issue Type: Improvement
> Components: Gogo Command, Gogo JLine, Gogo Runtime, Gogo Shell
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: gogo.command-1.1.0, gogo.runtime-1.1.2,
> gogo.shell-1.1.2, gogo.jline-1.1.2
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
Timothy Ward created FELIX-5978:
---
Summary: Felix framework unable to retrieve custom URL handlers
when security is on
Key: FELIX-5978
URL: https://issues.apache.org/jira/browse/FELIX-5978
Project: Felix
Issue Type: Bug
Affects Versions: framework-6.0.1, framework-6.0.0
Reporter: Timothy Ward
Fix For: framework-6.0.2
When running with multiple frameworks in the same VM, custom URL Handlers, and
OSGi security on there are a couple of problems:
Firstly, this security exception results in the custom URL handler being
ignored. The framework should really be using a doPriv here.
{code:java}
java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "getClassLoader")
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
at java.lang.Class.getClassLoader(Class.java:683)
at
org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
at
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
at java.net.URL.toExternalForm(URL.java:929)
at java.net.URL.toString(URL.java:915)
at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
{code}
Secondly, the wrong framework is returned some of the time due to the logic of
URLHandlers.getFrameworkContext() - in this method it assumes that there will
be a bundle class loader on the stack, which is not true when the launcher is
starting a bundle (the framework reflectively loads the Activator type which
requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on
[
https://issues.apache.org/jira/browse/FELIX-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679712#comment-16679712
]
Timothy Ward commented on FELIX-5978:
-
{quote}Secondly, the wrong framework is returned some of the time due to the
logic of URLHandlers.getFrameworkContext() - in this method it assumes that
there will be a bundle class loader on the stack, which is not true when the
launcher is starting a bundle (the framework reflectively loads the Activator
type which requires a URL check to set the security domain).
{quote}
While it would be nice to fix this, I've thought more deeply about it and I'm
really not sure whether it is possible to fix without a significant change to
the Felix BundleClassLoader (basically to register the Framework that is
associated with the current class load). I would like some advice as to whether
people think this would be a good idea. [~karlpauls]?
> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
> Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Timothy Ward
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers,
> and OSGi security on there are a couple of problems:
>
> Firstly, this security exception results in the custom URL handler being
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic
> of URLHandlers.getFrameworkContext() - in this method it assumes that there
> will be a bundle class loader on the stack, which is not true when the
> launcher is starting a bundle (the framework reflectively loads the Activator
> type which requires a URL check to set the security domain).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5974) Prototype scope references are not released on deactivation
[ https://issues.apache.org/jira/browse/FELIX-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16669018#comment-16669018 ] Timothy Ward commented on FELIX-5974: - I've updated the PR - hopefully this will now release the objects from the MultiplePrototypeRefPair as well as releasing the service instance. > Prototype scope references are not released on deactivation > --- > > Key: FELIX-5974 > URL: https://issues.apache.org/jira/browse/FELIX-5974 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.1.12 >Reporter: Timothy Ward >Priority: Major > Fix For: scr-2.1.14 > > > Having read the stack overflow question on [Stack > Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released] > I was pretty certain that the user must be doing something wrong, but in > fact it seems as though SCR does a bad job of releasing Prototype scoped > references when a component is disposed. > I looked into the code, and it seems that there are a lot of conflicting > locations where prototype scope services are obtained and released. I propose > tidying this up so that the ComponentServiceObjects is *always* used > internally regardless of whether it is injected or not. This encapsulates all > the access in a single location so it is less likely that the objects will > leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5974) Prototype scope references are not released on deactivation
Timothy Ward created FELIX-5974: --- Summary: Prototype scope references are not released on deactivation Key: FELIX-5974 URL: https://issues.apache.org/jira/browse/FELIX-5974 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-2.1.12 Reporter: Timothy Ward Fix For: scr-2.1.14 Having read the stack overflow question on [Stack Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released] I was pretty certain that the user must be doing something wrong, but in fact it seems as though SCR does a bad job of releasing Prototype scoped references when a component is disposed. I looked into the code, and it seems that there are a lot of conflicting locations where prototype scope services are obtained and released. I propose tidying this up so that the ComponentServiceObjects is *always* used internally regardless of whether it is injected or not. This encapsulates all the access in a single location so it is less likely that the objects will leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5911) [Configurator] Too restrictive permissions.perm file
[
https://issues.apache.org/jira/browse/FELIX-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628970#comment-16628970
]
Timothy Ward commented on FELIX-5911:
-
{quote}[~timothyjward]: as far as I understand the set of permissions granted
by the system admin/the person launching the framework can only be a subset of
the permissions requested in the permissions.perm file. More precisely, the
effective set of permissions is the intersection of the ones in
permissions.perm and the ones granted by the admin. It is hence not possible to
configure additional permissions. Did I get this wrong?
{quote}
You can still use PermissionAdmin/ConditionalPermissionAdmin to control the
permissions of a bundle and grant them wider permissions than they would
otherwise have. You are correct, however that the permissions for a bundle
cannot expand beyond those of the Java runtime as a whole.
> [Configurator] Too restrictive permissions.perm file
>
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
> Issue Type: Bug
> Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within
> and below the current working dir). However, the bundle tries to access files
> in the bundle storage area as well, whose location we cannot anticipate here.
> It can be configured by means of a framework property, for instance. The
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete")
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5911) [Configurator] request FilePermission <>
[ https://issues.apache.org/jira/browse/FELIX-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628697#comment-16628697 ] Timothy Ward commented on FELIX-5911: - This permission request seems wrong. By default the OSGi framework should grant access to the bundle storage area ([see the security section in the core specification title|[https://osgi.org/specification/osgi.core/7.0.0/framework.security.html#framework.security.impliedpermissions]).] I'm not sure why the bundle should need to request other file permissions at all. I would also really like to see reflection removed as it really shouldn't be necessary. The bundle is in complete control of the serialization, so I'm not sure why it hasn't been written purely using DataInput/DataOutput. There aren't any cycles, and none of the default serialisation behaviour is in use. To my mind this could (and should) all be re-implemented without any need for reflection, even while maintaining backward compatibility with existing saved data. Finally, the additional permissions needed when the "configurator.initial" property is set need to be granted by the person launching the framework. They know that they have set security on, and what they have sent the configurator.initial property to. The Configurator bundle shouldn't be opening up the base options for this. > [Configurator] request FilePermission <> > --- > > Key: FELIX-5911 > URL: https://issues.apache.org/jira/browse/FELIX-5911 > Project: Felix > Issue Type: Bug > Components: Configurator >Affects Versions: configurator-1.0.4, configurator-1.0.6 >Reporter: Christoph Nölle >Assignee: Carsten Ziegeler >Priority: Major > Fix For: configurator-1.0.8 > > > Configurator currently requests > (java.io.FilePermission "-" "read,write,execute,delete") > in its permissions.perm file (the "-" means all files and subfolders within > and below the current working dir). However, the bundle tries to access files > in the bundle storage area as well, whose location we cannot anticipate here. > It can be configured by means of a framework property, for instance. The > correct permission would be > (java.io.FilePermission "<>" "read,write,execute,delete") -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5910) [ConfigAdmin] Set correct AccessControlContext when firing events
[
https://issues.apache.org/jira/browse/FELIX-5910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16612491#comment-16612491
]
Timothy Ward commented on FELIX-5910:
-
{quote}Thanks, yes this looks like a SCR bug
{quote}
I agree with this. SCR should definitely be removing itself from the stack by
setting the relevant access control context before calling any lifecycle
methods on the component. Otherwise SCR requires AllPermission (which is
probably what it has if nobody has created a proper permissions file for it)
which is a bad thing.
> [ConfigAdmin] Set correct AccessControlContext when firing events
> -
>
> Key: FELIX-5910
> URL: https://issues.apache.org/jira/browse/FELIX-5910
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
>Affects Versions: configadmin-1.9.4
> Environment: - Felix fwk 6.0.0
> - Felix security 2.6.0
> - Felix config admin 1.9.4 and 1.9.5-SNAPSHOT
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configadmin-1.9.6
>
>
> ConfigAdmin requests a restricted set of permissions by means of a
> permissions.perm file, which must not restrict the permissions of other
> bundles to which it sends events. There is in fact a mechanism in place to
> prevent this, using the protection domain of the bundle, in the class
> ManagedServiceTracker (resolving the related issue
> https://issues.apache.org/jira/browse/FELIX-4362). However, the UpdateThread
> class does not use this mechanism; instead it explicitly sets an
> AccessControlContext based on its own protection domain, hence enforcing its
> own restricted set of permissions to the event listeners. Below are two
> examples of the resulting AccessControlExceptions I get... there is just one
> additional bundle in the stack trace, felix-scr, which has all permissions
> and can be ignored from the permissions point of view.
> By the way, removing the permissions.perm file from ConfigAdmin resolves the
> problem, confirming that the bug is indeed in ConfigAdmin.
> rg.slf4j.osgi-over-slf4j[org.apache.felix.configadmin.1.9.4] :
> [[org.osgi.service.cm.ConfigurationAdmin]]Unexpected problem delivering
> configuration event to [org.osgi.service.cm.ConfigurationListener, id=18,
> bundle=24/mvn:org.apache.felix/org.apache.felix.configadmin/1.9.4]
> java.security.AccessControlException: access denied
> ("java.lang.RuntimePermission" "getClassLoader")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.base/java.security.AccessController.checkPermission(AccessController.java:895)
> at
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:335)
> at
> java.base/java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:2042)
> at java.base/java.lang.Class.getClassLoader(Class.java:807)
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.findMethod(BaseMethod.java:158)
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$400(BaseMethod.java:41)
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$NotResolved.resolve(BaseMethod.java:602)
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$NotResolved.methodExists(BaseMethod.java:626)
> at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.methodExists(BaseMethod.java:528)
> at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:315)
> at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeModifiedMethod(SingleComponentManager.java:810)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:765)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:683)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:647)
> at
> org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:435)
> at
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:288)
> at
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport$1.configurationEvent(RegionConfigurationSupport.java:91)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:1667)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1635)
> at org.apache.felix.cm.impl.UpdateThread$1.run(UpdateThread.java:126)
> at
[jira] [Commented] (FELIX-5010) NPE when resolving bundle with a header "Bundle-NativeCode = *"
[
https://issues.apache.org/jira/browse/FELIX-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16612482#comment-16612482
]
Timothy Ward commented on FELIX-5010:
-
Please ignore the above PR addition - It was supposed to reference FELIX-5910
> NPE when resolving bundle with a header "Bundle-NativeCode = *"
> ---
>
> Key: FELIX-5010
> URL: https://issues.apache.org/jira/browse/FELIX-5010
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.0.1
>Reporter: Guillaume Nodet
>Assignee: Bob Paulin
>Priority: Major
> Fix For: framework-5.2.0
>
>
> {code}
> java.lang.NullPointerException
> at
> org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:197)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:187)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.framework.StatefulResolver.findProvidersInternal(StatefulResolver.java:229)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.framework.ResolveContextImpl.findProviders(ResolveContextImpl.java:89)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.resolver.Candidates.populate(Candidates.java:198)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:199)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:140)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:431)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.framework.Felix.resolveBundles(Felix.java:4073)[org.apache.felix.framework-5.0.1.jar:]
> at
> org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:133)[org.apache.felix.framework-5.0.1.jar:]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5908) NoClassDefFoundError for the CM Security Domain combiner
[ https://issues.apache.org/jira/browse/FELIX-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582235#comment-16582235 ] Timothy Ward commented on FELIX-5908: - [~cziegeler] the other option would be update the ConfigurationTestBase installBundle method to add a dummy file into the generated test bundles. Adding a dummy file makes these bundles not “manifest only” and therefore avoids FELIX-5906 blowing up the tests. If this change is made then security 2.6.0 can be used. I avoided working around that bug in the patch as it wasn’t part of the minimum necessary changes for testing/fixing, and I figured the test changes were complex enough already! > NoClassDefFoundError for the CM Security Domain combiner > > > Key: FELIX-5908 > URL: https://issues.apache.org/jira/browse/FELIX-5908 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.9.4 >Reporter: Timothy Ward >Assignee: Carsten Ziegeler >Priority: Major > Fix For: configadmin-1.9.6 > > > This is a pretty weird bug, so I'll try to explain it. > When running with security on the Configuration Admin Updater thread applies > an Access Control Context which, amongst other things, sets up a Domain > Combiner. This Domain Combiner lazily creates a combined Protection Domain > based on the target bundle. > > All of this works fine until you end up in the following situation: > # The MS/MSF being called attempts to perform a checked operation (for which > they may or may not have permission) > # The Check causes the CM Domain Combiner to be instantiated, triggering a > class load if it is the first time > # The Loading of the class can then trigger *more* security checks in some > cases, for example setting the CodeSource of the class being defined can > require a security check if there are multiple frameworks in the VM, or if > the code was installed from a custom URL handler that has a custom > toExternalForm() implementation > # This security check retrievers the CM Domain Combiner, which attempts to > load the class again > # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError > > I am setting up a "simple" test demonstrating this (it necessarily has > several moving parts) and a proposed patch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5908) NoClassDefFoundError for the CM Security Domain combiner
[ https://issues.apache.org/jira/browse/FELIX-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581038#comment-16581038 ] Timothy Ward commented on FELIX-5908: - The attached GitHub Pull Request contains two commits, the first containing tests demonstrating the issue, the second containing a fix for the issue > NoClassDefFoundError for the CM Security Domain combiner > > > Key: FELIX-5908 > URL: https://issues.apache.org/jira/browse/FELIX-5908 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.9.4 >Reporter: Timothy Ward >Priority: Major > > This is a pretty weird bug, so I'll try to explain it. > When running with security on the Configuration Admin Updater thread applies > an Access Control Context which, amongst other things, sets up a Domain > Combiner. This Domain Combiner lazily creates a combined Protection Domain > based on the target bundle. > > All of this works fine until you end up in the following situation: > # The MS/MSF being called attempts to perform a checked operation (for which > they may or may not have permission) > # The Check causes the CM Domain Combiner to be instantiated, triggering a > class load if it is the first time > # The Loading of the class can then trigger *more* security checks in some > cases, for example setting the CodeSource of the class being defined can > require a security check if there are multiple frameworks in the VM, or if > the code was installed from a custom URL handler that has a custom > toExternalForm() implementation > # This security check retrievers the CM Domain Combiner, which attempts to > load the class again > # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError > > I am setting up a "simple" test demonstrating this (it necessarily has > several moving parts) and a proposed patch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5908) NoClassDefFoundError for the CM Security Domain combiner
Timothy Ward created FELIX-5908: --- Summary: NoClassDefFoundError for the CM Security Domain combiner Key: FELIX-5908 URL: https://issues.apache.org/jira/browse/FELIX-5908 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.9.4 Reporter: Timothy Ward This is a pretty weird bug, so I'll try to explain it. When running with security on the Configuration Admin Updater thread applies an Access Control Context which, amongst other things, sets up a Domain Combiner. This Domain Combiner lazily creates a combined Protection Domain based on the target bundle. All of this works fine until you end up in the following situation: # The MS/MSF being called attempts to perform a checked operation (for which they may or may not have permission) # The Check causes the CM Domain Combiner to be instantiated, triggering a class load if it is the first time # The Loading of the class can then trigger *more* security checks in some cases, for example setting the CodeSource of the class being defined can require a security check if there are multiple frameworks in the VM, or if the code was installed from a custom URL handler that has a custom toExternalForm() implementation # This security check retrievers the CM Domain Combiner, which attempts to load the class again # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError I am setting up a "simple" test demonstrating this (it necessarily has several moving parts) and a proposed patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5906) Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from Felix Security
[ https://issues.apache.org/jira/browse/FELIX-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated FELIX-5906: Component/s: Framework Security > Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from > Felix Security > --- > > Key: FELIX-5906 > URL: https://issues.apache.org/jira/browse/FELIX-5906 > Project: Felix > Issue Type: Bug > Components: Framework Security >Affects Versions: framework.security-2.6.0 >Reporter: Timothy Ward >Priority: Major > > The Felix security Provider returns an empty array, rather than null when > [finding > certificates|[https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L274].] > This then causes an ArrayIndexOutOfBoundsException when [this > line|https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L475] > is reached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5906) Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from Felix Security
[ https://issues.apache.org/jira/browse/FELIX-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated FELIX-5906: Affects Version/s: framework.security-2.6.0 > Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from > Felix Security > --- > > Key: FELIX-5906 > URL: https://issues.apache.org/jira/browse/FELIX-5906 > Project: Felix > Issue Type: Bug > Components: Framework Security >Affects Versions: framework.security-2.6.0 >Reporter: Timothy Ward >Priority: Major > > The Felix security Provider returns an empty array, rather than null when > [finding > certificates|[https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L274].] > This then causes an ArrayIndexOutOfBoundsException when [this > line|https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L475] > is reached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5906) Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from Felix Security
Timothy Ward created FELIX-5906: --- Summary: Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from Felix Security Key: FELIX-5906 URL: https://issues.apache.org/jira/browse/FELIX-5906 Project: Felix Issue Type: Bug Reporter: Timothy Ward The Felix security Provider returns an empty array, rather than null when [finding certificates|[https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L274].] This then causes an ArrayIndexOutOfBoundsException when [this line|https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L475] is reached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5892) Repeated calls to getFactoryConfiguration return different configuration instances
Timothy Ward created FELIX-5892: --- Summary: Repeated calls to getFactoryConfiguration return different configuration instances Key: FELIX-5892 URL: https://issues.apache.org/jira/browse/FELIX-5892 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.9.2 Reporter: Timothy Ward When using the new getFactoryConfiguration methods the Configuration Admin implementation does not store a newly created configuration in its local cache. This results in a new configuration object being created each time which means that the revision field is reset to 1. Any updates made to the newly acquired configuration are thus not delivered to ManagedServiceFactory instances because they are deemed to be "too old", at least until the revision count of the new configuration overtakes the old one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5885) Felix SCR uses an overly restrictive import range for promises
Timothy Ward created FELIX-5885: --- Summary: Felix SCR uses an overly restrictive import range for promises Key: FELIX-5885 URL: https://issues.apache.org/jira/browse/FELIX-5885 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-2.1.2 Reporter: Timothy Ward Fix For: scr-2.1.2 The Felix SCR bundle embeds the OSGi promise library at version 1.0 to make it easy to deploy DS. This is great, but the import range used is [1.0,1.1), which prevents users of the DS API from using promises 1.1. There should be no reason that Felix SCR needs to have a provider import range - it should be able to substitute any backward compatible version and use a range of [1,2). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5864) Missing uses constraints for OSGi spec packages
[ https://issues.apache.org/jira/browse/FELIX-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509709#comment-16509709 ] Timothy Ward commented on FELIX-5864: - Looking now it appears that this may be fixed in trunk, but that still leaves 5.6.x broken, and there are no snapshots being published of the latest code. > Missing uses constraints for OSGi spec packages > --- > > Key: FELIX-5864 > URL: https://issues.apache.org/jira/browse/FELIX-5864 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.10 >Reporter: Timothy Ward >Priority: Major > Fix For: framework-5.6.12 > > > The System bundle is required to export a number of OSGi spec packages. Some > of these must come from the system bundle, but others (for example, > org.osgi.service.resolver) can be provided by other bundles as well. It is > important, therefore, that the framework defines uses constraints on these > packages. > Specifically "org.osgi.service.resolver" uses "org.osgi.resource" and both > are available as separate installable bundles. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5864) Missing uses constraints for OSGi spec packages
Timothy Ward created FELIX-5864: --- Summary: Missing uses constraints for OSGi spec packages Key: FELIX-5864 URL: https://issues.apache.org/jira/browse/FELIX-5864 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-5.6.10 Reporter: Timothy Ward Fix For: framework-5.6.12 The System bundle is required to export a number of OSGi spec packages. Some of these must come from the system bundle, but others (for example, org.osgi.service.resolver) can be provided by other bundles as well. It is important, therefore, that the framework defines uses constraints on these packages. Specifically "org.osgi.service.resolver" uses "org.osgi.resource" and both are available as separate installable bundles. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5310) Felix HTTP Jetty WebSockets do not work out of the box
[
https://issues.apache.org/jira/browse/FELIX-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Ward updated FELIX-5310:
Description:
I have encountered two significant problems when trying to use the Jetty
WebSocketServlet with the Jetty based Felix HTTP service whiteboard. Both
problems occur in the init method of my servlet.
1. I have to set the TCCL for the Jetty Web Socket implementation to be able
to find its own internal implementation of Websockets (specifically
org.eclipse.jetty.websocket.server.WebSocketServerFactory). This is really
stupid, as the TCCL I have to use is the Felix HTTP Jetty bundle's class loader!
2. The Jetty Web Socket implementation does one (and only one) check to check
that it's running on Jetty. It looks as though the only reason for this is to
get hold of an Executor which is available via a getter. This check involves
trying to establish the Jetty Context by casting the ServletContext to a Jetty
internal type. This does not work as the HTTP Whiteboard wrappers the
ServletContext. I can work around this by delaying initialisation to the first
request so that there is a context to get hold of, but this also sucks :(
In summary, my servlet has to look like this, most of which should not be
necessary!
{code:java}
public class EchoServlet extends WebSocketServlet {
private static final Logger LOGGER =
LoggerFactory.getLogger(EchoServlet.class);
private final AtomicBoolean firstCall = new AtomicBoolean(true);
private final CountDownLatch initBarrier = new CountDownLatch(1);
@Override
public void init() throws ServletException {
LOGGER.info("The Echo servlet has been initialized, but we delay
initialization until the first request so that a Jetty Context is available");
}
@Override
public void service(ServletRequest arg0, ServletResponse arg1) throws
ServletException, IOException {
if(firstCall.compareAndSet(true, false)) {
try {
delayedInit();
} finally {
initBarrier.countDown();
}
} else {
try {
initBarrier.await();
} catch (InterruptedException e) {
throw new ServletException("Timed out waiting for
initialisation", e);
}
}
super.service(arg0, arg1);
}
private void delayedInit() throws ServletException {
// Overide the TCCL so that the internal factory can be found
// Jetty tries to use ServiceLoader, and their fallback is to
// use TCCL, it would be better if we could provide a loader...
Thread currentThread = Thread.currentThread();
ClassLoader tccl = currentThread.getContextClassLoader();
currentThread.setContextClassLoader(WebSocketServlet.class.getClassLoader());
try {
super.init();
} finally {
currentThread.setContextClassLoader(tccl);
}
}
@Override
public void configure(WebSocketServletFactory wsf) {
wsf.setCreator((req,res) -> new WebSocketAdaptor() {
public void onWebSocketText(String message) {
getRemote().sendStringByFuture("Echo: " + message);
}
});
}
}
{code}
was:
I have encountered two significant problems when trying to use the Jetty
WebSocketServlet with the Jetty based Felix HTTP service whiteboard. Both
problems occur in the init method of my servlet.
1. I have to set the TCCL for the Jetty Web Socket implementation to be able
to find its own internal implementation of Websockets (specifically
org.eclipse.jetty.websocket.server.WebSocketServerFactory). This is really
stupid, as the TCCL I have to use is the Felix HTTP Jetty bundle's class loader!
2. The Jetty Web Socket implementation does one (and only one) check to check
that it's running on Jetty. It looks as though the only reason for this is to
get hold of an Executor which is available via a getter. This check involves
trying to establish the Jetty Context by casting the ServletContext to a Jetty
internal type. This does not work as the HTTP Whiteboard wrappers the
ServletContext. I can work around this by delaying initialisation to the first
request so that there is a context to get hold of, but this also sucks :(
In summary, my servlet has to look like this, most of which should not be
necessary!
public class EchoServlet extends WebSocketServlet {
private static final Logger LOGGER =
LoggerFactory.getLogger(EchoServlet.class);
private final AtomicBoolean firstCall = new AtomicBoolean(true);
[jira] [Created] (FELIX-5310) Felix HTTP Jetty WebSockets do not work out of the box
Timothy Ward created FELIX-5310:
---
Summary: Felix HTTP Jetty WebSockets do not work out of the box
Key: FELIX-5310
URL: https://issues.apache.org/jira/browse/FELIX-5310
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.jetty-3.2.0
Reporter: Timothy Ward
I have encountered two significant problems when trying to use the Jetty
WebSocketServlet with the Jetty based Felix HTTP service whiteboard. Both
problems occur in the init method of my servlet.
1. I have to set the TCCL for the Jetty Web Socket implementation to be able
to find its own internal implementation of Websockets (specifically
org.eclipse.jetty.websocket.server.WebSocketServerFactory). This is really
stupid, as the TCCL I have to use is the Felix HTTP Jetty bundle's class loader!
2. The Jetty Web Socket implementation does one (and only one) check to check
that it's running on Jetty. It looks as though the only reason for this is to
get hold of an Executor which is available via a getter. This check involves
trying to establish the Jetty Context by casting the ServletContext to a Jetty
internal type. This does not work as the HTTP Whiteboard wrappers the
ServletContext. I can work around this by delaying initialisation to the first
request so that there is a context to get hold of, but this also sucks :(
In summary, my servlet has to look like this, most of which should not be
necessary!
public class EchoServlet extends WebSocketServlet {
private static final Logger LOGGER =
LoggerFactory.getLogger(EchoServlet.class);
private final AtomicBoolean firstCall = new AtomicBoolean(true);
private final CountDownLatch initBarrier = new CountDownLatch(1);
@Override
public void init() throws ServletException {
LOGGER.info("The Echo servlet has been initialized, but we delay
initialization until the first request so that a Jetty Context is available");
}
@Override
public void service(ServletRequest arg0, ServletResponse arg1) throws
ServletException, IOException {
if(firstCall.compareAndSet(true, false)) {
try {
delayedInit();
} finally {
initBarrier.countDown();
}
} else {
try {
initBarrier.await();
} catch (InterruptedException e) {
throw new ServletException("Timed out waiting for
initialisation", e);
}
}
super.service(arg0, arg1);
}
private void delayedInit() throws ServletException {
// Overide the TCCL so that the internal factory can be found
// Jetty tries to use ServiceLoader, and their fallback is to
// use TCCL, it would be better if we could provide a loader...
Thread currentThread = Thread.currentThread();
ClassLoader tccl = currentThread.getContextClassLoader();
currentThread.setContextClassLoader(WebSocketServlet.class.getClassLoader());
try {
super.init();
} finally {
currentThread.setContextClassLoader(tccl);
}
}
@Override
public void configure(WebSocketServletFactory wsf) {
wsf.setCreator((req,res) -> new WebSocketAdaptor() {
public void onWebSocketText(String message) {
getRemote().sendStringByFuture("Echo: " + message);
}
});
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5248) SCR does not reactivate a failed component after a configuration update
[ https://issues.apache.org/jira/browse/FELIX-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15269493#comment-15269493 ] Timothy Ward commented on FELIX-5248: - Hi David, The component is immediate and has a configuration policy of required. It has one static reference to a service which is satisfied, an activate method which takes a bundle context, a type safe configuration object, and a map of the raw configuration. It also has a deactivate method which takes no arguments. The failure flow is as follows: 1. The component's bundle is started and the referenced service is available. The configuration requirement correctly prevents activation of any component instances. 2. A factory configuration is created for the correct factory pid with some config properties. Occasionally one of the config properties is malformed, which the component instance detects, throwing an exception from the activate method. This correctly prevents that component instance from starting when the config is bad. 3. The factory configuration is then updated by the user to correct the malformed config property. At this point I do not get the behaviour I expect. I expect a component instance to be activated with the updated configuration. Instead the component sits there, ignoring the configuration update. If at this point I disable and enable the component then everything works fine, but I don't want to do that as it will disable all of the other instances created by other factory configurations. It also works if I delete the old config and create a new config, but I don't want to do that either because it's an extra set of steps for the user. I don't think that what I'm asking for is illogical, although I can't find a line in the specification which says that it must work. I hope this helps. I've tried looking through the felix SCR unit tests, but at the moment I'm not entirely sure how I would write a failing test for this behaviour. Tim > SCR does not reactivate a failed component after a configuration update > --- > > Key: FELIX-5248 > URL: https://issues.apache.org/jira/browse/FELIX-5248 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.4 >Reporter: Timothy Ward >Priority: Blocker > > A configurable SCR component may fail to activate by throwing an exception if > the factory configuration contains bad values. If the factory configuration > for that component is then updated SCR should attempt to recreate and > activate the component. Instead the component sits in the "satisfied" state > forever, and updates to the factory configuration are ignored. > This makes it impossible to "fix" a mistaken configuration without deleting > and recreating it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5248) SCR does not reactivate a failed component after a configuration update
Timothy Ward created FELIX-5248: --- Summary: SCR does not reactivate a failed component after a configuration update Key: FELIX-5248 URL: https://issues.apache.org/jira/browse/FELIX-5248 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-2.0.4 Reporter: Timothy Ward Priority: Blocker A configurable SCR component may fail to activate by throwing an exception if the factory configuration contains bad values. If the factory configuration for that component is then updated SCR should attempt to recreate and activate the component. Instead the component sits in the "satisfied" state forever, and updates to the factory configuration are ignored. This makes it impossible to "fix" a mistaken configuration without deleting and recreating it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active
[ https://issues.apache.org/jira/browse/FELIX-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756405#comment-13756405 ] Timothy Ward commented on FELIX-4212: - Hi Richard, Thanks for locating the relevant part of the spec. The R4.3 JavaDoc for BundleWiring.getCapabilities() doesn't mention the resolver (hence my confusion) The wording is as follows: - java.util.ListBundleCapability getCapabilities(java.lang.String namespace) Returns the capabilities provided by this bundle wiring. A capability may not be required by any bundle wiring and thus there may be no wires for the capability. A bundle wiring for a non-fragment revision provides a subset of the declared capabilities from the bundle revision and all attached fragment revisions. Not all declared capabilities may be provided since some may be discarded. For example, if a package is declared to be exported and import, only one is selected and the other is discarded. Parameters: namespace - The name space of the capabilities to return or null to return the capabilities from all name spaces. Returns: A list containing a snapshot of the BundleCapabilitys, or an empty list if this bundle wiring provides no capabilities in the specified name space. If this bundle wiring is not in use, null will be returned. For a given name space, the list contains the wires in the order the capabilities were specified in the manifests of the bundle revision and the attached fragments of this bundle wiring. There is no ordering defined between capabilities in different name spaces. -- This was updated in R5 to: --- java.util.ListBundleCapability getCapabilities(java.lang.String namespace) Returns the capabilities provided by this bundle wiring. Only capabilities considered by the resolver are returned. For example, capabilities with effective directive not equal to resolve are not returned. A capability may not be required by any bundle wiring and thus there may be no wires for the capability. A bundle wiring for a non-fragment revision provides a subset of the declared capabilities from the bundle revision and all attached fragment revisions†. Not all declared capabilities may be provided since some may be discarded. For example, if a package is declared to be both exported and imported, only one is selected and the other is discarded. A bundle wiring for a fragment revision with a symbolic name must provide exactly one identity capability. † The identity capability provided by attached fragment revisions must not be included in the capabilities of the host bundle wiring. Parameters: namespace - The namespace of the capabilities to return or null to return the capabilities from all namespaces. Returns: A list containing a snapshot of the BundleCapabilitys, or an empty list if this bundle wiring provides no capabilities in the specified namespace. If this bundle wiring is not in use, null will be returned. For a given namespace, the list contains the wires in the order the capabilities were specified in the manifests of the bundle revision and the attached fragments† of this bundle wiring. There is no ordering defined between capabilities in different namespaces. I've put in a quick test. My bundle manifest contains: -- Provide-Capability: test.namespace, test.namespace; effective:=active Require-Capability: test.namespace; filter:=(foo=bar); resolution:=optional, test.namespace; filter:=(foo=bar); effective:=active -- and I see the following: Felix 4.2.1: Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Felix 4.2.0: Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Felix 4.0.3: Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Equinox 3.8.2: -- Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Equinox 3.7.2: -- Bundle Revision test.namespace effective null test.namespace effective null Bundle Wiring test.namespace effective null Looks like I should raise a bug against Equinox 3.7.x ... Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active -- Key:
[jira] [Closed] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active
[ https://issues.apache.org/jira/browse/FELIX-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward closed FELIX-4212. --- Resolution: Invalid Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active -- Key: FELIX-4212 URL: https://issues.apache.org/jira/browse/FELIX-4212 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.2.1 Reporter: Timothy Ward Priority: Critical I am trying to access Require-Capability and Provide-Capability metadata from my bundle's manifest using the BundleWiring API. Most capabilities show up fine, but none of the ones with effective:=active are present. I understand that these capabilities are ignored by the resolver, and may not have any wirings, but I expect them to show up anyway. This avoids me having to provide my own parsing code to turn the manifest entries into Requirements and Capabilities. Having checked with the OSGi Core Platform Expert group, active time requirements and capabilities really should be showing up in the BundleWiring. My guess is that this will be easy to fix! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active
Timothy Ward created FELIX-4212: --- Summary: Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active Key: FELIX-4212 URL: https://issues.apache.org/jira/browse/FELIX-4212 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.2.1 Reporter: Timothy Ward Priority: Critical I am trying to access Require-Capability and Provide-Capability metadata from my bundle's manifest using the BundleWiring API. Most capabilities show up fine, but none of the ones with effective:=active are present. I understand that these capabilities are ignored by the resolver, and may not have any wirings, but I expect them to show up anyway. This avoids me having to provide my own parsing code to turn the manifest entries into Requirements and Capabilities. Having checked with the OSGi Core Platform Expert group, active time requirements and capabilities really should be showing up in the BundleWiring. My guess is that this will be easy to fix! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739450#comment-13739450 ] Timothy Ward commented on FELIX-4088: - That's fine with me. NPE from SCR service unregistration --- Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Configuration Admin, Declarative Services (SCR), Framework Affects Versions: framework-4.2.0, configadmin-1.2.8, scr-1.6.0 Environment: MacOSX 8 processors Reporter: Timothy Ward When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673330#comment-13673330 ] Timothy Ward commented on FELIX-4088: - Hi [~djencks] - I have run the scenario again with a local build of the latest SCR code and I'm no longer seeing errors. Previously they were occurring about 75% of the time, and I've run through 10 times since the update. This obviously doesn't guarantee that there isn't another race condition in the framework, but the fix you added has definitely improved things. NPE from SCR service unregistration --- Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Configuration Admin, Declarative Services (SCR), Framework Affects Versions: framework-4.2.0, configadmin-1.2.8, scr-1.6.0 Environment: MacOSX 8 processors Reporter: Timothy Ward When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at
[jira] [Created] (FELIX-4088) NPE from SCR service unregistration
Timothy Ward created FELIX-4088: --- Summary: NPE from SCR service unregistration Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Configuration Admin, Declarative Services (SCR), Framework Affects Versions: scr-1.6.2 Reporter: Timothy Ward -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward updated FELIX-4088: Description: When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) One of the bundles is an
[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669616#comment-13669616 ] Timothy Ward commented on FELIX-4088: - 1. I'll have a go with the latest snapshot and see what happens. 2. The Paremus code doesn't do anything much beyond logging the call and then delegating. I don't see a way in which it could be introducing a thread switch, a delay, or that it could filter the event from DS. I'll make sure to keep an eye on it while continuing to debug. 3. The configuration has a factory pid matching the name of the DS component, and the DS component has a configuration-policy of require: scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0; name=com.paremus.packager.demos.derby.guard configuration-policy=require activate=activate I'll try to collect some useful logs. Even if this does turn out to be fixed in a more recent SCR release it still might be worth putting a null check in the core framework. I was quite surprised to be able to get something so deep in the core to NPE! NPE from SCR service unregistration --- Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Configuration Admin, Declarative Services (SCR), Framework Affects Versions: framework-4.2.0, configadmin-1.2.8, scr-1.6.0 Environment: MacOSX 8 processors Reporter: Timothy Ward When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at
[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669662#comment-13669662 ] Timothy Ward commented on FELIX-4088: - It looks like it probably is a threading problem... I see the same error using the 1.7.0-SNAPSHOT build from this morning, but only sometimes. Most of the time I see the following instead: ERROR: [com.paremus.packager.demos.derby.guard(53)] Bundle is shut down for dependency driverHosting to ((database.driver=derby)(version=10.9.1.0)) *ERROR* Unexpected problem delivery configuration event to [org.osgi.service.cm.ConfigurationListener, id=199, bundle=158] java.lang.NullPointerException at org.apache.felix.scr.impl.config.ConfigurationSupport.configureComponentHolder(ConfigurationSupport.java:113) at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:246) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) If I turn on debug trace then I no longer see the problem at all, if I turn on info trace then I occasionally see the problem. Sorry, I know this isn't the most helpful of debug information! NPE from SCR service unregistration --- Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Configuration Admin, Declarative Services (SCR), Framework Affects Versions: framework-4.2.0, configadmin-1.2.8, scr-1.6.0 Environment: MacOSX 8 processors Reporter: Timothy Ward When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at
[jira] Commented: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services
[
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991858#comment-12991858
]
Timothy Ward commented on FELIX-2546:
-
Hi Guillaume,
Obviously I'd like this fixed, but I'm happy for it to go into a 1.7 release
rather than a 1.6.5 release of bundlerepository. There are a few other problems
I'm looking at providing fixes for, and I'm happy to work by locally patching
my bundles in the short term.
Tim
Only one service is provisioned even when specifying for mulitple services
--
Key: FELIX-2546
URL: https://issues.apache.org/jira/browse/FELIX-2546
Project: Felix
Issue Type: Bug
Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
Environment: n/a
Reporter: Emily Jiang
Attachments: Felix OBR isMultiple support - timothyjward.txt
Felix OBR is unable to return multiple services when specifying 'multiple'
attribute with the value of 'true'. The test scenario is detailed below.
I am trying to get all bundles registering the service of
com.sample.HelloWorld and install them into the osgi framework . In my test
environment, there are two bundles with different symbolic name offering the
same service, com.sample.HelloWorld. However, only one bundle was pulled into
runtime. The snippet of my repository is shown below.
require extend=false
filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
multiple=true name=service optional=falseRequires service with
attributes {service=service, objectClass=com.sample.HelloWorld}/require
Regards
Emily
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services
[
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980887#action_12980887
]
Timothy Ward commented on FELIX-2546:
-
I also needed this and thought that it would be rather useful function for OBR,
so I had a go at coding it up. It actually turned out to be relatively simple
thanks to the existing structure. I'll attach what I have, and I'm happy to
contribute it to the felix code base.
Only one service is provisioned even when specifying for mulitple services
--
Key: FELIX-2546
URL: https://issues.apache.org/jira/browse/FELIX-2546
Project: Felix
Issue Type: Bug
Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
Environment: n/a
Reporter: Emily Jiang
Felix OBR is unable to return multiple services when specifying 'multiple'
attribute with the value of 'true'. The test scenario is detailed below.
I am trying to get all bundles registering the service of
com.sample.HelloWorld and install them into the osgi framework . In my test
environment, there are two bundles with different symbolic name offering the
same service, com.sample.HelloWorld. However, only one bundle was pulled into
runtime. The snippet of my repository is shown below.
require extend=false
filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
multiple=true name=service optional=falseRequires service with
attributes {service=service, objectClass=com.sample.HelloWorld}/require
Regards
Emily
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services
[
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Ward updated FELIX-2546:
Attachment: Felix OBR isMultiple support - timothyjward.txt
This patch adds proper support for multiple resources (i.e. it greedily finds
them in the repository and adds the ones that can resolve). It also adds
another resolution flag that allows the new behaviour to be switched off,
returning to the original behaviour and providing a slight speed increase.
There is a simple testcase for the new function included in the patch as well.
Only one service is provisioned even when specifying for mulitple services
--
Key: FELIX-2546
URL: https://issues.apache.org/jira/browse/FELIX-2546
Project: Felix
Issue Type: Bug
Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
Environment: n/a
Reporter: Emily Jiang
Attachments: Felix OBR isMultiple support - timothyjward.txt
Felix OBR is unable to return multiple services when specifying 'multiple'
attribute with the value of 'true'. The test scenario is detailed below.
I am trying to get all bundles registering the service of
com.sample.HelloWorld and install them into the osgi framework . In my test
environment, there are two bundles with different symbolic name offering the
same service, com.sample.HelloWorld. However, only one bundle was pulled into
runtime. The snippet of my repository is shown below.
require extend=false
filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
multiple=true name=service optional=falseRequires service with
attributes {service=service, objectClass=com.sample.HelloWorld}/require
Regards
Emily
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
