[jira] [Comment Edited] (FELIX-6594) Could not start bundle: file:custo/cxf-rt-bindings-soap-3.3.8.jar because of missing requirement javax.xml.soap
[
https://issues.apache.org/jira/browse/FELIX-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688744#comment-17688744
]
Pierre De Rop edited comment on FELIX-6594 at 2/14/23 11:19 PM:
by the way, I don't think this is related to Felix File Install component, so
most likely that you can close this issue.
It's more related to an installation issue where some bundles are missing or
you could also manage to reexport the jdk javax.xml.soap package using the
framework system property
"{{{}org.osgi.framework.system.packages.extra=javax.xml.soap;version={}}}1.3.0",
see
[https://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html]
however, I know the Nokia environment you are using. So I suggest you close
this issue and contact me privately by email (try to contact the team at Nokia
who is in charge of the "CASR" project, they most likely know how to contact me.
thanks.
was (Author: pderop):
by the way, I don't think this is related to Felix File Install component, so
most likely that you can close this issue.
It's more related to an installation issue where some bundles are missing or
you could also manage to reexport the jdk javax.xml.soap package using the
framework system property
"{{{}org.osgi.framework.system.packages.extra=javax.xml.soap;version={}}}1.3.0",
see
https://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html
{{}}
however, I know the Nokia environment you are using. So I suggest you close
this issue and contact me privately by email (try to contact the team at Nokia
who is in charge of the "CASR" project, they most likely know how to contact me.
thanks.
> Could not start bundle: file:custo/cxf-rt-bindings-soap-3.3.8.jar because of
> missing requirement javax.xml.soap
> ---
>
> Key: FELIX-6594
> URL: https://issues.apache.org/jira/browse/FELIX-6594
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Reporter: XIAOMING ZHAO
>Priority: Major
>
> Hello,
> We are upgrading cxf 3.2.13 to 3.3.8 or 3.3.11, we always got the following
> error in osgi felix.log, we didn't add a javax.xml.soap dependencies in
> gradle file, so it's from jdk.
> Would you please let me know how to resolve this error?
> I ever created a Jira CXF-8814, but no one can help to fix it. Would you
> please help me out?
> {code:java}
> WARN - 2023-01-13 07:33:32,85 - FelixDispatchQueue - Could not start bundle:
> file:custo/cxf-rt-bindings-soap-3.3.8.jar
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0): missing requirement
> [org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))
> Unresolved requirements: [[org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))]
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl$DeployedBundle.start(BundleInstallerImpl.java:935)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.startBundles(BundleInstallerImpl.java:624)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.finishInitialisation(BundleInstallerImpl.java:260)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.frameworkEvent(BundleInstallerImpl.java:244)
> at
> org.apache.felix.framework.EventDispatcher.invokeFrameworkListenerCallback(EventDispatcher.java:881)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:830)
> at
> org.apache.felix.framework.EventDispatcher.run(EventDispatcher.java:1147)
> at
> org.apache.felix.framework.EventDispatcher.access$000(EventDispatcher.java:54)
> at
> org.apache.felix.framework.EventDispatcher$1.run(EventDispatcher.java:102)
> at java.lang.Thread.run(Thread.java:750)
> WARN - 2023-01-13 07:33:32,152 - FelixDispatchQueue - Could not start bundle:
> file:custo/cxf-rt-frontend-jaxws-3.3.8.jar
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.cxf-rt-frontend-jaxws [102](R 102.0): missing requirement
> [org.apache.cxf.cxf-rt-frontend-jaxws [102](R 102.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))
> Unresolved
[jira] [Commented] (FELIX-6594) Could not start bundle: file:custo/cxf-rt-bindings-soap-3.3.8.jar because of missing requirement javax.xml.soap
[
https://issues.apache.org/jira/browse/FELIX-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688744#comment-17688744
]
Pierre De Rop commented on FELIX-6594:
--
by the way, I don't think this is related to Felix File Install component, so
most likely that you can close this issue.
It's more related to an installation issue where some bundles are missing or
you could also manage to reexport the jdk javax.xml.soap package using the
framework system property
"{{{}org.osgi.framework.system.packages.extra=javax.xml.soap;version={}}}1.3.0",
see
https://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html
{{}}
however, I know the Nokia environment you are using. So I suggest you close
this issue and contact me privately by email (try to contact the team at Nokia
who is in charge of the "CASR" project, they most likely know how to contact me.
thanks.
> Could not start bundle: file:custo/cxf-rt-bindings-soap-3.3.8.jar because of
> missing requirement javax.xml.soap
> ---
>
> Key: FELIX-6594
> URL: https://issues.apache.org/jira/browse/FELIX-6594
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Reporter: XIAOMING ZHAO
>Priority: Major
>
> Hello,
> We are upgrading cxf 3.2.13 to 3.3.8 or 3.3.11, we always got the following
> error in osgi felix.log, we didn't add a javax.xml.soap dependencies in
> gradle file, so it's from jdk.
> Would you please let me know how to resolve this error?
> I ever created a Jira CXF-8814, but no one can help to fix it. Would you
> please help me out?
> {code:java}
> WARN - 2023-01-13 07:33:32,85 - FelixDispatchQueue - Could not start bundle:
> file:custo/cxf-rt-bindings-soap-3.3.8.jar
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0): missing requirement
> [org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))
> Unresolved requirements: [[org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))]
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl$DeployedBundle.start(BundleInstallerImpl.java:935)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.startBundles(BundleInstallerImpl.java:624)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.finishInitialisation(BundleInstallerImpl.java:260)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.frameworkEvent(BundleInstallerImpl.java:244)
> at
> org.apache.felix.framework.EventDispatcher.invokeFrameworkListenerCallback(EventDispatcher.java:881)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:830)
> at
> org.apache.felix.framework.EventDispatcher.run(EventDispatcher.java:1147)
> at
> org.apache.felix.framework.EventDispatcher.access$000(EventDispatcher.java:54)
> at
> org.apache.felix.framework.EventDispatcher$1.run(EventDispatcher.java:102)
> at java.lang.Thread.run(Thread.java:750)
> WARN - 2023-01-13 07:33:32,152 - FelixDispatchQueue - Could not start bundle:
> file:custo/cxf-rt-frontend-jaxws-3.3.8.jar
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.cxf-rt-frontend-jaxws [102](R 102.0): missing requirement
> [org.apache.cxf.cxf-rt-frontend-jaxws [102](R 102.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))
> Unresolved requirements: [[org.apache.cxf.cxf-rt-frontend-jaxws [102](R
> 102.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))]
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398){code}
>
> we use openjak 1.8.0_352.
> openjdk version "1.8.0_352"
> OpenJDK Runtime Environment (build 1.8.0_352-b08)
> OpenJDK 64-Bit Server VM (build 25.352-b08, mixed mode),
> I tried to install cxf-bundle-compatible-3.3.11.jar and cxf-rt-ws-security
> and cxf-rt-ws-rm jar files, but still had errors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FELIX-6594) Could not start bundle: file:custo/cxf-rt-bindings-soap-3.3.8.jar because of missing requirement javax.xml.soap
[
https://issues.apache.org/jira/browse/FELIX-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688692#comment-17688692
]
Pierre De Rop commented on FELIX-6594:
--
The bundle cxf-rt-bindings-soap-3.3.8.jar can't be installed because it imports
the package javax.xml.soap with version range "[1.3.0, 2)", but it seems that
there is no other bundle exporting such package.
Maybe adding the following one would help ?
[https://search.maven.org/remotecontent?filepath=org/apache/servicemix/specs/org.apache.servicemix.specs.saaj-api-1.4/1.4_2/org.apache.servicemix.specs.saaj-api-1.4-1.4_2.jar]
> Could not start bundle: file:custo/cxf-rt-bindings-soap-3.3.8.jar because of
> missing requirement javax.xml.soap
> ---
>
> Key: FELIX-6594
> URL: https://issues.apache.org/jira/browse/FELIX-6594
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Reporter: XIAOMING ZHAO
>Priority: Major
>
> Hello,
> We are upgrading cxf 3.2.13 to 3.3.8 or 3.3.11, we always got the following
> error in osgi felix.log, we didn't add a javax.xml.soap dependencies in
> gradle file, so it's from jdk.
> Would you please let me know how to resolve this error?
> I ever created a Jira CXF-8814, but no one can help to fix it. Would you
> please help me out?
> {code:java}
> WARN - 2023-01-13 07:33:32,85 - FelixDispatchQueue - Could not start bundle:
> file:custo/cxf-rt-bindings-soap-3.3.8.jar
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0): missing requirement
> [org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))
> Unresolved requirements: [[org.apache.cxf.cxf-rt-bindings-soap [88](R 88.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))]
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl$DeployedBundle.start(BundleInstallerImpl.java:935)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.startBundles(BundleInstallerImpl.java:624)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.finishInitialisation(BundleInstallerImpl.java:260)
> at
> com.alcatel.as.service.bundleinstaller.impl.BundleInstallerImpl.frameworkEvent(BundleInstallerImpl.java:244)
> at
> org.apache.felix.framework.EventDispatcher.invokeFrameworkListenerCallback(EventDispatcher.java:881)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:830)
> at
> org.apache.felix.framework.EventDispatcher.run(EventDispatcher.java:1147)
> at
> org.apache.felix.framework.EventDispatcher.access$000(EventDispatcher.java:54)
> at
> org.apache.felix.framework.EventDispatcher$1.run(EventDispatcher.java:102)
> at java.lang.Thread.run(Thread.java:750)
> WARN - 2023-01-13 07:33:32,152 - FelixDispatchQueue - Could not start bundle:
> file:custo/cxf-rt-frontend-jaxws-3.3.8.jar
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.cxf.cxf-rt-frontend-jaxws [102](R 102.0): missing requirement
> [org.apache.cxf.cxf-rt-frontend-jaxws [102](R 102.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))
> Unresolved requirements: [[org.apache.cxf.cxf-rt-frontend-jaxws [102](R
> 102.0)] osgi.wiring.package;
> (&(osgi.wiring.package=javax.xml.soap)(version>=1.3.0)(!(version>=2.0.0)))]
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398){code}
>
> we use openjak 1.8.0_352.
> openjdk version "1.8.0_352"
> OpenJDK Runtime Environment (build 1.8.0_352-b08)
> OpenJDK 64-Bit Server VM (build 25.352-b08, mixed mode),
> I tried to install cxf-bundle-compatible-3.3.11.jar and cxf-rt-ws-security
> and cxf-rt-ws-rm jar files, but still had errors.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FELIX-6278) Update Dependency Manager with latest bndtools version
[ https://issues.apache.org/jira/browse/FELIX-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-6278. > Update Dependency Manager with latest bndtools version > -- > > Key: FELIX-6278 > URL: https://issues.apache.org/jira/browse/FELIX-6278 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r16 > > > felix dependency manager is built using an old bndtools 3.0.5. Let's update > the project with latest bndtools 5.0.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6278) Update Dependency Manager with latest bndtools version
[ https://issues.apache.org/jira/browse/FELIX-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17271400#comment-17271400 ] Pierre De Rop commented on FELIX-6278: -- updated dependency manager project using bndlibs 5.2.0 > Update Dependency Manager with latest bndtools version > -- > > Key: FELIX-6278 > URL: https://issues.apache.org/jira/browse/FELIX-6278 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r16 > > > felix dependency manager is built using an old bndtools 3.0.5. Let's update > the project with latest bndtools 5.0.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService
[
https://issues.apache.org/jira/browse/FELIX-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-6180.
> Component initialization error message get's printed to sysout instead of
> logged to LogService
> --
>
> Key: FELIX-6180
> URL: https://issues.apache.org/jira/browse/FELIX-6180
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r16
>
> Attachments: FELIX-6180.patch
>
>
> We had a broken component that failed to start (for a good reason):
> {code:java}
> @Component(provides = Object.class)
> public class BrokenComponent {
> static final Locale defaultLocale =
> Locale.forLanguageTag(System.getProperty("not.set"));
> }
> {code}
> The problem is not that it doesn't work BUT the error log (see below) never
> reached our central logging (which is consuming the log messages from the
> LogService).
> I this is caused by the fact that this is not an {{Exception}} but an
> {{Error}}, that makes it propagate all the way to the {{SerialExecutor}}
> which is initialized with a new {{Logger}} instance in {{ComponentImpl}}
> instead of getting the {{Logger}} instance that was used to create the
> {{ComponentImpl}}.
> {code}
> ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
> at
> org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
> at
> org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
> at
> org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
> at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
> at
> org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
> at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
> at
> org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
> at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
> at my.project.Activator.init(Activator.java:84)
> at
> org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at aQute.launcher.Launcher.startBundles(Launcher.java:528)
> at aQute.launcher.Launcher.activate(Launcher.java:427)
> at aQute.launcher.Launcher.run(Launcher.java:306)
> at aQute.launcher.Launcher.main(Launcher.java:152)
> at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
> Caused by: java.lang.NullPointerException
> at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
> at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
> at java.util.Locale.forLanguageTag(Locale.java:1568)
> at MyBrokenComponent.(UserTransformerV1_2.java:17)
> ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-6284) Felix Connect Native-Image support
[
https://issues.apache.org/jira/browse/FELIX-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-6284.
Resolution: Abandoned
I'm closing this issue, which is not actually needed anymore.
> Felix Connect Native-Image support
> --
>
> Key: FELIX-6284
> URL: https://issues.apache.org/jira/browse/FELIX-6284
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> The upcoming OSGi R8 will allow to combine OSGi with application compiled
> with graalVM/native-image, and maybe Atomos already supports this. In the
> meantime, I need to use the old apache Felix Connect library in GraalVM
> substrate/native-image environment.
> To do so, there might be few adaptions to be done in Felix Connect. One is
> about how bundles are scanned by the *ClasspathScanner* class. Currently,
> this class provides a "scanForBundles" method which looks for all bundle URLS
> available from the classpath, using:
> {code:java}
> Enumeration ClassLoader.getResources("META-INF/MANIFEST.MF") {code}
> This works fine in classpath environment, and collected URLS (jar:file) are
> then used to create BundleDescriptors. Each BundleDescriptor can then get
> access to bundle content using the URL.
> The ClassLoader.getResource method returns for instance URLS like:
> {code:java}
> jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.gogo.command-1.1.0.jar!/META-INF/MANIFEST.MF
> jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.metatype-1.2.2.jar!/META-INF/MANIFEST.MF
> etc ...{code}
> But in compiled applications (using substrate/native image), the
> ClassLoader.getResources("META-INF/MANIFEST.MF") method returns an
> enumeration of URLS which are all the same (using "resource" protocol) for
> all found bundles. For example, for gogo and metatype bundles in the example
> above, the ClassLoader.getResources("META-INF/MANIFEST.MF") would return
> these same urls:
> {code:java}
> resource:META-INF/MANIFEST.MF
> resource:META-INF/MANIFEST.MF {code}
> this is problematic, because it's not possible to load resources from a
> bundle using a unique jar:file url. Moreover, in native-image, using the
> "resource" url seems to cause problems, and it seems we can only open and
> read "resource" input stream only one time. I also observed some exceptions
> when reading "resource" inputstreams, like this:
> {code:java}
> DEBUG: bundle jaxrs.hello:0.0.0 (11)BundleComponentActivator : Descriptor
> locations OSGI-INF/sample.jaxrs.HelloDS.xml
> java.io.IOException: Stream closed
> at
> java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:165)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:271)
> at
> org.apache.felix.connect.URLRevision.getUrlContent(URLRevision.java:131)
> at
> org.apache.felix.connect.URLRevision.getEntries(URLRevision.java:73)
> at
> org.apache.felix.connect.EntryFilterEnumeration.(EntryFilterEnumeration.java:52)
> at
> org.apache.felix.connect.PojoSRBundle.findEntries(PojoSRBundle.java:486)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.findDescriptors(BundleComponentActivator.java:413)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:313)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:263)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:551)
> at org.apache.felix.scr.impl.Activator.access$200(Activator.java:69)
> at
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:424)
> at
> org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:420)
> at
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
> at
> org.apache.felix.connect.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:821)
> at
> org.apache.felix.connect.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:771)
>
[jira] [Commented] (FELIX-6282) Felix Connect R7 support
[
https://issues.apache.org/jira/browse/FELIX-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270237#comment-17270237
]
Pierre De Rop commented on FELIX-6282:
--
Thanks Tom, I'll test it soon.
> Felix Connect R7 support
>
>
> Key: FELIX-6282
> URL: https://issues.apache.org/jira/browse/FELIX-6282
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> The Felix Connect library seems to be almost ready for OSGi R7 support.
> At least, modifying the project's pom in order to depend on
> org.osgi:osgi.core:7.0.0 allows to use recent declarative service,
> configadmin, metatype, etc ...
> There is one minor issue: the support for FrameworkWiringDTO is missing (even
> if it's not really useful in the context of felix connect): in the following
> code, the adapt method returns null:
> {code:java}
> Bundle system = _ctx.getBundle(0);
> FrameworkWiringDTO wiring = system.adapt(FrameworkWiringDTO.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6282) Felix Connect R7 support
[
https://issues.apache.org/jira/browse/FELIX-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269682#comment-17269682
]
Pierre De Rop commented on FELIX-6282:
--
Hi Tom,
we have a use case where we load bundles from the Class Path, and if I'm
correct there are also use cases where old Felix connect is embedded from a
spring boot application.
I will start to work on all this soon, using the Atomos snapshots version for
the moment, and will let you know in case I find any issues (probably early
next week).
thanks
> Felix Connect R7 support
>
>
> Key: FELIX-6282
> URL: https://issues.apache.org/jira/browse/FELIX-6282
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> The Felix Connect library seems to be almost ready for OSGi R7 support.
> At least, modifying the project's pom in order to depend on
> org.osgi:osgi.core:7.0.0 allows to use recent declarative service,
> configadmin, metatype, etc ...
> There is one minor issue: the support for FrameworkWiringDTO is missing (even
> if it's not really useful in the context of felix connect): in the following
> code, the adapt method returns null:
> {code:java}
> Bundle system = _ctx.getBundle(0);
> FrameworkWiringDTO wiring = system.adapt(FrameworkWiringDTO.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6282) Felix Connect R7 support
[
https://issues.apache.org/jira/browse/FELIX-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269441#comment-17269441
]
Pierre De Rop commented on FELIX-6282:
--
Hi Karl,
I do agree, it may be confusing to release the old connect while the official
Felix 7.0.0 available.
It's just that we have some products which are still based on old felix
connect. We'll migrate them to the new official Felix 7.0.0 , and probably to
Atomos, but the work is not yet started. That's why a 0.x release could help
temporarily, until we do the switch to R8 (and probably to Atomos).
but I do agree: better is to switch now to R8, and not use the old felix
connect. We will do this, you can close this jira.
By the way, is Atomos officially released to maven central ?
> Felix Connect R7 support
>
>
> Key: FELIX-6282
> URL: https://issues.apache.org/jira/browse/FELIX-6282
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> The Felix Connect library seems to be almost ready for OSGi R7 support.
> At least, modifying the project's pom in order to depend on
> org.osgi:osgi.core:7.0.0 allows to use recent declarative service,
> configadmin, metatype, etc ...
> There is one minor issue: the support for FrameworkWiringDTO is missing (even
> if it's not really useful in the context of felix connect): in the following
> code, the adapt method returns null:
> {code:java}
> Bundle system = _ctx.getBundle(0);
> FrameworkWiringDTO wiring = system.adapt(FrameworkWiringDTO.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6282) Felix Connect R7 support
[
https://issues.apache.org/jira/browse/FELIX-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268909#comment-17268909
]
Pierre De Rop commented on FELIX-6282:
--
Hello Karl,
I'm getting back to this old issue (I was busy so far).
So, I have committed the patch last Jun (and I actually don't need the other
fix from FELIX-6284). Then I think we are now ready to go for a release.
So, are you fine if I do it now ? I will use version *0.2.2*, is it ok ?
however, there is one remaining question: it's easy to integrate OSGi R8 API,
so may I do it before doing the release ? To add support for R8, we only need
to do the following:
* the org.osgi:osgi.core:8.0.0 can just be included in the felix connect jar
* the ServiceReference.adapt() method must be implemented.
* the pom.xml has to be updated to use java8 (because the
org.osgi:osgi.core:8.0.0 jar is requiring java 8)
* finally, the Copyright year should be updated in the LICENSE file
So, are you ok if I add support for OSGI R8 before doing the release ?
PS: please let me know in case you prefer to do the release yourself ?
thanks.
> Felix Connect R7 support
>
>
> Key: FELIX-6282
> URL: https://issues.apache.org/jira/browse/FELIX-6282
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> The Felix Connect library seems to be almost ready for OSGi R7 support.
> At least, modifying the project's pom in order to depend on
> org.osgi:osgi.core:7.0.0 allows to use recent declarative service,
> configadmin, metatype, etc ...
> There is one minor issue: the support for FrameworkWiringDTO is missing (even
> if it's not really useful in the context of felix connect): in the following
> code, the adapt method returns null:
> {code:java}
> Bundle system = _ctx.getBundle(0);
> FrameworkWiringDTO wiring = system.adapt(FrameworkWiringDTO.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (FELIX-4818) New release process for Dependency Manager
[
https://issues.apache.org/jira/browse/FELIX-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-4818.
> New release process for Dependency Manager
> --
>
> Key: FELIX-4818
> URL: https://issues.apache.org/jira/browse/FELIX-4818
> Project: Felix
> Issue Type: Wish
> Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r1
>
>
> The new Dependency Manager 4.0 is now built using gradle and bndtools (see
> FELIX-4816). But this has an impact on the release process because we are not
> using Maven anymore. So, this issue describes a new release process for DM,
> which is for now minimal: we don't use the nexus staging repository and we
> don't release to maven central (this is optional). But we'll try to refine
> and improve the release process gradually, in next DM releases.
> So, here is the new release process description:
> * it is based mostly on the basic Apache release process (see [1]), and is
> also inspired from the Apache Ace release process (see [2]), and the Amdatu
> release process (see [3]) which are also using bndtools.
> * the DM4 release will be in the form of three archives: a source based
> archive (org.apache.felix.dependencymanager-rsrc.zip), a source binary
> dependencies archive (org.apache.felix.dependencymanager-rdeps.zip)
> containing all build-time binary dependencies, and a binary archive
> (org.apache.felix.dependencymanager-rbin.zip) containing all DM bundles
> for convenience.
> * Each released artifacts (-src, -deps, -bin) has the same unique release
> version number, regardless of the outcome of the vote. This implies that
> release version used for releases are not to be reused. By convention, a
> release version is defined as "r", where is a positive integer number
> starting at 1 and is incremented upon each release.
> * To verify the integrity of archives, .asc, .md5, and .sha (512) checksum
> files are provided for all archives.
> * Before making a release, the dependency manager source will be tagged to
> felix-dev git repo, using
> [org.apache.felix.dependencymanager-r|https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.dependencymanager-r]
> tag name.
> * Then a staging release is put in
> [https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r]/
> directory which will contain the three -src.zip, -deps.zip and -bin.zip
> archives.
> * Then a vote starts, and vote participants must then use a custom
> check_staged_release.sh (see [4]). This script, unlike the original Felix
> check_stage_release.sh, will download staging from
> [https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r]
> instead of
> [http://repository.apache.org/content/repositories]
> The usage of this command is:
> {code:java}
> sh check_staged_release.sh r /tmp/felix-staging
> (replace r by the actual staging release reversion, like "r1")
> {code}
> * Then if the vote has passed, the staging release is promoted and moved to:
> **
> [https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-src.zip
> **
> [https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-deps.zip
> **
> [https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-bin.zip
> * Else, if the vote has failed, the staging release is simply deleted from
> the staging area
> ([https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r])
> More informations can be found in [5] concerning how to use the gradle
> script, when making a release.
> [1] [http://www.apache.org/dev/release.html]
> [2] [https://ace.apache.org/docs/release-guide.html]
> [3]
> [https://amdatu.atlassian.net/wiki/display/AMDATUDEV/Amdatu+Release+Procedure]
> [4]
> [http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh]
> [5]
> [http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/README.release]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-4818) New release process for Dependency Manager
[
https://issues.apache.org/jira/browse/FELIX-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop resolved FELIX-4818.
--
Resolution: Fixed
> New release process for Dependency Manager
> --
>
> Key: FELIX-4818
> URL: https://issues.apache.org/jira/browse/FELIX-4818
> Project: Felix
> Issue Type: Wish
> Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r1
>
>
> The new Dependency Manager 4.0 is now built using gradle and bndtools (see
> FELIX-4816). But this has an impact on the release process because we are not
> using Maven anymore. So, this issue describes a new release process for DM,
> which is for now minimal: we don't use the nexus staging repository and we
> don't release to maven central (this is optional). But we'll try to refine
> and improve the release process gradually, in next DM releases.
> So, here is the new release process description:
> * it is based mostly on the basic Apache release process (see [1]), and is
> also inspired from the Apache Ace release process (see [2]), and the Amdatu
> release process (see [3]) which are also using bndtools.
> * the DM4 release will be in the form of three archives: a source based
> archive (org.apache.felix.dependencymanager-rsrc.zip), a source binary
> dependencies archive (org.apache.felix.dependencymanager-rdeps.zip)
> containing all build-time binary dependencies, and a binary archive
> (org.apache.felix.dependencymanager-rbin.zip) containing all DM bundles
> for convenience.
> * Each released artifacts (-src, -deps, -bin) has the same unique release
> version number, regardless of the outcome of the vote. This implies that
> release version used for releases are not to be reused. By convention, a
> release version is defined as "r", where is a positive integer number
> starting at 1 and is incremented upon each release.
> * To verify the integrity of archives, .asc, .md5, and .sha (512) checksum
> files are provided for all archives.
> * Before making a release, the dependency manager source will be tagged to
> felix-dev git repo, using
> [org.apache.felix.dependencymanager-r|https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.dependencymanager-r]
> tag name.
> * Then a staging release is put in
> [https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r]/
> directory which will contain the three -src.zip, -deps.zip and -bin.zip
> archives.
> * Then a vote starts, and vote participants must then use a custom
> check_staged_release.sh (see [4]). This script, unlike the original Felix
> check_stage_release.sh, will download staging from
> [https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r]
> instead of
> [http://repository.apache.org/content/repositories]
> The usage of this command is:
> {code:java}
> sh check_staged_release.sh r /tmp/felix-staging
> (replace r by the actual staging release reversion, like "r1")
> {code}
> * Then if the vote has passed, the staging release is promoted and moved to:
> **
> [https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-src.zip
> **
> [https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-deps.zip
> **
> [https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-bin.zip
> * Else, if the vote has failed, the staging release is simply deleted from
> the staging area
> ([https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r])
> More informations can be found in [5] concerning how to use the gradle
> script, when making a release.
> [1] [http://www.apache.org/dev/release.html]
> [2] [https://ace.apache.org/docs/release-guide.html]
> [3]
> [https://amdatu.atlassian.net/wiki/display/AMDATUDEV/Amdatu+Release+Procedure]
> [4]
> [http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh]
> [5]
> [http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/README.release]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-4818) New release process for Dependency Manager
[
https://issues.apache.org/jira/browse/FELIX-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-4818:
-
Description:
The new Dependency Manager 4.0 is now built using gradle and bndtools (see
FELIX-4816). But this has an impact on the release process because we are not
using Maven anymore. So, this issue describes a new release process for DM,
which is for now minimal: we don't use the nexus staging repository and we
don't release to maven central (this is optional). But we'll try to refine and
improve the release process gradually, in next DM releases.
So, here is the new release process description:
* it is based mostly on the basic Apache release process (see [1]), and is
also inspired from the Apache Ace release process (see [2]), and the Amdatu
release process (see [3]) which are also using bndtools.
* the DM4 release will be in the form of three archives: a source based
archive (org.apache.felix.dependencymanager-rsrc.zip), a source binary
dependencies archive (org.apache.felix.dependencymanager-rdeps.zip)
containing all build-time binary dependencies, and a binary archive
(org.apache.felix.dependencymanager-rbin.zip) containing all DM bundles for
convenience.
* Each released artifacts (-src, -deps, -bin) has the same unique release
version number, regardless of the outcome of the vote. This implies that
release version used for releases are not to be reused. By convention, a
release version is defined as "r", where is a positive integer number
starting at 1 and is incremented upon each release.
* To verify the integrity of archives, .asc, .md5, and .sha (512) checksum
files are provided for all archives.
* Before making a release, the dependency manager source will be tagged to
felix-dev git repo, using
[org.apache.felix.dependencymanager-r|https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.dependencymanager-r]
tag name.
* Then a staging release is put in
[https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r]/
directory which will contain the three -src.zip, -deps.zip and -bin.zip
archives.
* Then a vote starts, and vote participants must then use a custom
check_staged_release.sh (see [4]). This script, unlike the original Felix
check_stage_release.sh, will download staging from
[https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r]
instead of
[http://repository.apache.org/content/repositories]
The usage of this command is:
{code:java}
sh check_staged_release.sh r /tmp/felix-staging
(replace r by the actual staging release reversion, like "r1")
{code}
* Then if the vote has passed, the staging release is promoted and moved to:
**
[https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-src.zip
**
[https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-deps.zip
**
[https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r]-bin.zip
* Else, if the vote has failed, the staging release is simply deleted from the
staging area
([https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r])
More informations can be found in [5] concerning how to use the gradle script,
when making a release.
[1] [http://www.apache.org/dev/release.html]
[2] [https://ace.apache.org/docs/release-guide.html]
[3]
[https://amdatu.atlassian.net/wiki/display/AMDATUDEV/Amdatu+Release+Procedure]
[4]
[http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh]
[5]
[http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/README.release]
was:
The new Dependency Manager 4.0 is now built using gradle and bndtools (see
FELIX-4816). But this has an impact on the release process because we are not
using Maven anymore. So, this issue describes a new release process for DM,
which is for now minimal: we don't use the nexus staging repository and we
don't release to maven central (this is optional). But we'll try to refine and
improve the release process gradually, in next DM releases.
So, here is the new release process description:
* it is based mostly on the basic Apache release process (see [1]), and is also
inspired from the Apache Ace release process (see [2]), and the Amdatu release
process (see [3]) which are also using bndtools.
* the DM4 release will be in the form of three archives: a source based archive
(org.apache.felix.dependencymanager-rsrc.zip), a source binary dependencies
archive (org.apache.felix.dependencymanager-rdeps.zip) containing all
build-time binary dependencies, and a binary archive
(org.apache.felix.dependencymanager-rbin.zip) containing all DM bundles for
convenience.
* Each released artifacts (-src, -deps, -bin) has the same unique release
version number, regardless of the outcome of the vote. This
[jira] [Reopened] (FELIX-4818) New release process for Dependency Manager
[
https://issues.apache.org/jira/browse/FELIX-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop reopened FELIX-4818:
--
> New release process for Dependency Manager
> --
>
> Key: FELIX-4818
> URL: https://issues.apache.org/jira/browse/FELIX-4818
> Project: Felix
> Issue Type: Wish
> Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r1
>
>
> The new Dependency Manager 4.0 is now built using gradle and bndtools (see
> FELIX-4816). But this has an impact on the release process because we are not
> using Maven anymore. So, this issue describes a new release process for DM,
> which is for now minimal: we don't use the nexus staging repository and we
> don't release to maven central (this is optional). But we'll try to refine
> and improve the release process gradually, in next DM releases.
> So, here is the new release process description:
> * it is based mostly on the basic Apache release process (see [1]), and is
> also inspired from the Apache Ace release process (see [2]), and the Amdatu
> release process (see [3]) which are also using bndtools.
> * the DM4 release will be in the form of three archives: a source based
> archive (org.apache.felix.dependencymanager-rsrc.zip), a source binary
> dependencies archive (org.apache.felix.dependencymanager-rdeps.zip)
> containing all build-time binary dependencies, and a binary archive
> (org.apache.felix.dependencymanager-rbin.zip) containing all DM bundles
> for convenience.
> * Each released artifacts (-src, -deps, -bin) has the same unique release
> version number, regardless of the outcome of the vote. This implies that
> release version used for releases are not to be reused. By convention, a
> release version is defined as "r", where is a positive integer number
> starting at 1 and is incremented upon each release.
> * To verify the integrity of archives, .asc, .md5, and .sha (512) checksum
> files are provided for all archives.
> * Before making a release, the dependency manager source will be tagged to
> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.dependencymanager-r
> * Then a staging release is put in
> https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r/
> directory which will contain the three -src.zip, -deps.zip and -bin.zip
> archives.
> * Then a vote starts, and vote participants must then use a custom
> check_staged_release.sh (see [4]). This script, unlike the original Felix
> check_stage_release.sh, will download staging from
> https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r
> instead of
> http://repository.apache.org/content/repositories
> The usage of this command is:
> {code}
> sh check_staged_release.sh r /tmp/felix-staging
> (replace r by the actual staging release reversion, like "r1")
> {code}
> * Then if the vote has passed, the staging release is promoted and moved to:
> **
> https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r-src.zip
> **
> https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r-deps.zip
> **
> https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r-bin.zip
> * Else, if the vote has failed, the staging release is simply deleted from
> the staging area
> (https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r)
> More informations can be found in [5] concerning how to use the gradle
> script, when making a release.
> [1] http://www.apache.org/dev/release.html
> [2] https://ace.apache.org/docs/release-guide.html
> [3]
> https://amdatu.atlassian.net/wiki/display/AMDATUDEV/Amdatu+Release+Procedure
> [4]
> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh
> [5]
> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/README.release
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6278) Update Dependency Manager with latest bndtools version
[ https://issues.apache.org/jira/browse/FELIX-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-6278: - Summary: Update Dependency Manager with latest bndtools version (was: Update Dependency Manager with latest bndtools 5.0.1) > Update Dependency Manager with latest bndtools version > -- > > Key: FELIX-6278 > URL: https://issues.apache.org/jira/browse/FELIX-6278 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r16 > > > felix dependency manager is built using an old bndtools 3.0.5. Let's update > the project with latest bndtools 5.0.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6375) Configuration Admin Service not available with org.apache.felix.webconsole_4.6.0.all
[
https://issues.apache.org/jira/browse/FELIX-6375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264277#comment-17264277
]
Pierre De Rop commented on FELIX-6375:
--
I think the issue comes from the Import-Package that was added since 4.6.0
version:
{code:java}
!javax.portlet,*
{code}
> Configuration Admin Service not available with
> org.apache.felix.webconsole_4.6.0.all
>
>
> Key: FELIX-6375
> URL: https://issues.apache.org/jira/browse/FELIX-6375
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.6.0
>Reporter: Benno Luthiger
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.6.2
>
>
> After using _org.apache.felix.webconsole_4.6.0.all_, the /configMgr showed no
> configuration entries but the message "Configuration Admin Service not
> available".
> Switching back to _org.apache.felix.webconsole-4.5.4-all_ showed the expected
> behavior.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (FELIX-6375) Configuration Admin Service not available with org.apache.felix.webconsole_4.6.0.all
[
https://issues.apache.org/jira/browse/FELIX-6375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264239#comment-17264239
]
Pierre De Rop edited comment on FELIX-6375 at 1/13/21, 4:36 PM:
Hello Benno,
Can you provide the exact list of all bundles you are using (as well as the
felix framework version used) ? We'll try to reproduce using the exact same
bundles from your ones.
>From my side, I found another problem, not sure if it's related to your own
>issue, anyway, let me describe it:
When using felix-framework-7.0.0 with org.apache.felix.configadmin-1.9.20.jar
and with org.apache.felix.webconsole-4.6.0-all.jar, I'm getting this exception:
{code:java}
org.osgi.framework.BundleException: Unable to resolve
org.apache.felix.webconsole [13](R 13.0): missing requirement
[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))
Unresolved r
equirements: [[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
{code}
it's because the org.apache.felix.webconsole-4.6.0-all.jar strictly imports the
org.osgi.service.cm package with a strict version range: *"[1.5,1.6)"*, however
the org.apache.felix.configadmin-1.9.20.jar exports the org.osgi.service.cm
with version "1.6.0". That's why there is the problem.
And indeed, using previous org.apache.felix.webconsole-4.5.4-all.jar, I don't
have the import-package issue.
So, can you provide the felix framework version used, as well as the list of
all bundles ? we'll then test.
thanks.
was (Author: pderop):
Hello Benno,
Can you provide the exact list of all bundles you are using (as well as the
felix framework version used) ? We'll try to reproduce using the exact same
bundles from your ones.
>From my side, I found another problem, not sure if it's related to your own
>issue, anyway, let me describe it:
When using felix-framework-7.0.0 with org.apache.felix.configadmin-1.9.20.jar
and with org.apache.felix.webconsole-4.6.0-all.jar, I'm getting this exception:
{code:java}
org.osgi.framework.BundleException: Unable to resolve
org.apache.felix.webconsole [13](R 13.0): missing requirement
[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))
Unresolved r
equirements: [[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
{code}
it's because the org.apache.felix.webconsole-4.6.0-all.jar strictly imporst the
org.osgi.service.cm package with a strict version range: *"[1.5,1.6)"*, however
the org.apache.felix.configadmin-1.9.20.jar exports the org.osgi.service.cm
with version "1.6.0". That's why there is the problem.
And indeed, using previous org.apache.felix.webconsole-4.5.4-all.jar, I don't
have the import-package issue.
So, can you provide the felix framework version used, as well as the list of
all bundles ? we'll then test.
thanks.
> Configuration Admin Service not available with
> org.apache.felix.webconsole_4.6.0.all
>
>
> Key: FELIX-6375
> URL: https://issues.apache.org/jira/browse/FELIX-6375
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.6.0
>Reporter: Benno Luthiger
>Priority: Minor
>
> After using _org.apache.felix.webconsole_4.6.0.all_, the /configMgr showed no
> configuration entries but the message "Configuration Admin Service not
> available".
> Switching back to _org.apache.felix.webconsole-4.5.4-all_ showed the expected
> behavior.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (FELIX-6375) Configuration Admin Service not available with org.apache.felix.webconsole_4.6.0.all
[
https://issues.apache.org/jira/browse/FELIX-6375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264239#comment-17264239
]
Pierre De Rop edited comment on FELIX-6375 at 1/13/21, 4:35 PM:
Hello Benno,
Can you provide the exact list of all bundles you are using (as well as the
felix framework version used) ? We'll try to reproduce using the exact same
bundles from your ones.
>From my side, I found another problem, not sure if it's related to your own
>issue, anyway, let me describe it:
When using felix-framework-7.0.0 with org.apache.felix.configadmin-1.9.20.jar
and with org.apache.felix.webconsole-4.6.0-all.jar, I'm getting this exception:
{code:java}
org.osgi.framework.BundleException: Unable to resolve
org.apache.felix.webconsole [13](R 13.0): missing requirement
[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))
Unresolved r
equirements: [[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
{code}
it's because the org.apache.felix.webconsole-4.6.0-all.jar strictly imporst the
org.osgi.service.cm package with a strict version range: *"[1.5,1.6)"*, however
the org.apache.felix.configadmin-1.9.20.jar exports the org.osgi.service.cm
with version "1.6.0". That's why there is the problem.
And indeed, using previous org.apache.felix.webconsole-4.5.4-all.jar, I don't
have the import-package issue.
So, can you provide the felix framework version used, as well as the list of
all bundles ? we'll then test.
thanks.
was (Author: pderop):
Hello Benno,
Can you provide the exact list of all bundles you are using (as well as the
felix framework version used) ? We'll try to reproduce using the exact same
bundles from your ones.
>From my side, I found another problem, not sure if it's related to your own
>issue, anyway, let me describe it:
When using felix-framework-7.0.0 with org.apache.felix.configadmin-1.9.20.jar
and with org.apache.felix.webconsole-4.6.0-all.jar, I'm getting this exception:
{code:java}
org.osgi.framework.BundleException: Unable to resolve
org.apache.felix.webconsole [13](R 13.0): missing requirement
[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))
Unresolved r
equirements: [[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
{code}
it's because the org.apache.felix.webconsole-4.6.0-all.jar strictly imporst the
org.osgi.service.cm package with a strict version range: *"[1.5, 6)"*, however
the org.apache.felix.configadmin-1.9.20.jar exports the org.osgi.service.cm
with version "1.6.0". That's why there is the problem.
And indeed, using previous org.apache.felix.webconsole-4.5.4-all.jar, I don't
have the import-package issue.
So, can you provide the felix framework version used, as well as the list of
all bundles ? we'll then test.
thanks.
> Configuration Admin Service not available with
> org.apache.felix.webconsole_4.6.0.all
>
>
> Key: FELIX-6375
> URL: https://issues.apache.org/jira/browse/FELIX-6375
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.6.0
>Reporter: Benno Luthiger
>Priority: Minor
>
> After using _org.apache.felix.webconsole_4.6.0.all_, the /configMgr showed no
> configuration entries but the message "Configuration Admin Service not
> available".
> Switching back to _org.apache.felix.webconsole-4.5.4-all_ showed the expected
> behavior.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6375) Configuration Admin Service not available with org.apache.felix.webconsole_4.6.0.all
[
https://issues.apache.org/jira/browse/FELIX-6375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264239#comment-17264239
]
Pierre De Rop commented on FELIX-6375:
--
Hello Benno,
Can you provide the exact list of all bundles you are using (as well as the
felix framework version used) ? We'll try to reproduce using the exact same
bundles from your ones.
>From my side, I found another problem, not sure if it's related to your own
>issue, anyway, let me describe it:
When using felix-framework-7.0.0 with org.apache.felix.configadmin-1.9.20.jar
and with org.apache.felix.webconsole-4.6.0-all.jar, I'm getting this exception:
{code:java}
org.osgi.framework.BundleException: Unable to resolve
org.apache.felix.webconsole [13](R 13.0): missing requirement
[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))
Unresolved r
equirements: [[org.apache.felix.webconsole [13](R 13.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.cm)(version>=1.5.0)(!(version>=1.6.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
{code}
it's because the org.apache.felix.webconsole-4.6.0-all.jar strictly imporst the
org.osgi.service.cm package with a strict version range: *"[1.5, 6)"*, however
the org.apache.felix.configadmin-1.9.20.jar exports the org.osgi.service.cm
with version "1.6.0". That's why there is the problem.
And indeed, using previous org.apache.felix.webconsole-4.5.4-all.jar, I don't
have the import-package issue.
So, can you provide the felix framework version used, as well as the list of
all bundles ? we'll then test.
thanks.
> Configuration Admin Service not available with
> org.apache.felix.webconsole_4.6.0.all
>
>
> Key: FELIX-6375
> URL: https://issues.apache.org/jira/browse/FELIX-6375
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.6.0
>Reporter: Benno Luthiger
>Priority: Minor
>
> After using _org.apache.felix.webconsole_4.6.0.all_, the /configMgr showed no
> configuration entries but the message "Configuration Admin Service not
> available".
> Switching back to _org.apache.felix.webconsole-4.5.4-all_ showed the expected
> behavior.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6286) Concurrency issue in Gogo runtime Activator
[
https://issues.apache.org/jira/browse/FELIX-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-6286:
-
Description:
*Environment:*
jdk: OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.252-b09, mixed mode)
felix: felix-framework-6.0.3
bundles:
* jansi-1.18.jar
* jline-3.13.0.jar
* org.apache.felix.bundlerepository-2.0.10.jar
* org.apache.felix.gogo.command-1.1.1-SNAPSHOT.jar
* org.apache.felix.gogo.jline-1.1.7-SNAPSHOT.jar (or
org.apache.felix.gogo.shell-1.1.3-SNAPSHOT.jar)
* org.apache.felix.gogo.runtime-1.1.3-SNAPSHOT.jar
*Symptoms:*
Sometimes, the gogo bundles don't start up properly:
- when using org.apache.felix.gogo.shell: we may get the following exception:
{code:java}
java -jar bin/felix.jar
gogo: CommandNotFoundException: Command not found: gosh
org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: gosh
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
- when using org.apache.felix.gogo.jline, we may get the following exception:
{code:java}
java -jar bin/felix.jar
bundle://89aa8bfc-38db-4413-9201-f31ffb0fd779_5.0:1/gosh_profile:23.0CommandNotFoundException:
Command not found: try
org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: try
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){code}
*When:*
the issue is hard to reproduce. The system must be heavily loaded while the
felix framework is starting up.
To fairly reproduce manually, you can do this:
First: ensure that the org.apache.felix.gogo.runtime bundle is started *AFTER*
other gogo bundles (after gogo jline or gogo shell bundle).
Second: add a delay in
gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/activator/Activator.java
start method, between the CommandProcessor registration and the OSGiCommands
ServiceTracker activation: this will reproduce the issue all the time:
{code:java}
public void start(final BundleContext context) throws Exception
{
threadio = new ThreadIOImpl();
threadio.start();
threadioRegistration =context.registerService(ThreadIO.class.getName(),
threadio, null);
processorRegistration = newProcessor(threadio, context);
System.out.println("XXX: sleep");
Thread.sleep(3000);
System.out.println("XXX: wakeup");
commandTracker = trackOSGiCommands(context);
commandTracker.open();
{code}
*Work Around:*
start the org.apache.felix.gogo.runtime bundle BEFORE other bundles:
*Analysis:*
my understand is the following: the gogo runtime is doing the following in its
Activator:
# registers the CommandProcessor service
# and after that, it starts tracking OSGI commands.
The issue happens if there are some delay between 1 and 2 above, typically when
the machine is heavily loaded while the felix framework is starting.
So, the other gogo jline and gogo shell Activators are doing this:
# track the CommandProcessor services
# when the CommandProcessor is registered: the shell or jline gogo Activators
then register their shell commands in the registry and a thread is then
started. At this point, it is assumed that the shell or jline commands are
already injected into the gogo runtime CommandProcessor. but it won't be the
case if the delay is happening between the time the CommandProcessor is
registered and the gogo runtime service tracker is opened.
*Proposed fix:*
in the *gogo runtime* bundle Activator, register the CommandProcessor *AFTER*
the OSGI commands ServiceTracker has been opened.
By doing so, when the other jline or
[jira] [Work started] (FELIX-6286) Concurrency issue in Gogo runtime Activator
[
https://issues.apache.org/jira/browse/FELIX-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-6286 started by Pierre De Rop.
> Concurrency issue in Gogo runtime Activator
> ---
>
> Key: FELIX-6286
> URL: https://issues.apache.org/jira/browse/FELIX-6286
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Affects Versions: gogo.runtime-1.1.2
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> *Environment:*
> jdk: OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.252-b09, mixed mode)
> felix: felix-framework-6.0.3
> bundles:
> * jansi-1.18.jar
> * jline-3.13.0.jar
> * org.apache.felix.bundlerepository-2.0.10.jar
> * org.apache.felix.gogo.command-1.1.1-SNAPSHOT.jar
> * org.apache.felix.gogo.jline-1.1.7-SNAPSHOT.jar (or
> org.apache.felix.gogo.shell-1.1.3-SNAPSHOT.jar)
> * org.apache.felix.gogo.runtime-1.1.3-SNAPSHOT.jar
> *Symptoms:*
> Sometimes, the gogo bundles don't start up properly:
> - when using org.apache.felix.gogo.shell: we may get the following exception:
> {code:java}
> java -jar bin/felix.jar
> gogo: CommandNotFoundException: Command not found: gosh
> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found:
> gosh
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> - when using org.apache.felix.gogo.jline, we may get the following exception:
> {code:java}
> java -jar bin/felix.jar
> bundle://89aa8bfc-38db-4413-9201-f31ffb0fd779_5.0:1/gosh_profile:23.0CommandNotFoundException:
> Command not found: try
> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: try
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
>
> *When:*
> the issue is hard to reproduce. The system must be heavily loaded while the
> felix framework is starting up.
> To fairly reproduce manually, you can do this:
> First: ensure that the org.apache.felix.gogo.runtime bundle is started
> *AFTER* other gogo bundles (after gogo jline or gogo shell bundle).
> Second: add a delay in
> gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/activator/Activator.java
> start method, between the CommandProcessor registration and the OSGiCommands
> ServiceTracker activation: this will reproduce the issue all the time:
> {code:java}
> public void start(final BundleContext context) throws Exception
> {
>threadio = new ThreadIOImpl();
>threadio.start();
>threadioRegistration =context.registerService(ThreadIO.class.getName(),
> threadio, null);
>processorRegistration = newProcessor(threadio, context);
>System.out.println("XXX: sleep");
>Thread.sleep(3000);
>System.out.println("XXX: wakeup");
>commandTracker = trackOSGiCommands(context);
>commandTracker.open();
> {code}
>
> *Work Around:*
> start the org.apache.felix.gogo.runtime bundle BEFORE other bundles:
> *Analysis:*
> my understand is the following: the gogo runtime is doing the following in
> its Activator:
> # registers the CommandProcessor service
> # and after that, it starts tracking OSGI commands.
> The issue happens if there are some delay between 1 and 2 above, typically
> when the machine is heavily loaded while the felix framework is starting.
> So, the other gogo jline and gogo shell Activators are doing this:
> # track the CommandProcessor services
> # when the
[jira] [Created] (FELIX-6286) Concurrency issue in Gogo runtime Activator
Pierre De Rop created FELIX-6286:
Summary: Concurrency issue in Gogo runtime Activator
Key: FELIX-6286
URL: https://issues.apache.org/jira/browse/FELIX-6286
Project: Felix
Issue Type: Bug
Components: Gogo Runtime
Affects Versions: gogo.runtime-1.1.2
Reporter: Pierre De Rop
Assignee: Pierre De Rop
*Environment:*
jdk: OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.252-b09, mixed mode)
felix: felix-framework-6.0.3
bundles:
* jansi-1.18.jar
* jline-3.13.0.jar
* org.apache.felix.bundlerepository-2.0.10.jar
* org.apache.felix.gogo.command-1.1.1-SNAPSHOT.jar
* org.apache.felix.gogo.jline-1.1.7-SNAPSHOT.jar (or
org.apache.felix.gogo.shell-1.1.3-SNAPSHOT.jar)
* org.apache.felix.gogo.runtime-1.1.3-SNAPSHOT.jar
*Symptoms:*
Sometimes, the gogo bundles don't start up properly:
- when using org.apache.felix.gogo.shell: we may get the following exception:
{code:java}
java -jar bin/felix.jar
gogo: CommandNotFoundException: Command not found: gosh
org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: gosh
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
- when using org.apache.felix.gogo.jline, we may get the following exception:
{code:java}
java -jar bin/felix.jar
bundle://89aa8bfc-38db-4413-9201-f31ffb0fd779_5.0:1/gosh_profile:23.0CommandNotFoundException:
Command not found: try
org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: try
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:596)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){code}
*When:*
the issue is hard to reproduce. The system must be heavily loaded while the
felix framework is starting up.
To fairly reproduce manually, you can do this:
First: ensure that the org.apache.felix.gogo.runtime bundle is started *AFTER*
other gogo bundles (after gogo jline or gogo shell bundle).
Second: add a delay in
gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/activator/Activator.java
start method, between the CommandProcessor registration and the OSGiCommands
ServiceTracker activation: this will reproduce the issue all the time:
{code:java}
public void start(final BundleContext context) throws Exception
{
threadio = new ThreadIOImpl();
threadio.start();
threadioRegistration =context.registerService(ThreadIO.class.getName(),
threadio, null);
processorRegistration = newProcessor(threadio, context);
System.out.println("XXX: sleep");
Thread.sleep(3000);
System.out.println("XXX: wakeup");
commandTracker = trackOSGiCommands(context);
commandTracker.open();
{code}
*Work Around:*
start the org.apache.felix.gogo.runtime bundle BEFORE other bundles:
*Analysis:*
my understand is the following: the gogo runtime is doing the following in its
Activator:
# registers the CommandProcessor service
# and after that, it starts tracking OSGI commands.
The issue happens if there are some delay between 1 and 2 above, typically when
the machine is heavily loaded while the felix framework is starting.
So, the other gogo jline and gogo shell Activators are doing this:
# track the CommandProcessor services
# when the CommandProcessor is registered: the shell or jline gogo commands
then register their shell commands in the registry and a thread is then
started. At this point, it is assumed that the shell or jline commands are
already injected into the gogo runtime CommandProcessor. but it won't be the
case if the delay is happening between the time the CommandProcessor is
registered and
[jira] [Comment Edited] (FELIX-6284) Felix Connect Native-Image support
[
https://issues.apache.org/jira/browse/FELIX-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125281#comment-17125281
]
Pierre De Rop edited comment on FELIX-6284 at 6/3/20, 8:18 PM:
---
Thanks Tom for sharing the info.
Since I need a release of the Felix Connect soon, I would like to first commit
the simple work around I provided in the PR linked to this jira. It is
certainly not as robust as the solution you have designed for Atomos, but it
allows me to go ahead until the new Felix Connect R8 / Atomos is released. Once
it is release, I will switch to it.
thanks.
was (Author: pderop):
Thanks Tom for sharing the info.
Since I need a release of the Felix Connect soon, I would like to first commit
the simple work around I provided in the PR linked to this jira. It is
certainly not as robust as the solution you have designed for Atomos, but it
allows me to go ahead until the new Felix Connect R8 is released. Once it is
release, I will switch to it.
thanks.
> Felix Connect Native-Image support
> --
>
> Key: FELIX-6284
> URL: https://issues.apache.org/jira/browse/FELIX-6284
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> The upcoming OSGi R8 will allow to combine OSGi with application compiled
> with graalVM/native-image, and maybe Atomos already supports this. In the
> meantime, I need to use the old apache Felix Connect library in GraalVM
> substrate/native-image environment.
> To do so, there might be few adaptions to be done in Felix Connect. One is
> about how bundles are scanned by the *ClasspathScanner* class. Currently,
> this class provides a "scanForBundles" method which looks for all bundle URLS
> available from the classpath, using:
> {code:java}
> Enumeration ClassLoader.getResources("META-INF/MANIFEST.MF") {code}
> This works fine in classpath environment, and collected URLS (jar:file) are
> then used to create BundleDescriptors. Each BundleDescriptor can then get
> access to bundle content using the URL.
> The ClassLoader.getResource method returns for instance URLS like:
> {code:java}
> jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.gogo.command-1.1.0.jar!/META-INF/MANIFEST.MF
> jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.metatype-1.2.2.jar!/META-INF/MANIFEST.MF
> etc ...{code}
> But in compiled applications (using substrate/native image), the
> ClassLoader.getResources("META-INF/MANIFEST.MF") method returns an
> enumeration of URLS which are all the same (using "resource" protocol) for
> all found bundles. For example, for gogo and metatype bundles in the example
> above, the ClassLoader.getResources("META-INF/MANIFEST.MF") would return
> these same urls:
> {code:java}
> resource:META-INF/MANIFEST.MF
> resource:META-INF/MANIFEST.MF {code}
> this is problematic, because it's not possible to load resources from a
> bundle using a unique jar:file url. Moreover, in native-image, using the
> "resource" url seems to cause problems, and it seems we can only open and
> read "resource" input stream only one time. I also observed some exceptions
> when reading "resource" inputstreams, like this:
> {code:java}
> DEBUG: bundle jaxrs.hello:0.0.0 (11)BundleComponentActivator : Descriptor
> locations OSGI-INF/sample.jaxrs.HelloDS.xml
> java.io.IOException: Stream closed
> at
> java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:165)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:271)
> at
> org.apache.felix.connect.URLRevision.getUrlContent(URLRevision.java:131)
> at
> org.apache.felix.connect.URLRevision.getEntries(URLRevision.java:73)
> at
> org.apache.felix.connect.EntryFilterEnumeration.(EntryFilterEnumeration.java:52)
> at
> org.apache.felix.connect.PojoSRBundle.findEntries(PojoSRBundle.java:486)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.findDescriptors(BundleComponentActivator.java:413)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:313)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:263)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:551)
> at org.apache.felix.scr.impl.Activator.access$200(Activator.java:69)
> at
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:424)
> at
> org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
> at
>
[jira] [Commented] (FELIX-6284) Felix Connect Native-Image support
[
https://issues.apache.org/jira/browse/FELIX-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125281#comment-17125281
]
Pierre De Rop commented on FELIX-6284:
--
Thanks Tom for sharing the info.
Since I need a release of the Felix Connect soon, I would like to first commit
the simple work around I provided in the PR linked to this jira. It is
certainly not as robust as the solution you have designed for Atomos, but it
allows me to go ahead until the new Felix Connect R8 is released. Once it is
release, I will switch to it.
thanks.
> Felix Connect Native-Image support
> --
>
> Key: FELIX-6284
> URL: https://issues.apache.org/jira/browse/FELIX-6284
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> The upcoming OSGi R8 will allow to combine OSGi with application compiled
> with graalVM/native-image, and maybe Atomos already supports this. In the
> meantime, I need to use the old apache Felix Connect library in GraalVM
> substrate/native-image environment.
> To do so, there might be few adaptions to be done in Felix Connect. One is
> about how bundles are scanned by the *ClasspathScanner* class. Currently,
> this class provides a "scanForBundles" method which looks for all bundle URLS
> available from the classpath, using:
> {code:java}
> Enumeration ClassLoader.getResources("META-INF/MANIFEST.MF") {code}
> This works fine in classpath environment, and collected URLS (jar:file) are
> then used to create BundleDescriptors. Each BundleDescriptor can then get
> access to bundle content using the URL.
> The ClassLoader.getResource method returns for instance URLS like:
> {code:java}
> jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.gogo.command-1.1.0.jar!/META-INF/MANIFEST.MF
> jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.metatype-1.2.2.jar!/META-INF/MANIFEST.MF
> etc ...{code}
> But in compiled applications (using substrate/native image), the
> ClassLoader.getResources("META-INF/MANIFEST.MF") method returns an
> enumeration of URLS which are all the same (using "resource" protocol) for
> all found bundles. For example, for gogo and metatype bundles in the example
> above, the ClassLoader.getResources("META-INF/MANIFEST.MF") would return
> these same urls:
> {code:java}
> resource:META-INF/MANIFEST.MF
> resource:META-INF/MANIFEST.MF {code}
> this is problematic, because it's not possible to load resources from a
> bundle using a unique jar:file url. Moreover, in native-image, using the
> "resource" url seems to cause problems, and it seems we can only open and
> read "resource" input stream only one time. I also observed some exceptions
> when reading "resource" inputstreams, like this:
> {code:java}
> DEBUG: bundle jaxrs.hello:0.0.0 (11)BundleComponentActivator : Descriptor
> locations OSGI-INF/sample.jaxrs.HelloDS.xml
> java.io.IOException: Stream closed
> at
> java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:165)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:271)
> at
> org.apache.felix.connect.URLRevision.getUrlContent(URLRevision.java:131)
> at
> org.apache.felix.connect.URLRevision.getEntries(URLRevision.java:73)
> at
> org.apache.felix.connect.EntryFilterEnumeration.(EntryFilterEnumeration.java:52)
> at
> org.apache.felix.connect.PojoSRBundle.findEntries(PojoSRBundle.java:486)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.findDescriptors(BundleComponentActivator.java:413)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:313)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:263)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:551)
> at org.apache.felix.scr.impl.Activator.access$200(Activator.java:69)
> at
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:424)
> at
> org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:420)
> at
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
> at
>
[jira] [Commented] (FELIX-6282) Felix Connect R7 support
[
https://issues.apache.org/jira/browse/FELIX-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125177#comment-17125177
]
Pierre De Rop commented on FELIX-6282:
--
Hi Karl,
ok, I'll commit the patch, thanks for the review. I have no problem with
keeping the version in 0.x range.
PS: please also consider the new FELIX-6284 issue I just created, thanks.
> Felix Connect R7 support
>
>
> Key: FELIX-6282
> URL: https://issues.apache.org/jira/browse/FELIX-6282
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> The Felix Connect library seems to be almost ready for OSGi R7 support.
> At least, modifying the project's pom in order to depend on
> org.osgi:osgi.core:7.0.0 allows to use recent declarative service,
> configadmin, metatype, etc ...
> There is one minor issue: the support for FrameworkWiringDTO is missing (even
> if it's not really useful in the context of felix connect): in the following
> code, the adapt method returns null:
> {code:java}
> Bundle system = _ctx.getBundle(0);
> FrameworkWiringDTO wiring = system.adapt(FrameworkWiringDTO.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FELIX-6284) Felix Connect Native-Image support
Pierre De Rop created FELIX-6284:
Summary: Felix Connect Native-Image support
Key: FELIX-6284
URL: https://issues.apache.org/jira/browse/FELIX-6284
Project: Felix
Issue Type: Improvement
Components: Connect
Affects Versions: connect-0.2.0
Reporter: Pierre De Rop
Assignee: Pierre De Rop
The upcoming OSGi R8 will allow to combine OSGi with application compiled with
graalVM/native-image, and maybe Atomos already supports this. In the meantime,
I need to use the old apache Felix Connect library in GraalVM
substrate/native-image environment.
To do so, there might be few adaptions to be done in Felix Connect. One is
about how bundles are scanned by the *ClasspathScanner* class. Currently, this
class provides a "scanForBundles" method which looks for all bundle URLS
available from the classpath, using:
{code:java}
Enumeration ClassLoader.getResources("META-INF/MANIFEST.MF") {code}
This works fine in classpath environment, and collected URLS (jar:file) are
then used to create BundleDescriptors. Each BundleDescriptor can then get
access to bundle content using the URL.
The ClassLoader.getResource method returns for instance URLS like:
{code:java}
jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.gogo.command-1.1.0.jar!/META-INF/MANIFEST.MF
jar:file:/home/pderop/felix.connect/bundles/org.apache.felix.metatype-1.2.2.jar!/META-INF/MANIFEST.MF
etc ...{code}
But in compiled applications (using substrate/native image), the
ClassLoader.getResources("META-INF/MANIFEST.MF") method returns an enumeration
of URLS which are all the same (using "resource" protocol) for all found
bundles. For example, for gogo and metatype bundles in the example above, the
ClassLoader.getResources("META-INF/MANIFEST.MF") would return these same urls:
{code:java}
resource:META-INF/MANIFEST.MF
resource:META-INF/MANIFEST.MF {code}
this is problematic, because it's not possible to load resources from a bundle
using a unique jar:file url. Moreover, in native-image, using the "resource"
url seems to cause problems, and it seems we can only open and read "resource"
input stream only one time. I also observed some exceptions when reading
"resource" inputstreams, like this:
{code:java}
DEBUG: bundle jaxrs.hello:0.0.0 (11)BundleComponentActivator : Descriptor
locations OSGI-INF/sample.jaxrs.HelloDS.xml
java.io.IOException: Stream closed
at java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:165)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
at java.io.BufferedInputStream.read(BufferedInputStream.java:271)
at
org.apache.felix.connect.URLRevision.getUrlContent(URLRevision.java:131)
at org.apache.felix.connect.URLRevision.getEntries(URLRevision.java:73)
at
org.apache.felix.connect.EntryFilterEnumeration.(EntryFilterEnumeration.java:52)
at
org.apache.felix.connect.PojoSRBundle.findEntries(PojoSRBundle.java:486)
at
org.apache.felix.scr.impl.BundleComponentActivator.findDescriptors(BundleComponentActivator.java:413)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:313)
at
org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:263)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:551)
at org.apache.felix.scr.impl.Activator.access$200(Activator.java:69)
at
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:424)
at
org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
at
org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169)
at
org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:420)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
at
org.apache.felix.connect.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:821)
at
org.apache.felix.connect.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:771)
at
org.apache.felix.connect.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:510)
at org.apache.felix.connect.PojoSRBundle.start(PojoSRBundle.java:157)
at org.apache.felix.connect.PojoSR.startBundles(PojoSR.java:286)
at com.nokia.as.service.felixconnect.impl.Launch.start(Launch.java:161)
at com.nokia.as.service.felixconnect.impl.Launch.main(Launch.java:76)
{code}
I
[jira] [Resolved] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService
[
https://issues.apache.org/jira/browse/FELIX-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop resolved FELIX-6180.
--
Resolution: Fixed
> Component initialization error message get's printed to sysout instead of
> logged to LogService
> --
>
> Key: FELIX-6180
> URL: https://issues.apache.org/jira/browse/FELIX-6180
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r16
>
> Attachments: FELIX-6180.patch
>
>
> We had a broken component that failed to start (for a good reason):
> {code:java}
> @Component(provides = Object.class)
> public class BrokenComponent {
> static final Locale defaultLocale =
> Locale.forLanguageTag(System.getProperty("not.set"));
> }
> {code}
> The problem is not that it doesn't work BUT the error log (see below) never
> reached our central logging (which is consuming the log messages from the
> LogService).
> I this is caused by the fact that this is not an {{Exception}} but an
> {{Error}}, that makes it propagate all the way to the {{SerialExecutor}}
> which is initialized with a new {{Logger}} instance in {{ComponentImpl}}
> instead of getting the {{Logger}} instance that was used to create the
> {{ComponentImpl}}.
> {code}
> ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
> at
> org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
> at
> org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
> at
> org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
> at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
> at
> org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
> at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
> at
> org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
> at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
> at my.project.Activator.init(Activator.java:84)
> at
> org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at aQute.launcher.Launcher.startBundles(Launcher.java:528)
> at aQute.launcher.Launcher.activate(Launcher.java:427)
> at aQute.launcher.Launcher.run(Launcher.java:306)
> at aQute.launcher.Launcher.main(Launcher.java:152)
> at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
> Caused by: java.lang.NullPointerException
> at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
> at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
> at java.util.Locale.forLanguageTag(Locale.java:1568)
> at MyBrokenComponent.(UserTransformerV1_2.java:17)
> ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6282) Felix Connect R7 support
[
https://issues.apache.org/jira/browse/FELIX-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120926#comment-17120926
]
Pierre De Rop commented on FELIX-6282:
--
Added PR #24.
> Felix Connect R7 support
>
>
> Key: FELIX-6282
> URL: https://issues.apache.org/jira/browse/FELIX-6282
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Affects Versions: connect-0.2.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> The Felix Connect library seems to be almost ready for OSGi R7 support.
> At least, modifying the project's pom in order to depend on
> org.osgi:osgi.core:7.0.0 allows to use recent declarative service,
> configadmin, metatype, etc ...
> There is one minor issue: the support for FrameworkWiringDTO is missing (even
> if it's not really useful in the context of felix connect): in the following
> code, the adapt method returns null:
> {code:java}
> Bundle system = _ctx.getBundle(0);
> FrameworkWiringDTO wiring = system.adapt(FrameworkWiringDTO.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FELIX-6282) Felix Connect R7 support
Pierre De Rop created FELIX-6282:
Summary: Felix Connect R7 support
Key: FELIX-6282
URL: https://issues.apache.org/jira/browse/FELIX-6282
Project: Felix
Issue Type: Improvement
Components: Connect
Affects Versions: connect-0.2.0
Reporter: Pierre De Rop
Assignee: Pierre De Rop
The Felix Connect library seems to be almost ready for OSGi R7 support.
At least, modifying the project's pom in order to depend on
org.osgi:osgi.core:7.0.0 allows to use recent declarative service, configadmin,
metatype, etc ...
There is one minor issue: the support for FrameworkWiringDTO is missing (even
if it's not really useful in the context of felix connect): in the following
code, the adapt method returns null:
{code:java}
Bundle system = _ctx.getBundle(0);
FrameworkWiringDTO wiring = system.adapt(FrameworkWiringDTO.class);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1711#comment-1711 ] Pierre De Rop commented on FELIX-5860: -- Thanks Karl, I'm relieved by your message because it's a long time I got no news about this issue, and I think all is in place to go for a release: declarative service works, etc ... So, I'll submit a first PR for this Jira (it will contain the FELIX-5860 patch currently attached to this issue). I'll also create another Jira because I need to add another small patch for the support of substrate-vm/native image. thanks. > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5860: - Comment: was deleted (was: it looks like there is no more activities on this issue, I got no comments about my patch since last november, maybe because the upcoming new OSGi Connect will replace the old Felix Connect ? Anyway, since I need Felix Connect running on recent felix R7 frameworks, I prefer to create another fresh Jira issue, I'll provide a pull request, and if no one objects, I'll merge it and will call for a vote. thanks.) > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119726#comment-17119726 ] Pierre De Rop commented on FELIX-5860: -- it looks like there is no more activities on this issue, I got no comments about my patch since last november, maybe because the upcoming new OSGi Connect will replace the old Felix Connect ? Anyway, since I need Felix Connect running on recent felix R7 frameworks, I prefer to create another fresh Jira issue, I'll provide a pull request, and if no one objects, I'll merge it and will call for a vote. thanks. > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-6278) Update Dependency Manager with latest bndtools 5.0.1
[ https://issues.apache.org/jira/browse/FELIX-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop resolved FELIX-6278. -- Resolution: Fixed The project now builds using bndtools 5.0.1. I had to adapt the annotation runtime, because something changed in the bndtools class scanner: Annotations with Character attributes are now parsed differently by bnd parser ... See JSONMetaData.java in dm runtime project. > Update Dependency Manager with latest bndtools 5.0.1 > > > Key: FELIX-6278 > URL: https://issues.apache.org/jira/browse/FELIX-6278 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r16 > > > felix dependency manager is built using an old bndtools 3.0.5. Let's update > the project with latest bndtools 5.0.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6278) Update Dependency Manager with latest bndtools 5.0.1
[ https://issues.apache.org/jira/browse/FELIX-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-6278: - Fix Version/s: org.apache.felix.dependencymanager-r16 > Update Dependency Manager with latest bndtools 5.0.1 > > > Key: FELIX-6278 > URL: https://issues.apache.org/jira/browse/FELIX-6278 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r16 > > > felix dependency manager is built using an old bndtools 3.0.5. Let's update > the project with latest bndtools 5.0.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6278) Update Dependency Manager with latest bndtools 5.0.1
Pierre De Rop created FELIX-6278: Summary: Update Dependency Manager with latest bndtools 5.0.1 Key: FELIX-6278 URL: https://issues.apache.org/jira/browse/FELIX-6278 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Pierre De Rop Assignee: Pierre De Rop felix dependency manager is built using an old bndtools 3.0.5. Let's update the project with latest bndtools 5.0.1 version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967024#comment-16967024 ] Pierre De Rop edited comment on FELIX-5860 at 1/20/20 11:21 PM: Hi, So, I have attached a small patch (see FELIX-5860.patch) which builds the project using org.osgi:osgi.core:7.0.0. The dependency on org.osgi:osgi.cmpn:7.0.0 has been removed from the pom. Finally, I added a small fix for the missing org.osgi.framework.wiring.dto.FrameworkWiringDTO in the DTOFactory.java Maybe someone would like to review ? if nobody objects, then I'd like to go ahead with all this and commit the proposed patch. thanks. was (Author: pderop): Hi, So, I have attached a small patch (see FELIX-5860.patch) which builds the project using org.osgi:osgi.core:7.0.0, and org.osgi:osgi.cmpn:7.0.0. I also had to use a more recent version of the animal-sniffer-maven-plugin, because with the 1.5 version, I got an odd ArrayIndexOutOfBoundsException. Finally, I added the missing org.osgi.framework.wiring.dto.FrameworkWiringDTO in the DTOFactory.java Maybe someone would like to review ? if nobody objects, then I'd like to go ahead with all this and commit the proposed patch. thanks. > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5860: - Attachment: (was: FELIX-5860.patch) > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5860: - Attachment: FELIX-5860.patch > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6201) Page not found
[ https://issues.apache.org/jira/browse/FELIX-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16973117#comment-16973117 ] Pierre De Rop commented on FELIX-6201: -- Hello; You will find the documentation here: https://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/design-patterns.html Let us know if you need help, Regards > Page not found > -- > > Key: FELIX-6201 > URL: https://issues.apache.org/jira/browse/FELIX-6201 > Project: Felix > Issue Type: Bug >Reporter: Ashwani Sahni >Priority: Major > > Hi Team, > I want to access > [http://felix.apache.org/site/apache-felix-dependency-manager-osgi-design-patterns.html] > . But it's not available. > Can you please help me to find the content or location if it was moved to > other place. > Thanks, > Ashwani Sahni -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5860: - Attachment: FELIX-5860.patch > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967024#comment-16967024 ] Pierre De Rop commented on FELIX-5860: -- Hi, So, I have attached a small patch (see FELIX-5860.patch) which builds the project using org.osgi:osgi.core:7.0.0, and org.osgi:osgi.cmpn:7.0.0. I also had to use a more recent version of the animal-sniffer-maven-plugin, because with the 1.5 version, I got an odd ArrayIndexOutOfBoundsException. Finally, I added the missing org.osgi.framework.wiring.dto.FrameworkWiringDTO in the DTOFactory.java Maybe someone would like to review ? if nobody objects, then I'd like to go ahead with all this and commit the proposed patch. thanks. > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > Attachments: FELIX-5860.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960692#comment-16960692 ] Pierre De Rop commented on FELIX-5860: -- Hello Jean-Baptiste, Any updates about this old issue ? For the R7 support, it looks like updating the pom.xml to just depend on org.osgi:osgi.core:7.0.0, and org.osgi:osgi.cmpn:7.0.0 would be enough, right ? From my side, I did the test, and it seems to work well. Maybe the support for the R7 org.osgi.framework.wiring.dto.FrameworkWiringDTO should be added, but apart from that it seems work well when rebuilding the felix connect with core:7.0.0 and cmpn:7.0.0 any other things to be done ? would you have time to work on this ? let me know if I can help ? thanks & regards > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: connect-0.3.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService
[
https://issues.apache.org/jira/browse/FELIX-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928054#comment-16928054
]
Pierre De Rop commented on FELIX-6180:
--
I just have committed your patch in the trunk, thanks a lot Bram !
> Component initialization error message get's printed to sysout instead of
> logged to LogService
> --
>
> Key: FELIX-6180
> URL: https://issues.apache.org/jira/browse/FELIX-6180
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r16
>
> Attachments: FELIX-6180.patch
>
>
> We had a broken component that failed to start (for a good reason):
> {code:java}
> @Component(provides = Object.class)
> public class BrokenComponent {
> static final Locale defaultLocale =
> Locale.forLanguageTag(System.getProperty("not.set"));
> }
> {code}
> The problem is not that it doesn't work BUT the error log (see below) never
> reached our central logging (which is consuming the log messages from the
> LogService).
> I this is caused by the fact that this is not an {{Exception}} but an
> {{Error}}, that makes it propagate all the way to the {{SerialExecutor}}
> which is initialized with a new {{Logger}} instance in {{ComponentImpl}}
> instead of getting the {{Logger}} instance that was used to create the
> {{ComponentImpl}}.
> {code}
> ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
> at
> org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
> at
> org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
> at
> org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
> at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
> at
> org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
> at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
> at
> org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
> at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
> at my.project.Activator.init(Activator.java:84)
> at
> org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at aQute.launcher.Launcher.startBundles(Launcher.java:528)
> at aQute.launcher.Launcher.activate(Launcher.java:427)
> at aQute.launcher.Launcher.run(Launcher.java:306)
> at aQute.launcher.Launcher.main(Launcher.java:152)
> at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
> Caused by: java.lang.NullPointerException
> at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
> at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
> at java.util.Locale.forLanguageTag(Locale.java:1568)
> at MyBrokenComponent.(UserTransformerV1_2.java:17)
> ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService
[
https://issues.apache.org/jira/browse/FELIX-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-6180:
-
Fix Version/s: org.apache.felix.dependencymanager-r16
> Component initialization error message get's printed to sysout instead of
> logged to LogService
> --
>
> Key: FELIX-6180
> URL: https://issues.apache.org/jira/browse/FELIX-6180
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r16
>
> Attachments: FELIX-6180.patch
>
>
> We had a broken component that failed to start (for a good reason):
> {code:java}
> @Component(provides = Object.class)
> public class BrokenComponent {
> static final Locale defaultLocale =
> Locale.forLanguageTag(System.getProperty("not.set"));
> }
> {code}
> The problem is not that it doesn't work BUT the error log (see below) never
> reached our central logging (which is consuming the log messages from the
> LogService).
> I this is caused by the fact that this is not an {{Exception}} but an
> {{Error}}, that makes it propagate all the way to the {{SerialExecutor}}
> which is initialized with a new {{Logger}} instance in {{ComponentImpl}}
> instead of getting the {{Logger}} instance that was used to create the
> {{ComponentImpl}}.
> {code}
> ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
> at
> org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
> at
> org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
> at
> org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
> at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
> at
> org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
> at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
> at
> org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
> at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
> at my.project.Activator.init(Activator.java:84)
> at
> org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at aQute.launcher.Launcher.startBundles(Launcher.java:528)
> at aQute.launcher.Launcher.activate(Launcher.java:427)
> at aQute.launcher.Launcher.run(Launcher.java:306)
> at aQute.launcher.Launcher.main(Launcher.java:152)
> at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
> Caused by: java.lang.NullPointerException
> at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
> at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
> at java.util.Locale.forLanguageTag(Locale.java:1568)
> at MyBrokenComponent.(UserTransformerV1_2.java:17)
> ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService
[
https://issues.apache.org/jira/browse/FELIX-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop reassigned FELIX-6180:
Assignee: Pierre De Rop
Thanks Bram, I'll take a look.
> Component initialization error message get's printed to sysout instead of
> logged to LogService
> --
>
> Key: FELIX-6180
> URL: https://issues.apache.org/jira/browse/FELIX-6180
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: FELIX-6180.patch
>
>
> We had a broken component that failed to start (for a good reason):
> {code:java}
> @Component(provides = Object.class)
> public class BrokenComponent {
> static final Locale defaultLocale =
> Locale.forLanguageTag(System.getProperty("not.set"));
> }
> {code}
> The problem is not that it doesn't work BUT the error log (see below) never
> reached our central logging (which is consuming the log messages from the
> LogService).
> I this is caused by the fact that this is not an {{Exception}} but an
> {{Error}}, that makes it propagate all the way to the {{SerialExecutor}}
> which is initialized with a new {{Logger}} instance in {{ComponentImpl}}
> instead of getting the {{Logger}} instance that was used to create the
> {{ComponentImpl}}.
> {code}
> ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
> at
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
> at
> org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
> at
> org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
> at
> org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
> at
> org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
> at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
> at
> org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
> at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
> at
> org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
> at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
> at my.project.Activator.init(Activator.java:84)
> at
> org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at aQute.launcher.Launcher.startBundles(Launcher.java:528)
> at aQute.launcher.Launcher.activate(Launcher.java:427)
> at aQute.launcher.Launcher.run(Launcher.java:306)
> at aQute.launcher.Launcher.main(Launcher.java:152)
> at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
> Caused by: java.lang.NullPointerException
> at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
> at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
> at java.util.Locale.forLanguageTag(Locale.java:1568)
> at MyBrokenComponent.(UserTransformerV1_2.java:17)
> ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (FELIX-5998) NPE in Resolver checkPackageSpaceConsistency
[
https://issues.apache.org/jira/browse/FELIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761268#comment-16761268
]
Pierre De Rop commented on FELIX-5998:
--
I have two questions:
* regarding your last comment, do you mean that there may be an issue if the
BundleRepository Resource "equals" method is not symetric (like r1.equals(r2)
!= t2.equals(r1)) ? I have looked into the source code of the BundleRepostory
Resource "equals" method (see [1]), and it seems to me that the
FelixResourceAdapter.equals method is symetric (it sounds like).
* what do you think about the missing equals/hashcode methods in the
WrappedResource class ? shouldn't we add these methods in that class (the
WrappedCapability class implements equals/hashcode methods, while the
WrappedResource does not) ?
[1]
http://svn.apache.org/viewvc/felix/trunk/bundlerepository/src/main/java/org/apache/felix/bundlerepository/impl/FelixResourceAdapter.java?revision=1829639=markup
> NPE in Resolver checkPackageSpaceConsistency
>
>
> Key: FELIX-5998
> URL: https://issues.apache.org/jira/browse/FELIX-5998
> Project: Felix
> Issue Type: Task
> Components: Resolver
>Affects Versions: resolver-2.0.0
>Reporter: Pierre De Rop
>Priority: Major
>
> I'm using a custom ResolveContext implementation that I've written in order
> to calculate the dependencies of some applications which bundles are all
> centralized in an OBR. Now, using the Felix framework 6.0.1 (and the Resolver
> 2.0.0 that is provided by the framework), I sometimes get an NPE in the
> ResolverImpl.checkPackageSpaceConsistency, line 1319).
> My OBR is not yet fully "curated" (I still have some " Candidate permutation
> failed due to a conflict between imports" logs when enabling
> felix.log.level=4). So I'm cleaning the OBR gradually, but now, sometimes I
> see this NPE while resolving :
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1319)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:622)
> at
> org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:575)
> at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:438)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:414)
> at
> com.nokia.as.microfeatures.bundlerepository.impl.BundleRepositoryImpl.findResolution(BundleRepositoryImpl.java:257)
> {code}
> The bad thing is that I'm not able to reproduce the NPE when I enable
> felix.log.level=4, and the NPE is difficult to reproduce.
> Could someone please give me a clue about what could produce this NPE ? Are
> there some traces which could be added in order to figure out what is the
> problem ? Then is there a fix which should be done in order to avoid this
> null pointer ?
> If I fully cleanup my OBR, maybe I won't have anymore the NPE, but I just
> wanted to report it here.
> thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5998) NPE in Resolver checkPackageSpaceConsistency
[
https://issues.apache.org/jira/browse/FELIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761240#comment-16761240
]
Pierre De Rop commented on FELIX-5998:
--
I confirm that when I'm getting the NPE, then the classnames of the keys
inserted in the resourcePkgMap are all of the
"org.apache.felix.bundlerepository.impl.FelixResourceAdapter" type.
I have modified my trace like this:
{code:java}
for (Map.Entry entries : resourcePkgMap.entrySet()) {
System.out.println("key.toString=" + entries.getKey() + ", key.className="
+ entries.getKey().getClass().getName() + ", key.hashCode=" +
entries.getKey().hashCode());
}
{code}
and indeed, the trace for the resource causing the NPE is like this:
{code}
key.toString=com.nokia.as.util.jartool;1.0.0.RELEASE;osgi.bundle,
key.className=org.apache.felix.bundlerepository.impl.FelixResourceAdapter,
key.hashCode=1931656772
{code}
> NPE in Resolver checkPackageSpaceConsistency
>
>
> Key: FELIX-5998
> URL: https://issues.apache.org/jira/browse/FELIX-5998
> Project: Felix
> Issue Type: Task
> Components: Resolver
>Affects Versions: resolver-2.0.0
>Reporter: Pierre De Rop
>Priority: Major
>
> I'm using a custom ResolveContext implementation that I've written in order
> to calculate the dependencies of some applications which bundles are all
> centralized in an OBR. Now, using the Felix framework 6.0.1 (and the Resolver
> 2.0.0 that is provided by the framework), I sometimes get an NPE in the
> ResolverImpl.checkPackageSpaceConsistency, line 1319).
> My OBR is not yet fully "curated" (I still have some " Candidate permutation
> failed due to a conflict between imports" logs when enabling
> felix.log.level=4). So I'm cleaning the OBR gradually, but now, sometimes I
> see this NPE while resolving :
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1319)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:622)
> at
> org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:575)
> at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:438)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:414)
> at
> com.nokia.as.microfeatures.bundlerepository.impl.BundleRepositoryImpl.findResolution(BundleRepositoryImpl.java:257)
> {code}
> The bad thing is that I'm not able to reproduce the NPE when I enable
> felix.log.level=4, and the NPE is difficult to reproduce.
> Could someone please give me a clue about what could produce this NPE ? Are
> there some traces which could be added in order to figure out what is the
> problem ? Then is there a fix which should be done in order to avoid this
> null pointer ?
> If I fully cleanup my OBR, maybe I won't have anymore the NPE, but I just
> wanted to report it here.
> thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5998) NPE in Resolver checkPackageSpaceConsistency
[
https://issues.apache.org/jira/browse/FELIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761080#comment-16761080
]
Pierre De Rop commented on FELIX-5998:
--
Hello Thomas,
I came across the same exception again, and I'd like to have your opinion . So
this time I have been able to reproduce the problem more easily and I have
added some traces in the resolver; so I observed the following scenario:
So, at some point, the ResolverImpl.checkPackageSpaceConsistency is called:
{code:java}
private ResolutionError checkPackageSpaceConsistency(
ResolveSession session,
Resource resource,
Candidates allCandidates,
boolean dynamic,
Map resourcePkgMap,
Map resultCache)
{
{code}
And the second "resource" parameter is set to a "com.alcatel.as.utils" resource
found from an OBR , using a ResolveContext implementation (notice that the
"com.alcatel.as.utils" resource bundle has some fragments).
So sometimes (rarely), the following code in the checkPackageSpaceConsistency
method does not find the "com.alcatel.as.utils" resource from the
resourcePkgMap map:
{code:java}
Packages pkgs = resourcePkgMap.get(resource);
{code}
So, the above method call returns null, and pkgs is null, this is why I'm
having the NPE initally reported in this Jira issue.
Now, I have dumped the following infos about the resource parameter:
{code:java}
resource.toString () returns
"com.alcatel.as.utils;2.5.1.RELEASE;osgi.bundle"
resource.hashCode()returns 1244348781
resource.getClass().getNames() returns
"org.apache.felix.resolver.WrappedResource"{code}
So, the hascode of the resource parameter is 1244348781. Now, I have dumped
content of all the resourcePkgMap keys, for each one I have called the key
toString() and key hashcode v methods using this code (when the resource is not
found from the resourcePkgMap):
{code:java}
for (Map.Entry entries : resourcePkgMap.entrySet()) {
System.out.println("hash of " + entries.getKey() + "=" +
entries.getKey().hashCode());
}
{code}
And interestingly, I see the the "com.alcatel.as.utils" resource is present,
but with a different hashcode, this is why the resource is not found:
{code:java}
hash of com.alcatel.as.utils;2.5.1.RELEASE;osgi.bundle=342519251
{code}
So, we see that the second "resource" parameter has 1244348781, but in the
resourcePkgMap, the same resource is present but with another Resource
instance, with another 342519251 hashcode. This is why the resource is not
found from the resourcePkgMap.
Now, I don't know if the following patch is making sense (or not ?), but I
tried to add the following equals/hashcode methods in the WrappedResource.java
from the Resolver, and suprisingly, the patch seems to have resolved the issue
(I have run a test all night long, without reproducing any NPE):
{code:java}
package org.apache.felix.resolver;
import java.util.*;
class WrappedResource implements Resource
{
...
@Override
public boolean equals(Object o)
{
if (o instanceof WrappedResource) {
return m_host.equals(((WrappedResource) o).m_host);
} else if (o instanceof Resource) {
return m_host.equals(o);
} else {
return false;
}
}
@Override
public int hashCode()
{
return m_host.hashCode();
}
{code}
So, do you think that adding some equals/hashcode methods in the
WrappedResource is making sense (notice the the WrappedCapability class is
defining some equals/hashcode methods.; not the WrappedResource class) ?
Otherwise, I would then need to investigate the ResolveContext implementation
I'm using ?
thanks for your help.
> NPE in Resolver checkPackageSpaceConsistency
>
>
> Key: FELIX-5998
> URL: https://issues.apache.org/jira/browse/FELIX-5998
> Project: Felix
> Issue Type: Task
> Components: Resolver
>Affects Versions: resolver-2.0.0
>Reporter: Pierre De Rop
>Priority: Major
>
> I'm using a custom ResolveContext implementation that I've written in order
> to calculate the dependencies of some applications which bundles are all
> centralized in an OBR. Now, using the Felix framework 6.0.1 (and the Resolver
> 2.0.0 that is provided by the framework), I sometimes get an NPE in the
> ResolverImpl.checkPackageSpaceConsistency, line 1319).
> My OBR is not yet fully "curated" (I still have some " Candidate permutation
> failed due to a conflict between imports" logs when enabling
> felix.log.level=4). So I'm cleaning the OBR gradually, but now, sometimes I
> see this NPE while resolving :
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1319)
> at
>
[jira] [Updated] (FELIX-5996) Remove generic parameter in DM Component interface
[
https://issues.apache.org/jira/browse/FELIX-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5996:
-
Fix Version/s: org.apache.felix.dependencymanager-r15
> Remove generic parameter in DM Component interface
> --
>
> Key: FELIX-5996
> URL: https://issues.apache.org/jira/browse/FELIX-5996
> Project: Felix
> Issue Type: Task
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r13
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r15
>
> Attachments: dependencymanager.FELIX-5996.tgz
>
>
> Since dm-r13, the Component interface is now taking a generic parameter so it
> make it easier to define extended components like adapters.
> So, with this new model, it looks like the following:
> {code:java}
> public interface Component> {
>T setInterface(String service, Dictionary properties)
>T setImplementation(Object ob);
>...
> }
> public interface AdapterComponent extends Component {
>AdapterComponent setAdaptee(Class service, String filter);
>AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
>...
> }
> {code}
> and you can now do something like this:
> {code:java}
> Component adapter = createAdapterComponent()
> .setAdaptee(Adaptee.class, "(foo=bar)")
> .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
> .setImplementation(AdapterImpl.class)
> .setInterface(AdapterService.class, null)
> .add(createServiceDependency().setService(LogService.class));
> {code}
> now, while using the generic parameter simplify the declaration of component
> adapters, it has a drawback: the Component now takes a generic parameter, and
> old code using simple components now generates a compilation warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> so, the above example generates a compilation warning, and you now have to
> declare "?" in order to get rid of the warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> that being said, maybe we can refactor in order to get rid of the generic
> parameter, by copying the top level component methods in sub interfaces, like
> this:
> {code:java}
> public interface Component {
> Component setInterface(String service, Dictionary properties);
> Component setImplementation(Object ob);
> ...
> }
> public interface AdapterComponent extends Component
> {
> // Component methods with specialized signatures
> AdapterComponent setInterface(String service, Dictionary properties)
> AdapterComponent setImplementation(Object ob);
> // AdapterComponent methods
> AdapterComponent methods AdapterComponent setAdaptee(Class service, String
> filter);
> AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5996) Remove generic parameter in DM Component interface
[
https://issues.apache.org/jira/browse/FELIX-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop resolved FELIX-5996.
--
Resolution: Fixed
Committed a patch in rv 1849304, and now no more generic parameters are used.
Added a temporary "fixupmessages" declaration in
org.apache.felix.dependencymanager/bnd.bnd, in order to avoid forcing to bump
major version. The binaries are compatible. However if some code that has been
built with r14 version is defining a "Component" generic parameter, then the
code will have to be changed and the generic parameter will have to be removed.
As this is a build time issue; not having a major version bump is ok.
> Remove generic parameter in DM Component interface
> --
>
> Key: FELIX-5996
> URL: https://issues.apache.org/jira/browse/FELIX-5996
> Project: Felix
> Issue Type: Task
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r13
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Attachments: dependencymanager.FELIX-5996.tgz
>
>
> Since dm-r13, the Component interface is now taking a generic parameter so it
> make it easier to define extended components like adapters.
> So, with this new model, it looks like the following:
> {code:java}
> public interface Component> {
>T setInterface(String service, Dictionary properties)
>T setImplementation(Object ob);
>...
> }
> public interface AdapterComponent extends Component {
>AdapterComponent setAdaptee(Class service, String filter);
>AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
>...
> }
> {code}
> and you can now do something like this:
> {code:java}
> Component adapter = createAdapterComponent()
> .setAdaptee(Adaptee.class, "(foo=bar)")
> .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
> .setImplementation(AdapterImpl.class)
> .setInterface(AdapterService.class, null)
> .add(createServiceDependency().setService(LogService.class));
> {code}
> now, while using the generic parameter simplify the declaration of component
> adapters, it has a drawback: the Component now takes a generic parameter, and
> old code using simple components now generates a compilation warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> so, the above example generates a compilation warning, and you now have to
> declare "?" in order to get rid of the warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> that being said, maybe we can refactor in order to get rid of the generic
> parameter, by copying the top level component methods in sub interfaces, like
> this:
> {code:java}
> public interface Component {
> Component setInterface(String service, Dictionary properties);
> Component setImplementation(Object ob);
> ...
> }
> public interface AdapterComponent extends Component
> {
> // Component methods with specialized signatures
> AdapterComponent setInterface(String service, Dictionary properties)
> AdapterComponent setImplementation(Object ob);
> // AdapterComponent methods
> AdapterComponent methods AdapterComponent setAdaptee(Class service, String
> filter);
> AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5998) NPE in Resolver checkPackageSpaceConsistency
[
https://issues.apache.org/jira/browse/FELIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16720404#comment-16720404
]
Pierre De Rop commented on FELIX-5998:
--
Thanks Thomas for the suggestions;
I checked and I don't think the implementation of Capability is returning null
for the getResources() method.
Actually, I could figure out what was wrong: the problem apparently came from a
wrongly configured org.osgi.framework.system.packages.extra property, which was
containing invalid extra system packages (some packages were defined while they
were already exported by the framework, like org.w3c.dom.css). After having
fixed my org.osgi.framework.system.packages.extra configuration, then the NPE
disappeared.
I will close this issue:
thanks for your quick response.
> NPE in Resolver checkPackageSpaceConsistency
>
>
> Key: FELIX-5998
> URL: https://issues.apache.org/jira/browse/FELIX-5998
> Project: Felix
> Issue Type: Task
> Components: Resolver
>Affects Versions: resolver-2.0.0
>Reporter: Pierre De Rop
>Priority: Major
>
> I'm using a custom ResolveContext implementation that I've written in order
> to calculate the dependencies of some applications which bundles are all
> centralized in an OBR. Now, using the Felix framework 6.0.1 (and the Resolver
> 2.0.0 that is provided by the framework), I sometimes get an NPE in the
> ResolverImpl.checkPackageSpaceConsistency, line 1319).
> My OBR is not yet fully "curated" (I still have some " Candidate permutation
> failed due to a conflict between imports" logs when enabling
> felix.log.level=4). So I'm cleaning the OBR gradually, but now, sometimes I
> see this NPE while resolving :
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1319)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at
> org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:622)
> at
> org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:575)
> at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:438)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:414)
> at
> com.nokia.as.microfeatures.bundlerepository.impl.BundleRepositoryImpl.findResolution(BundleRepositoryImpl.java:257)
> {code}
> The bad thing is that I'm not able to reproduce the NPE when I enable
> felix.log.level=4, and the NPE is difficult to reproduce.
> Could someone please give me a clue about what could produce this NPE ? Are
> there some traces which could be added in order to figure out what is the
> problem ? Then is there a fix which should be done in order to avoid this
> null pointer ?
> If I fully cleanup my OBR, maybe I won't have anymore the NPE, but I just
> wanted to report it here.
> thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5998) NPE in Resolver checkPackageSpaceConsistency
Pierre De Rop created FELIX-5998:
Summary: NPE in Resolver checkPackageSpaceConsistency
Key: FELIX-5998
URL: https://issues.apache.org/jira/browse/FELIX-5998
Project: Felix
Issue Type: Task
Components: Resolver
Affects Versions: resolver-2.0.0
Reporter: Pierre De Rop
I'm using a custom ResolveContext implementation that I've written in order to
calculate the dependencies of some applications which bundles are all
centralized in an OBR. Now, using the Felix framework 6.0.1 (and the Resolver
2.0.0 that is provided by the framework), I sometimes get an NPE in the
ResolverImpl.checkPackageSpaceConsistency, line 1319).
My OBR is not yet fully "curated" (I still have some " Candidate permutation
failed due to a conflict between imports" logs when enabling
felix.log.level=4). So I'm cleaning the OBR gradually, but now, sometimes I
see this NPE while resolving :
{code:java}
java.lang.NullPointerException
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1319)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
at
org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:622)
at
org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:575)
at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:438)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:414)
at
com.nokia.as.microfeatures.bundlerepository.impl.BundleRepositoryImpl.findResolution(BundleRepositoryImpl.java:257)
{code}
The bad thing is that I'm not able to reproduce the NPE when I enable
felix.log.level=4, and the NPE is difficult to reproduce.
Could someone please give me a clue about what could produce this NPE ? Are
there some traces which could be added in order to figure out what is the
problem ? Then is there a fix which should be done in order to avoid this null
pointer ?
If I fully cleanup my OBR, maybe I won't have anymore the NPE, but I just
wanted to report it here.
thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5996) Remove generic parameter in DM Component interface
[
https://issues.apache.org/jira/browse/FELIX-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5996:
-
Attachment: (was: dependencymanager.FELIX-5996.tgz)
> Remove generic parameter in DM Component interface
> --
>
> Key: FELIX-5996
> URL: https://issues.apache.org/jira/browse/FELIX-5996
> Project: Felix
> Issue Type: Task
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r13
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> Since dm-r13, the Component interface is now taking a generic parameter so it
> make it easier to define extended components like adapters.
> So, with this new model, it looks like the following:
> {code:java}
> public interface Component> {
>T setInterface(String service, Dictionary properties)
>T setImplementation(Object ob);
>...
> }
> public interface AdapterComponent extends Component {
>AdapterComponent setAdaptee(Class service, String filter);
>AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
>...
> }
> {code}
> and you can now do something like this:
> {code:java}
> Component adapter = createAdapterComponent()
> .setAdaptee(Adaptee.class, "(foo=bar)")
> .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
> .setImplementation(AdapterImpl.class)
> .setInterface(AdapterService.class, null)
> .add(createServiceDependency().setService(LogService.class));
> {code}
> now, while using the generic parameter simplify the declaration of component
> adapters, it has a drawback: the Component now takes a generic parameter, and
> old code using simple components now generates a compilation warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> so, the above example generates a compilation warning, and you now have to
> declare "?" in order to get rid of the warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> that being said, maybe we can refactor in order to get rid of the generic
> parameter, by copying the top level component methods in sub interfaces, like
> this:
> {code:java}
> public interface Component {
> Component setInterface(String service, Dictionary properties);
> Component setImplementation(Object ob);
> ...
> }
> public interface AdapterComponent extends Component
> {
> // Component methods with specialized signatures
> AdapterComponent setInterface(String service, Dictionary properties)
> AdapterComponent setImplementation(Object ob);
> // AdapterComponent methods
> AdapterComponent methods AdapterComponent setAdaptee(Class service, String
> filter);
> AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5996) Remove generic parameter in DM Component interface
[
https://issues.apache.org/jira/browse/FELIX-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712100#comment-16712100
]
Pierre De Rop commented on FELIX-5996:
--
I have attached a new version which is not using generic parameters anymore;
the methods from the Component interface have been duplicated in all Component
subinterfaces.
> Remove generic parameter in DM Component interface
> --
>
> Key: FELIX-5996
> URL: https://issues.apache.org/jira/browse/FELIX-5996
> Project: Felix
> Issue Type: Task
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r13
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Attachments: dependencymanager.FELIX-5996.tgz
>
>
> Since dm-r13, the Component interface is now taking a generic parameter so it
> make it easier to define extended components like adapters.
> So, with this new model, it looks like the following:
> {code:java}
> public interface Component> {
>T setInterface(String service, Dictionary properties)
>T setImplementation(Object ob);
>...
> }
> public interface AdapterComponent extends Component {
>AdapterComponent setAdaptee(Class service, String filter);
>AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
>...
> }
> {code}
> and you can now do something like this:
> {code:java}
> Component adapter = createAdapterComponent()
> .setAdaptee(Adaptee.class, "(foo=bar)")
> .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
> .setImplementation(AdapterImpl.class)
> .setInterface(AdapterService.class, null)
> .add(createServiceDependency().setService(LogService.class));
> {code}
> now, while using the generic parameter simplify the declaration of component
> adapters, it has a drawback: the Component now takes a generic parameter, and
> old code using simple components now generates a compilation warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> so, the above example generates a compilation warning, and you now have to
> declare "?" in order to get rid of the warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> that being said, maybe we can refactor in order to get rid of the generic
> parameter, by copying the top level component methods in sub interfaces, like
> this:
> {code:java}
> public interface Component {
> Component setInterface(String service, Dictionary properties);
> Component setImplementation(Object ob);
> ...
> }
> public interface AdapterComponent extends Component
> {
> // Component methods with specialized signatures
> AdapterComponent setInterface(String service, Dictionary properties)
> AdapterComponent setImplementation(Object ob);
> // AdapterComponent methods
> AdapterComponent methods AdapterComponent setAdaptee(Class service, String
> filter);
> AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5996) Remove generic parameter in DM Component interface
[
https://issues.apache.org/jira/browse/FELIX-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5996:
-
Attachment: dependencymanager.FELIX-5996.tgz
> Remove generic parameter in DM Component interface
> --
>
> Key: FELIX-5996
> URL: https://issues.apache.org/jira/browse/FELIX-5996
> Project: Felix
> Issue Type: Task
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r13
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Attachments: dependencymanager.FELIX-5996.tgz
>
>
> Since dm-r13, the Component interface is now taking a generic parameter so it
> make it easier to define extended components like adapters.
> So, with this new model, it looks like the following:
> {code:java}
> public interface Component> {
>T setInterface(String service, Dictionary properties)
>T setImplementation(Object ob);
>...
> }
> public interface AdapterComponent extends Component {
>AdapterComponent setAdaptee(Class service, String filter);
>AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
>...
> }
> {code}
> and you can now do something like this:
> {code:java}
> Component adapter = createAdapterComponent()
> .setAdaptee(Adaptee.class, "(foo=bar)")
> .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
> .setImplementation(AdapterImpl.class)
> .setInterface(AdapterService.class, null)
> .add(createServiceDependency().setService(LogService.class));
> {code}
> now, while using the generic parameter simplify the declaration of component
> adapters, it has a drawback: the Component now takes a generic parameter, and
> old code using simple components now generates a compilation warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> so, the above example generates a compilation warning, and you now have to
> declare "?" in order to get rid of the warning:
> {code:java}
> Component adapter = createComponent()
> .setImplementation(SimpleComponent.class)
> ...
> {code}
> that being said, maybe we can refactor in order to get rid of the generic
> parameter, by copying the top level component methods in sub interfaces, like
> this:
> {code:java}
> public interface Component {
> Component setInterface(String service, Dictionary properties);
> Component setImplementation(Object ob);
> ...
> }
> public interface AdapterComponent extends Component
> {
> // Component methods with specialized signatures
> AdapterComponent setInterface(String service, Dictionary properties)
> AdapterComponent setImplementation(Object ob);
> // AdapterComponent methods
> AdapterComponent methods AdapterComponent setAdaptee(Class service, String
> filter);
> AdapterComponent setAdapteeCallbacks(String add, String change, String
> remove, String swap);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5996) Remove generic parameter in DM Component interface
Pierre De Rop created FELIX-5996:
Summary: Remove generic parameter in DM Component interface
Key: FELIX-5996
URL: https://issues.apache.org/jira/browse/FELIX-5996
Project: Felix
Issue Type: Task
Components: Dependency Manager
Affects Versions: org.apache.felix.dependencymanager-r13
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Since dm-r13, the Component interface is now taking a generic parameter so it
make it easier to define extended components like adapters.
So, with this new model, it looks like the following:
{code:java}
public interface Component> {
T setInterface(String service, Dictionary properties)
T setImplementation(Object ob);
...
}
public interface AdapterComponent extends Component {
AdapterComponent setAdaptee(Class service, String filter);
AdapterComponent setAdapteeCallbacks(String add, String change, String
remove, String swap);
...
}
{code}
and you can now do something like this:
{code:java}
Component adapter = createAdapterComponent()
.setAdaptee(Adaptee.class, "(foo=bar)")
.setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
.setImplementation(AdapterImpl.class)
.setInterface(AdapterService.class, null)
.add(createServiceDependency().setService(LogService.class));
{code}
now, while using the generic parameter simplify the declaration of component
adapters, it has a drawback: the Component now takes a generic parameter, and
old code using simple components now generates a compilation warning:
{code:java}
Component adapter = createComponent()
.setImplementation(SimpleComponent.class)
...
{code}
so, the above example generates a compilation warning, and you now have to
declare "?" in order to get rid of the warning:
{code:java}
Component adapter = createComponent()
.setImplementation(SimpleComponent.class)
...
{code}
that being said, maybe we can refactor in order to get rid of the generic
parameter, by copying the top level component methods in sub interfaces, like
this:
{code:java}
public interface Component {
Component setInterface(String service, Dictionary properties);
Component setImplementation(Object ob);
...
}
public interface AdapterComponent extends Component
{ // Component methods with specialized signatures AdapterComponent
setInterface(String service, Dictionary properties) AdapterComponent
setImplementation(Object ob); … // AdapterComponent methods AdapterComponent
setAdaptee(Class service, String filter); AdapterComponent
setAdapteeCallbacks(String add, String change, String remove, String swap);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5992) Do not use a global changelog for all dm modules
[ https://issues.apache.org/jira/browse/FELIX-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop resolved FELIX-5992. -- Resolution: Fixed fixed in revision 1847683. > Do not use a global changelog for all dm modules > > > Key: FELIX-5992 > URL: https://issues.apache.org/jira/browse/FELIX-5992 > Project: Felix > Issue Type: Task > Components: Dependency Manager, Dependency Manager Annotations, > Dependency Manager Lambda, Dependency Manager Runtime, Dependency Manager > Shell >Affects Versions: org.apache.felix.dependencymanager-r13 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > Fix For: org.apache.felix.dependencymanager-r14 > > > Currently, there is one global changelog that is included in each dependency > manager artifact. > It means that if for a given release, we only modify one bundle, then when we > update the global changelog, the updated changelog is then included in other > unmodified bundles, hence forcing to update the bundle version of the > unmodified bundles. > So, it's better if each module includes its own changelog file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5992) Do not use a global changelog for all dm modules
Pierre De Rop created FELIX-5992: Summary: Do not use a global changelog for all dm modules Key: FELIX-5992 URL: https://issues.apache.org/jira/browse/FELIX-5992 Project: Felix Issue Type: Task Components: Dependency Manager, Dependency Manager Annotations, Dependency Manager Lambda, Dependency Manager Runtime, Dependency Manager Shell Affects Versions: org.apache.felix.dependencymanager-r13 Reporter: Pierre De Rop Assignee: Pierre De Rop Fix For: org.apache.felix.dependencymanager-r14 Currently, there is one global changelog that is included in each dependency manager artifact. It means that if for a given release, we only modify one bundle, then when we update the global changelog, the updated changelog is then included in other unmodified bundles, hence forcing to update the bundle version of the unmodified bundles. So, it's better if each module includes its own changelog file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-5991) DM annotation scanner debug messages are logged in warn
[ https://issues.apache.org/jira/browse/FELIX-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop resolved FELIX-5991. -- Resolution: Fixed Fixed in revision 1847649. > DM annotation scanner debug messages are logged in warn > --- > > Key: FELIX-5991 > URL: https://issues.apache.org/jira/browse/FELIX-5991 > Project: Felix > Issue Type: Wish > Components: Dependency Manager Annotations >Affects Versions: org.apache.felix.dependencymanager-r13 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r14 > > > When some component annotation property types are used, like jaxrs > whiteboard, many warnings are logged in bndtools when the > ComponentPropertyType annotation is not found from the buildpath. The > warnings should be logged in debug level, not in warn. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5990:
-
Fix Version/s: org.apache.felix.dependencymanager-r14
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r14
>
> Attachments: dm.memoryleak.tgz, oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5991) DM annotation scanner debug messages are logged in warn
Pierre De Rop created FELIX-5991: Summary: DM annotation scanner debug messages are logged in warn Key: FELIX-5991 URL: https://issues.apache.org/jira/browse/FELIX-5991 Project: Felix Issue Type: Wish Components: Dependency Manager Annotations Affects Versions: org.apache.felix.dependencymanager-r13 Reporter: Pierre De Rop Assignee: Pierre De Rop Fix For: org.apache.felix.dependencymanager-r14 When some component annotation property types are used, like jaxrs whiteboard, many warnings are logged in bndtools when the ComponentPropertyType annotation is not found from the buildpath. The warnings should be logged in debug level, not in warn. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop resolved FELIX-5990.
--
Resolution: Fixed
Committed a fix in revision 1847643.
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: dm.memoryleak.tgz, oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5990 started by Pierre De Rop.
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: dm.memoryleak.tgz, oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701903#comment-16701903
]
Pierre De Rop commented on FELIX-5990:
--
Added oom.png, which is screenshot of memoryanalyzer.
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5990:
-
Attachment: dm.memoryleak.tgz
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: dm.memoryleak.tgz, oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701903#comment-16701903
]
Pierre De Rop edited comment on FELIX-5990 at 11/28/18 1:49 PM:
Attached oom.png, which is screenshot of memoryanalyzer.
was (Author: pderop):
Added oom.png, which is screenshot of memoryanalyzer.
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: dm.memoryleak.tgz, oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701909#comment-16701909
]
Pierre De Rop commented on FELIX-5990:
--
Attached dm.memoryleak.tgz, which is a simple project that is reproducing the
issue.
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: dm.memoryleak.tgz, oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5990) DM ServiceTracker memory leak
[
https://issues.apache.org/jira/browse/FELIX-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5990:
-
Attachment: oom.png
> DM ServiceTracker memory leak
> -
>
> Key: FELIX-5990
> URL: https://issues.apache.org/jira/browse/FELIX-5990
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: dependencymanager-3.0.0
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: oom.png
>
>
> We have an old memory leak that comes from dependency manager 3.0.0 version,
> where the dm ServiceTracker does not remove the Set used to register highest
> tracked services when an optional ServiceDependency becomes unavailable.
> Here is the old code where the memory leak happens, in
> org.apache.felix.dm.tracker.ServiceTracker.java:
>
> {code:java}
> private void addHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services == null) {
> services = new TreeSet();
> m_highestTrackedCache.put(serviceId, services);
> }
> services.add(reference);
> }
> private void removeHighestTrackedCache(ServiceReference reference) {
> Long serviceId = ServiceUtil.getServiceIdObject(reference);
> TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
> if (services != null) {
> services.remove(reference);
> }
> }
> {code}
> So, the removeHighestTrackedCache does not remove the TreeSet from the
> m_highestTrackedCache when it becomes empty.
> So, the memory leak happens in the following situation: you have a Consumer
> component which has an optional dependency on a Provider, and the Provider
> service disappears and reappears a huge number of time.
> The memory can grow slowly, but may lead to an OOM in case the framework is
> run for a very long time and if the Provider service is
> registered/unregistered a lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5990) DM ServiceTracker memory leak
Pierre De Rop created FELIX-5990:
Summary: DM ServiceTracker memory leak
Key: FELIX-5990
URL: https://issues.apache.org/jira/browse/FELIX-5990
Project: Felix
Issue Type: Bug
Components: Dependency Manager
Affects Versions: dependencymanager-3.0.0
Reporter: Pierre De Rop
Assignee: Pierre De Rop
We have an old memory leak that comes from dependency manager 3.0.0 version,
where the dm ServiceTracker does not remove the Set used to register highest
tracked services when an optional ServiceDependency becomes unavailable.
Here is the old code where the memory leak happens, in
org.apache.felix.dm.tracker.ServiceTracker.java:
{code:java}
private void addHighestTrackedCache(ServiceReference reference) {
Long serviceId = ServiceUtil.getServiceIdObject(reference);
TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
if (services == null) {
services = new TreeSet();
m_highestTrackedCache.put(serviceId, services);
}
services.add(reference);
}
private void removeHighestTrackedCache(ServiceReference reference) {
Long serviceId = ServiceUtil.getServiceIdObject(reference);
TreeSet services = (TreeSet) m_highestTrackedCache.get(serviceId);
if (services != null) {
services.remove(reference);
}
}
{code}
So, the removeHighestTrackedCache does not remove the TreeSet from the
m_highestTrackedCache when it becomes empty.
So, the memory leak happens in the following situation: you have a Consumer
component which has an optional dependency on a Provider, and the Provider
service disappears and reappears a huge number of time.
The memory can grow slowly, but may lead to an OOM in case the framework is run
for a very long time and if the Provider service is registered/unregistered a
lot of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (FELIX-5967) DM does not support java9+
[
https://issues.apache.org/jira/browse/FELIX-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5967.
> DM does not support java9+
> --
>
> Key: FELIX-5967
> URL: https://issues.apache.org/jira/browse/FELIX-5967
> Project: Felix
> Issue Type: Improvement
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Dependency Manager can't be built/used on java9+ (9,10,11), because of the
> following issues:
> 1) for configuration types, when we parse interface "default methods", the
> way we are parsing does not work in java 9+, and a patch must be applied.
> See [1].
> 2) for dm-lambda, the way to parse the lambda parameter names for "fluent"
> service properties (which requires the -parameters javac option) does not
> work in java 9+.
> For example, the following does not work
> {code:java}
> component(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> So, the "property" lambda parameter name can't be parsed in Java9+. This is
> likely because starting from java9, the -parameters option is not generating
> anymore the metadata for the lambda parameter names (see [2]). For the
> moment, the fluent service properties willl work only using java8, but not
> anymore on java9+, and the most reasonable thing is to deprecate the usage of
> fluent service properties, meaning that instead of:
> {code:java}
> component(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> you then must replace by:
> {code:java}
> component(comp -> comp.impl(Foo.class).provides(FooService.class,
> "property","service property value"));{code}
> So, the fluent service properties must be commented as in restriction if
> java9+ is used. No need to bump the dm-lambda bundle version, becaue it still
> works using java8.
> 3) the gradle version needs to be updated, and for java11 support, the
> "--no-daemon" option must be used when building.
> [1]
> [https://dzone.com/articles/correct-reflective-access-to-interface-default-methods]
> [2] https://bugs.openjdk.java.net/browse/JDK-8138729
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (FELIX-5960) Do not supply MD5 checksum
[ https://issues.apache.org/jira/browse/FELIX-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5960. > Do not supply MD5 checksum > -- > > Key: FELIX-5960 > URL: https://issues.apache.org/jira/browse/FELIX-5960 > Project: Felix > Issue Type: Task > Components: Dependency Manager >Affects Versions: dependencymanager-2.0.1 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > Fix For: org.apache.felix.dependencymanager-r13 > > > Due to Apache release policy updates, we should not supply anymore MD5 > checksum when signing release candidates. > For DM, the signStaging task in the release/build.gradle should then be > updated accordingly, and the DM check_staged_release.sh should not check > anymore MD5 checksum. > It seems that the SHA-1 checksum should also not be supplied but I see that > they are still supplied by the other felix sub projects. So, for the moment, > let's only remove MD5 checksum. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (FELIX-5957) Check if a default implementation is used only on optional dependencies
[
https://issues.apache.org/jira/browse/FELIX-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5957.
> Check if a default implementation is used only on optional dependencies
> ---
>
> Key: FELIX-5957
> URL: https://issues.apache.org/jira/browse/FELIX-5957
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> When an optional dependency is defined on a class field, then a NullObject is
> injected in case the dependency is unavailable.
> Now, it is possible to also set a default implementation using the
> ServiceDependency.defaultImpl attribute. This attribute refers to class that
> will be used when the service dependency is unavailable.
> For example:
> {code:java}
> @Component
> class MyComponent {
> @ServiceDependency(required=false, defaultImpl=MyDefaultImpl.class)
> Dependency m_èdependency;
> }
> {code}
> But it is an error to use the defaultImpl attribute when the dependency is
> required or when the dependency is not applied on a class field. So, the DM
> annocation scanner should report an error in such a case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (FELIX-5336) Add support for prototype scope services in DM4
[ https://issues.apache.org/jira/browse/FELIX-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5336. > Add support for prototype scope services in DM4 > --- > > Key: FELIX-5336 > URL: https://issues.apache.org/jira/browse/FELIX-5336 > Project: Felix > Issue Type: New Feature > Components: Dependency Manager, Dependency Manager Annotations, > Dependency Manager Lambda, Dependency Manager Runtime >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Major > Fix For: org.apache.felix.dependencymanager-r13 > > Attachments: FELIX-5336.tgz > > > In the users mailing list, there is a wish to add support in DM4 for OSGi > prototype scope services, which allows any service consumer to get its own > instance of a given service dependency. > See http://www.mail-archive.com/users@felix.apache.org/msg17473.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (FELIX-5941) DM APi enhancements
[
https://issues.apache.org/jira/browse/FELIX-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5941.
> DM APi enhancements
> ---
>
> Key: FELIX-5941
> URL: https://issues.apache.org/jira/browse/FELIX-5941
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> in [https://github.com/pderop/dm.enhanced,] some enhancements have been done
> regarding the dm API, and the intent of this issue is to merge the
> improvements into the felix trunk:
> * the api to define aspects and adapters have been reworked (but dm API
> remains {{backward compatible}})
> * you can now declare multiple property type interfaces when using
> Configuration Dependency or Factory Components (this was needed to implement
> the enhancements for the annotations)
> * configuration dependency using metatypes can now declare property types
> * Allow to specify if propagated configuration dependencies must override
> service service properties (it was not possible to override service
> properties with propagated service properties so far)
> * Added the following signatures in Component interface:
> ** setInterface(Class serviceName, Dictionary properties)
> ** setInterface(Class[] serviceNames, Dictionary properties)
> h3. *Aspect/Adapters Api enhancements*
> So far, aspects or adapters were defined using many methods from
> DependencyManager or DependencyActivatorBase classes:
> For example, in DependencyManager.java, we currently have many signatures
> {code:java}
> public class DependencyManager {
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String autoConfig) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String add, String change, String remove) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String add, String change, String remove, String swap) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String autoConfig, Object callbackInstance, String add, String
> change, String remove, String swap, boolean propagate) {...}
>
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate) {...}
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate, Object callbackInstance) {...}
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate, Class configType) {...}
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate, Object callbackInstance,
> Class configType) {...}
> public Component createAdapterFactoryConfigurationService(String
> factoryPid, String update, boolean propagate,String heading, String desc,
> String localization, PropertyMetaData[] propertiesMetaData) {...}
>
> public Component createBundleAdapterService(int bundleStateMask, String
> bundleFilter, boolean propagate) {...}
> public Component createBundleAdapterService(int bundleStateMask, String
> bundleFilter, boolean propagate, Object callbackInstance, String add, String
> change, String remove) {...}
>
> public Component createResourceAdapterService(String resourceFilter,
> boolean propagate, Object callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter,
> boolean propagate, Object callbackInstance, String callbackSet, String
> callbackChanged)
> public Component createResourceAdapterService(String resourceFilter,
> Object propagateCallbackInstance, String propagateCallbackMethod, Object
> callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter,
> Object propagateCallbackInstance, String propagateCallbackMethod, Object
> callbackInstance, String callbackSet, String callbackChanged) {...}
>
> public Component createAspectService(Class serviceInterface, String
> serviceFilter, int ranking, String autoConfig) {...}
> public Component createAspectService(Class serviceInterface, String
> serviceFilter, int ranking) {...}
> public Component createAspectService(Class serviceInterface, String
> serviceFilter, int ranking, String add, String change, String remove) {...}
> public Component createAspectService(Class serviceInterface, String
> serviceFilter, int ranking,
[jira] [Closed] (FELIX-5956) NPE when invoking a lifecycle runnable method from init method
[
https://issues.apache.org/jira/browse/FELIX-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5956.
> NPE when invoking a lifecycle runnable method from init method
> --
>
> Key: FELIX-5956
> URL: https://issues.apache.org/jira/browse/FELIX-5956
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager Runtime
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> When you use a DM lifecycle controller in order to trigger component
> activation from the @Init method, a NPE is throw if you invoke the lifecylce
> runnable from the init method.
> For example, the following code:
> {code:java}
> @Component
> public class MyServiceImpl implements MyService {
> @LifecycleController
> volatile Runnable _start;
> @Init
> void init() {
> _start.run(); // immediately trigger service activation
> }
> }
> {code}
> produces the following NPE:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.dm.runtime.ToggleServiceDependency.activate(ToggleServiceDependency.java:49)
> at
> org.apache.felix.dm.runtime.ServiceLifecycleHandler$ComponentStarter.run(ServiceLifecycleHandler.java:431)
> at
> org.apache.felix.dependencymanager.samples.hello.annot.ServiceProviderImpl.init(ServiceProviderImpl.java:47)
> ... 65 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (FELIX-5939) DM annotations enhancements
[
https://issues.apache.org/jira/browse/FELIX-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5939.
> DM annotations enhancements
> ---
>
> Key: FELIX-5939
> URL: https://issues.apache.org/jira/browse/FELIX-5939
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations, Dependency Manager
> Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Some DM annotations improvements have been done regarding DM Annotation in
> this github project: [https://github.com/pderop/dm.enhanced,] and the intent
> is to merge the improvements to the felix trunk.
> Essentially, the following DM annotations enhancements and modifications have
> been done:
> * in OSGi R7, declarative service now provides a @ComponentPropertyType
> annotation that can be used to defined user defined property type
> annotations. Now this annotation is used by other R7 libraries, like jaxrs
> whiteboard R7 API. So the DM annotation scanner has been enhanced for the
> support of the DS @ComponentPropertyType, allowing you to reuse user defined
> annotations from other r7 libraries (whiteboad, etc ...). The dm annotation
> plugin has been enhanced by reusing some part of the ds annotation scanner
> from bndlib, which is full of reusable useful code which has been applied to
> dm (scanning of property types, PREFIX_, etc ...). For consistency api
> reasons, a new @PropertyType annotation has also been added to the DM
> annotation API: this annotation has the same semantics has the DS
> @ComponentPropertyType annotations.
> * allow ServiceDependency to auto detect the service type when the
> annotation is applied on a collection class field
> * removed FactoryComponentAdapterService (some attributes have been added in
> the Component annotation in order to declare factory pid components with the
> @Component annotation)
> * removed some old annotations / attributes. The attributes and annotations
> related to metatype have been removed since you can now use the standard
> metatype annotations. if users need to use old version, then the previous old
> 4.2.1 annotations can be used, because the dm runtime is compatible with old
> and new annotations version.
> * removed "dereference" attribute in ServiceDependencyAnnotation, because we
> can now infer if the service dependency callbacks accepts a ServiceReference
> or a ServiceObjects parameter
> Since some incompatible changes have been made, the major version of the
> annotation bundle has been bumped to 5.0.0.
> *User defined property types examples:*
> So far, you could define component service properties using DM @Property
> annotation, and component configuration could be declared as user defined
> interfaces. You can now declare user-defined annotations which can be used to
> specify both service properties and component configuration. It means that
> instead of declaring service properties using @Property annotation, you can
> now use your own annotations (which must be annotated with the new
> @PropertyType annotation, or using the standard @ComponentPropertyType
> annotation.
> For example, let’s assume your write an OSGi r7 jaxrs servlet context which
> needs the two following service properties:
> {code:java}
> osgi.http.whiteboard.context.name
> osgi.http.whiteboard.context.path
> {code}
> Then you can first define your own annotation (but you could also reuse the
> default annotations provided by the new jaxrs whiteboard r7 api, from the
> org.osgi.service.jaxrs.whiteboard.propertytypes package):
>
> {code:java}
> import org.apache.felix.dependencymanager.annotation.PropertyType;
> @PropertyType
> @interface ServletContext {
> String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
> String osgi_http_whiteboard_context_path();
> }
> {code}
> In the above, the underscore is mapped to ".", and you can apply the above
> annotation on top of your component like this:
> {code:java}
> @Component
> @ServletContext(osgi_http_whiteboard_context_path="/game")
> public class AppServletContext extends ServletContextHelper {
> }
> {code}
> You can also use configuration admin service in order to override the default
> service properties:
> {code:java}
> @Component
> @ServletContext(osgi_http_whiteboard_context_path="/game")
> public class AppServletContext extends ServletContextHelper {
> @ConfigurationDependency(propagate=true, pid="my.pid")
> void updated(ServletContext cnf) {
> // if some properties are not present in the configuration, then the
> ones used in the
> // annotation will be used.
> // The configuration admin properties, if defined, will
[jira] [Closed] (FELIX-5937) Refactor DM bndtools/gradle project
[ https://issues.apache.org/jira/browse/FELIX-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5937. > Refactor DM bndtools/gradle project > --- > > Key: FELIX-5937 > URL: https://issues.apache.org/jira/browse/FELIX-5937 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager, Dependency Manager Shell >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r13 > > > The DM gradle project structure has been enhanced (see [1]) and I'd like to > merge the enhancements in the felix trunk. > Mainly: > * all build time binary dependencies are now downloaded from maven central > using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository". > * The gradle wrapper is not commited anymore and is downloaded by the > "gradlew" scripts. > * Fixed some issues in the release/build.gradle script, which now allows to > interactively specify the PGP key when calling the "gradlew signStaging" task > The consequence of this is that we don't need anymore to deliver a > "-deps.zip" bundle which was containing so far build-time binary dependencies. > [1]https://github.com/pderop/dm.enhanced -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (FELIX-5955) Move changelog.txt to toplevel project dir
[ https://issues.apache.org/jira/browse/FELIX-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5955. > Move changelog.txt to toplevel project dir > -- > > Key: FELIX-5955 > URL: https://issues.apache.org/jira/browse/FELIX-5955 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: org.apache.felix.dependencymanager-r1 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > Fix For: org.apache.felix.dependencymanager-r13 > > > Currently, chanlogs are stored in each dependency manager sub projects. > But the download felix link requires the changelog to be located at the > toplevel source project directory. Moreover, it's easier to maintain one > single changelog.txt file instead of having one for each DM sub projects. > let's have a single changelog.txt file stored in the DM toplevel source > directory (dependencymanager/changelog;txt). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (FELIX-5768) DM Lambda stop callback not being called
[
https://issues.apache.org/jira/browse/FELIX-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5768.
> DM Lambda stop callback not being called
>
>
> Key: FELIX-5768
> URL: https://issues.apache.org/jira/browse/FELIX-5768
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager Lambda
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Blocker
> Fix For: org.apache.felix.dependencymanager-r13
>
> Attachments: org.apache.felix.dependencymanager.lambda-1.1.2.jar
>
>
> It has been reported from the felix users mailing list an issue where a
> component defined with dm-lambda API is never called in its "stop" callback
> when the bundle is stopped.
> indeed, the dm-lambda DependencyManagerActivator.stop method has a bug and
> does not clear the dependency manager when the bundle is stopped: the current
> code of the DependencyManagerActivator.stop method is this:
> {code}
> public void stop(BundleContext context) throws Exception {
> destroy();
> }
> {code}
> and of course, the manager must be cleared, like it is the case with the
> original DependencyActivatorBase.stop method:
> {code}
> public void stop(BundleContext context) throws Exception {
> destroy();
> m_manager.clear();
> }
> {code}
> it is too bad that no tests were testing this so basic behavior, so I will
> first add it soon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (FELIX-5716) Dead Lock in DM
[
https://issues.apache.org/jira/browse/FELIX-5716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5716.
> Dead Lock in DM
> ---
>
> Key: FELIX-5716
> URL: https://issues.apache.org/jira/browse/FELIX-5716
> Project: Felix
> Issue Type: Bug
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Critical
> Fix For: org.apache.felix.dependencymanager-r13
>
> Attachments: deadlock.proposed.patch.txt
>
>
> I just found an unfortunate deadlock when using latest DM r11 and latest SCR
> 2.0.12 in the same JVM.
> I believe that the same issue applies to both DM and SCR (I may have to open
> a seperate issue for SCR).
> First, here is the deadlock:
> {code}
> Found one Java-level deadlock:
> =
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)":
> waiting to lock monitor 0x7f8188004538 (object 0xeb38d420, a
> org.apache.felix.dm.tracker.ServiceTracker$Tracked),
> which is held by "FelixDispatchQueue"
> "FelixDispatchQueue":
> waiting for ownable synchronizer 0xc0699f30, (a
> java.util.concurrent.locks.ReentrantLock$FairSync),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)"
> Java stack information for the threads listed above:
> ===
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)":
> at
> org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChangedHideAspects(ServiceTracker.java:1140)
> - waiting to lock <0xeb38d420> (a
> org.apache.felix.dm.tracker.ServiceTracker$Tracked)
> at
> org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1054)
> at
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4579)
> at org.apache.felix.framework.Felix.access$000(Felix.java:105)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:419)
> at
> org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:588)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:131)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.updateServiceRegistration(SingleComponentManager.java:558)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:755)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:645)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:609)
> at
> org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:426)
> at
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:284)
> at
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport$1.configurationEvent(RegionConfigurationSupport.java:89)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2090)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2058)
> at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
> at java.lang.Thread.run(Thread.java:748)
> "FelixDispatchQueue":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc0699f30> (a
> java.util.concurrent.locks.ReentrantLock$FairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:442)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.obtainLock(AbstractComponentManager.java:228)
> at
>
[jira] [Closed] (FELIX-5683) getServiceProperties returns null instead of empty dictionary
[
https://issues.apache.org/jira/browse/FELIX-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5683.
> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component =
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
> Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method
> returns null instead of the empty dictionary that has been set in the
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE).
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary
> returned by the getServiceProperties() method was so far (since the initial
> version of felix dm 2.0.1) a copy of the service properties dictionary
> maintained in the ComponentImpl, so if you would like to do set service
> properties like this:
> {code}
> Component component =
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
> Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component); // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary
> returned by the getServiceProperties() method, and the "a=b" service
> properties won't be set when the component is added in the
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new
> behavior implemented, please open a new jira issue and I will manage to
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5967) DM does not support java9+
[
https://issues.apache.org/jira/browse/FELIX-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5967:
-
Description:
Dependency Manager can't be built/used on java9+ (9,10,11), because of the
following issues:
1) for configuration types, when we parse interface "default methods", the way
we are parsing does not work in java 9+, and a patch must be applied.
See [1].
2) for dm-lambda, the way to parse the lambda parameter names for "fluent"
service properties (which requires the -parameters javac option) does not work
in java 9+.
For example, the following does not work
{code:java}
component(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
"service property value"));{code}
So, the "property" lambda parameter name can't be parsed in Java9+. This is
likely because starting from java9, the -parameters option is not generating
anymore the metadata for the lambda parameter names (see [2]). For the moment,
the fluent service properties willl work only using java8, but not anymore on
java9+, and the most reasonable thing is to deprecate the usage of fluent
service properties, meaning that instead of:
{code:java}
component(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
"service property value"));{code}
you then must replace by:
{code:java}
component(comp -> comp.impl(Foo.class).provides(FooService.class,
"property","service property value"));{code}
So, the fluent service properties must be commented as in restriction if java9+
is used. No need to bump the dm-lambda bundle version, becaue it still works
using java8.
3) the gradle version needs to be updated, and for java11 support, the
"--no-daemon" option must be used when building.
[1]
[https://dzone.com/articles/correct-reflective-access-to-interface-default-methods]
[2] https://bugs.openjdk.java.net/browse/JDK-8138729
was:
Dependency Manager can't be built/used on java9+ (9,10,11), because of the
following issues:
1) for configuration types, when we parse interface "default methods", the way
we are parsing does not work in java 9+, and a patch must be applied.
See [1].
2) for dm-lambda, the way to parse the lambda parameter names for "fluent"
service properties (which requires the -parameters javac option) does not work
in java 9+.
For example, the following does not work
{code:java}
compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
"service property value"));{code}
So, the "property" lambda parameter name can't be parsed in Java9+. This is
likely because starting from java9, the -parameters option is not generating
anymore the metadata for the lambda parameter names (see [2]). For the moment,
the fluent service properties willl work only using java8, but not anymore on
java9+, and the most reasonable thing is to deprecate the usage of fluent
service properties, meaning that instead of:
{code:java}
compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
"service property value"));{code}
you then must replace by:
{code:java}
compnent(comp -> comp.impl(Foo.class).provides(FooService.class,
"property","service property value"));{code}
So, the fluent service properties must be commented as in restriction if java9+
is used. No need to bump the dm-lambda bundle version, becaue it still works
using java8.
3) the gradle version needs to be updated, and for java11 support, the
"--no-daemon" option must be used when building.
[1]
[https://dzone.com/articles/correct-reflective-access-to-interface-default-methods]
[2]https://bugs.openjdk.java.net/browse/JDK-8138729
> DM does not support java9+
> --
>
> Key: FELIX-5967
> URL: https://issues.apache.org/jira/browse/FELIX-5967
> Project: Felix
> Issue Type: Improvement
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Dependency Manager can't be built/used on java9+ (9,10,11), because of the
> following issues:
> 1) for configuration types, when we parse interface "default methods", the
> way we are parsing does not work in java 9+, and a patch must be applied.
> See [1].
> 2) for dm-lambda, the way to parse the lambda parameter names for "fluent"
> service properties (which requires the -parameters javac option) does not
> work in java 9+.
> For example, the following does not work
> {code:java}
> component(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> So, the "property" lambda parameter name can't be parsed in Java9+. This is
> likely because starting from java9, the -parameters option is not generating
> anymore the metadata for the lambda parameter names (see [2]).
[jira] [Updated] (FELIX-5967) DM does not support java9+
[
https://issues.apache.org/jira/browse/FELIX-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5967:
-
Fix Version/s: org.apache.felix.dependencymanager-r13
> DM does not support java9+
> --
>
> Key: FELIX-5967
> URL: https://issues.apache.org/jira/browse/FELIX-5967
> Project: Felix
> Issue Type: Improvement
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Dependency Manager can't be built/used on java9+ (9,10,11), because of the
> following issues:
> 1) for configuration types, when we parse interface "default methods", the
> way we are parsing does not work in java 9+, and a patch must be applied.
> See [1].
> 2) for dm-lambda, the way to parse the lambda parameter names for "fluent"
> service properties (which requires the -parameters javac option) does not
> work in java 9+.
> For example, the following does not work
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> So, the "property" lambda parameter name can't be parsed in Java9+. This is
> likely because starting from java9, the -parameters option is not generating
> anymore the metadata for the lambda parameter names (see [2]). For the
> moment, the fluent service properties willl work only using java8, but not
> anymore on java9+, and the most reasonable thing is to deprecate the usage of
> fluent service properties, meaning that instead of:
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> you then must replace by:
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class,
> "property","service property value"));{code}
> So, the fluent service properties must be commented as in restriction if
> java9+ is used. No need to bump the dm-lambda bundle version, becaue it still
> works using java8.
> 3) the gradle version needs to be updated, and for java11 support, the
> "--no-daemon" option must be used when building.
> [1]
> [https://dzone.com/articles/correct-reflective-access-to-interface-default-methods]
> [2]https://bugs.openjdk.java.net/browse/JDK-8138729
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5957) Check if a default implementation is used only on optional dependencies
[
https://issues.apache.org/jira/browse/FELIX-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5957:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r12)
org.apache.felix.dependencymanager-r13
> Check if a default implementation is used only on optional dependencies
> ---
>
> Key: FELIX-5957
> URL: https://issues.apache.org/jira/browse/FELIX-5957
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> When an optional dependency is defined on a class field, then a NullObject is
> injected in case the dependency is unavailable.
> Now, it is possible to also set a default implementation using the
> ServiceDependency.defaultImpl attribute. This attribute refers to class that
> will be used when the service dependency is unavailable.
> For example:
> {code:java}
> @Component
> class MyComponent {
> @ServiceDependency(required=false, defaultImpl=MyDefaultImpl.class)
> Dependency m_èdependency;
> }
> {code}
> But it is an error to use the defaultImpl attribute when the dependency is
> required or when the dependency is not applied on a class field. So, the DM
> annocation scanner should report an error in such a case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5939) DM annotations enhancements
[
https://issues.apache.org/jira/browse/FELIX-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5939:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r12)
org.apache.felix.dependencymanager-r13
> DM annotations enhancements
> ---
>
> Key: FELIX-5939
> URL: https://issues.apache.org/jira/browse/FELIX-5939
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager Annotations, Dependency Manager
> Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> Some DM annotations improvements have been done regarding DM Annotation in
> this github project: [https://github.com/pderop/dm.enhanced,] and the intent
> is to merge the improvements to the felix trunk.
> Essentially, the following DM annotations enhancements and modifications have
> been done:
> * in OSGi R7, declarative service now provides a @ComponentPropertyType
> annotation that can be used to defined user defined property type
> annotations. Now this annotation is used by other R7 libraries, like jaxrs
> whiteboard R7 API. So the DM annotation scanner has been enhanced for the
> support of the DS @ComponentPropertyType, allowing you to reuse user defined
> annotations from other r7 libraries (whiteboad, etc ...). The dm annotation
> plugin has been enhanced by reusing some part of the ds annotation scanner
> from bndlib, which is full of reusable useful code which has been applied to
> dm (scanning of property types, PREFIX_, etc ...). For consistency api
> reasons, a new @PropertyType annotation has also been added to the DM
> annotation API: this annotation has the same semantics has the DS
> @ComponentPropertyType annotations.
> * allow ServiceDependency to auto detect the service type when the
> annotation is applied on a collection class field
> * removed FactoryComponentAdapterService (some attributes have been added in
> the Component annotation in order to declare factory pid components with the
> @Component annotation)
> * removed some old annotations / attributes. The attributes and annotations
> related to metatype have been removed since you can now use the standard
> metatype annotations. if users need to use old version, then the previous old
> 4.2.1 annotations can be used, because the dm runtime is compatible with old
> and new annotations version.
> * removed "dereference" attribute in ServiceDependencyAnnotation, because we
> can now infer if the service dependency callbacks accepts a ServiceReference
> or a ServiceObjects parameter
> Since some incompatible changes have been made, the major version of the
> annotation bundle has been bumped to 5.0.0.
> *User defined property types examples:*
> So far, you could define component service properties using DM @Property
> annotation, and component configuration could be declared as user defined
> interfaces. You can now declare user-defined annotations which can be used to
> specify both service properties and component configuration. It means that
> instead of declaring service properties using @Property annotation, you can
> now use your own annotations (which must be annotated with the new
> @PropertyType annotation, or using the standard @ComponentPropertyType
> annotation.
> For example, let’s assume your write an OSGi r7 jaxrs servlet context which
> needs the two following service properties:
> {code:java}
> osgi.http.whiteboard.context.name
> osgi.http.whiteboard.context.path
> {code}
> Then you can first define your own annotation (but you could also reuse the
> default annotations provided by the new jaxrs whiteboard r7 api, from the
> org.osgi.service.jaxrs.whiteboard.propertytypes package):
>
> {code:java}
> import org.apache.felix.dependencymanager.annotation.PropertyType;
> @PropertyType
> @interface ServletContext {
> String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
> String osgi_http_whiteboard_context_path();
> }
> {code}
> In the above, the underscore is mapped to ".", and you can apply the above
> annotation on top of your component like this:
> {code:java}
> @Component
> @ServletContext(osgi_http_whiteboard_context_path="/game")
> public class AppServletContext extends ServletContextHelper {
> }
> {code}
> You can also use configuration admin service in order to override the default
> service properties:
> {code:java}
> @Component
> @ServletContext(osgi_http_whiteboard_context_path="/game")
> public class AppServletContext extends ServletContextHelper {
> @ConfigurationDependency(propagate=true, pid="my.pid")
> void updated(ServletContext cnf) {
> // if some properties are not present in the configuration, then the
>
[jira] [Updated] (FELIX-5960) Do not supply MD5 checksum
[ https://issues.apache.org/jira/browse/FELIX-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5960: - Fix Version/s: (was: org.apache.felix.dependencymanager-r12) org.apache.felix.dependencymanager-r13 > Do not supply MD5 checksum > -- > > Key: FELIX-5960 > URL: https://issues.apache.org/jira/browse/FELIX-5960 > Project: Felix > Issue Type: Task > Components: Dependency Manager >Affects Versions: dependencymanager-2.0.1 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > Fix For: org.apache.felix.dependencymanager-r13 > > > Due to Apache release policy updates, we should not supply anymore MD5 > checksum when signing release candidates. > For DM, the signStaging task in the release/build.gradle should then be > updated accordingly, and the DM check_staged_release.sh should not check > anymore MD5 checksum. > It seems that the SHA-1 checksum should also not be supplied but I see that > they are still supplied by the other felix sub projects. So, for the moment, > let's only remove MD5 checksum. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5956) NPE when invoking a lifecycle runnable method from init method
[
https://issues.apache.org/jira/browse/FELIX-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5956:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r12)
org.apache.felix.dependencymanager-r13
> NPE when invoking a lifecycle runnable method from init method
> --
>
> Key: FELIX-5956
> URL: https://issues.apache.org/jira/browse/FELIX-5956
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager Runtime
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> When you use a DM lifecycle controller in order to trigger component
> activation from the @Init method, a NPE is throw if you invoke the lifecylce
> runnable from the init method.
> For example, the following code:
> {code:java}
> @Component
> public class MyServiceImpl implements MyService {
> @LifecycleController
> volatile Runnable _start;
> @Init
> void init() {
> _start.run(); // immediately trigger service activation
> }
> }
> {code}
> produces the following NPE:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.dm.runtime.ToggleServiceDependency.activate(ToggleServiceDependency.java:49)
> at
> org.apache.felix.dm.runtime.ServiceLifecycleHandler$ComponentStarter.run(ServiceLifecycleHandler.java:431)
> at
> org.apache.felix.dependencymanager.samples.hello.annot.ServiceProviderImpl.init(ServiceProviderImpl.java:47)
> ... 65 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5937) Refactor DM bndtools/gradle project
[ https://issues.apache.org/jira/browse/FELIX-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5937: - Fix Version/s: (was: org.apache.felix.dependencymanager-r12) org.apache.felix.dependencymanager-r13 > Refactor DM bndtools/gradle project > --- > > Key: FELIX-5937 > URL: https://issues.apache.org/jira/browse/FELIX-5937 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager, Dependency Manager Shell >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r13 > > > The DM gradle project structure has been enhanced (see [1]) and I'd like to > merge the enhancements in the felix trunk. > Mainly: > * all build time binary dependencies are now downloaded from maven central > using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository". > * The gradle wrapper is not commited anymore and is downloaded by the > "gradlew" scripts. > * Fixed some issues in the release/build.gradle script, which now allows to > interactively specify the PGP key when calling the "gradlew signStaging" task > The consequence of this is that we don't need anymore to deliver a > "-deps.zip" bundle which was containing so far build-time binary dependencies. > [1]https://github.com/pderop/dm.enhanced -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5336) Add support for prototype scope services in DM4
[ https://issues.apache.org/jira/browse/FELIX-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5336: - Fix Version/s: (was: org.apache.felix.dependencymanager-r12) org.apache.felix.dependencymanager-r13 > Add support for prototype scope services in DM4 > --- > > Key: FELIX-5336 > URL: https://issues.apache.org/jira/browse/FELIX-5336 > Project: Felix > Issue Type: New Feature > Components: Dependency Manager, Dependency Manager Annotations, > Dependency Manager Lambda, Dependency Manager Runtime >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Major > Fix For: org.apache.felix.dependencymanager-r13 > > Attachments: FELIX-5336.tgz > > > In the users mailing list, there is a wish to add support in DM4 for OSGi > prototype scope services, which allows any service consumer to get its own > instance of a given service dependency. > See http://www.mail-archive.com/users@felix.apache.org/msg17473.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5941) DM APi enhancements
[
https://issues.apache.org/jira/browse/FELIX-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5941:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r12)
org.apache.felix.dependencymanager-r13
> DM APi enhancements
> ---
>
> Key: FELIX-5941
> URL: https://issues.apache.org/jira/browse/FELIX-5941
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> in [https://github.com/pderop/dm.enhanced,] some enhancements have been done
> regarding the dm API, and the intent of this issue is to merge the
> improvements into the felix trunk:
> * the api to define aspects and adapters have been reworked (but dm API
> remains {{backward compatible}})
> * you can now declare multiple property type interfaces when using
> Configuration Dependency or Factory Components (this was needed to implement
> the enhancements for the annotations)
> * configuration dependency using metatypes can now declare property types
> * Allow to specify if propagated configuration dependencies must override
> service service properties (it was not possible to override service
> properties with propagated service properties so far)
> * Added the following signatures in Component interface:
> ** setInterface(Class serviceName, Dictionary properties)
> ** setInterface(Class[] serviceNames, Dictionary properties)
> h3. *Aspect/Adapters Api enhancements*
> So far, aspects or adapters were defined using many methods from
> DependencyManager or DependencyActivatorBase classes:
> For example, in DependencyManager.java, we currently have many signatures
> {code:java}
> public class DependencyManager {
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String autoConfig) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String add, String change, String remove) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String add, String change, String remove, String swap) {...}
> public Component createAdapterService(Class serviceInterface, String
> serviceFilter, String autoConfig, Object callbackInstance, String add, String
> change, String remove, String swap, boolean propagate) {...}
>
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate) {...}
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate, Object callbackInstance) {...}
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate, Class configType) {...}
> public Component createFactoryConfigurationAdapterService(String
> factoryPid, String update, boolean propagate, Object callbackInstance,
> Class configType) {...}
> public Component createAdapterFactoryConfigurationService(String
> factoryPid, String update, boolean propagate,String heading, String desc,
> String localization, PropertyMetaData[] propertiesMetaData) {...}
>
> public Component createBundleAdapterService(int bundleStateMask, String
> bundleFilter, boolean propagate) {...}
> public Component createBundleAdapterService(int bundleStateMask, String
> bundleFilter, boolean propagate, Object callbackInstance, String add, String
> change, String remove) {...}
>
> public Component createResourceAdapterService(String resourceFilter,
> boolean propagate, Object callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter,
> boolean propagate, Object callbackInstance, String callbackSet, String
> callbackChanged)
> public Component createResourceAdapterService(String resourceFilter,
> Object propagateCallbackInstance, String propagateCallbackMethod, Object
> callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter,
> Object propagateCallbackInstance, String propagateCallbackMethod, Object
> callbackInstance, String callbackSet, String callbackChanged) {...}
>
> public Component createAspectService(Class serviceInterface, String
> serviceFilter, int ranking, String autoConfig) {...}
> public Component createAspectService(Class serviceInterface, String
> serviceFilter, int ranking) {...}
> public Component createAspectService(Class serviceInterface, String
> serviceFilter, int ranking, String add, String change,
[jira] [Updated] (FELIX-5955) Move changelog.txt to toplevel project dir
[ https://issues.apache.org/jira/browse/FELIX-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5955: - Fix Version/s: (was: org.apache.felix.dependencymanager-r12) org.apache.felix.dependencymanager-r13 > Move changelog.txt to toplevel project dir > -- > > Key: FELIX-5955 > URL: https://issues.apache.org/jira/browse/FELIX-5955 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: org.apache.felix.dependencymanager-r1 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > Fix For: org.apache.felix.dependencymanager-r13 > > > Currently, chanlogs are stored in each dependency manager sub projects. > But the download felix link requires the changelog to be located at the > toplevel source project directory. Moreover, it's easier to maintain one > single changelog.txt file instead of having one for each DM sub projects. > let's have a single changelog.txt file stored in the DM toplevel source > directory (dependencymanager/changelog;txt). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5768) DM Lambda stop callback not being called
[
https://issues.apache.org/jira/browse/FELIX-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5768:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r12)
org.apache.felix.dependencymanager-r13
> DM Lambda stop callback not being called
>
>
> Key: FELIX-5768
> URL: https://issues.apache.org/jira/browse/FELIX-5768
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager Lambda
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Blocker
> Fix For: org.apache.felix.dependencymanager-r13
>
> Attachments: org.apache.felix.dependencymanager.lambda-1.1.2.jar
>
>
> It has been reported from the felix users mailing list an issue where a
> component defined with dm-lambda API is never called in its "stop" callback
> when the bundle is stopped.
> indeed, the dm-lambda DependencyManagerActivator.stop method has a bug and
> does not clear the dependency manager when the bundle is stopped: the current
> code of the DependencyManagerActivator.stop method is this:
> {code}
> public void stop(BundleContext context) throws Exception {
> destroy();
> }
> {code}
> and of course, the manager must be cleared, like it is the case with the
> original DependencyActivatorBase.stop method:
> {code}
> public void stop(BundleContext context) throws Exception {
> destroy();
> m_manager.clear();
> }
> {code}
> it is too bad that no tests were testing this so basic behavior, so I will
> first add it soon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5683) getServiceProperties returns null instead of empty dictionary
[
https://issues.apache.org/jira/browse/FELIX-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5683:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r12)
org.apache.felix.dependencymanager-r13
> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r13
>
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component =
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
> Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method
> returns null instead of the empty dictionary that has been set in the
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE).
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary
> returned by the getServiceProperties() method was so far (since the initial
> version of felix dm 2.0.1) a copy of the service properties dictionary
> maintained in the ComponentImpl, so if you would like to do set service
> properties like this:
> {code}
> Component component =
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
> Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component); // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary
> returned by the getServiceProperties() method, and the "a=b" service
> properties won't be set when the component is added in the
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new
> behavior implemented, please open a new jira issue and I will manage to
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5716) Dead Lock in DM
[
https://issues.apache.org/jira/browse/FELIX-5716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5716:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r12)
org.apache.felix.dependencymanager-r13
> Dead Lock in DM
> ---
>
> Key: FELIX-5716
> URL: https://issues.apache.org/jira/browse/FELIX-5716
> Project: Felix
> Issue Type: Bug
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Critical
> Fix For: org.apache.felix.dependencymanager-r13
>
> Attachments: deadlock.proposed.patch.txt
>
>
> I just found an unfortunate deadlock when using latest DM r11 and latest SCR
> 2.0.12 in the same JVM.
> I believe that the same issue applies to both DM and SCR (I may have to open
> a seperate issue for SCR).
> First, here is the deadlock:
> {code}
> Found one Java-level deadlock:
> =
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)":
> waiting to lock monitor 0x7f8188004538 (object 0xeb38d420, a
> org.apache.felix.dm.tracker.ServiceTracker$Tracked),
> which is held by "FelixDispatchQueue"
> "FelixDispatchQueue":
> waiting for ownable synchronizer 0xc0699f30, (a
> java.util.concurrent.locks.ReentrantLock$FairSync),
> which is held by "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)"
> Java stack information for the threads listed above:
> ===
> "CM Event Dispatcher (Fire ConfigurationEvent:
> pid=com.alcatel.as.http.ioh.impl.HttpIOH)":
> at
> org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChangedHideAspects(ServiceTracker.java:1140)
> - waiting to lock <0xeb38d420> (a
> org.apache.felix.dm.tracker.ServiceTracker$Tracked)
> at
> org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1054)
> at
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4579)
> at org.apache.felix.framework.Felix.access$000(Felix.java:105)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:419)
> at
> org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:588)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:131)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.updateServiceRegistration(SingleComponentManager.java:558)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:755)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:645)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:609)
> at
> org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:426)
> at
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:284)
> at
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport$1.configurationEvent(RegionConfigurationSupport.java:89)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2090)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2058)
> at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)
> at java.lang.Thread.run(Thread.java:748)
> "FelixDispatchQueue":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xc0699f30> (a
> java.util.concurrent.locks.ReentrantLock$FairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:442)
> at
>
[jira] [Comment Edited] (FELIX-5967) DM does not support java9+
[
https://issues.apache.org/jira/browse/FELIX-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653597#comment-16653597
]
Pierre De Rop edited comment on FELIX-5967 at 10/17/18 2:16 PM:
Fixed in revision revision 1844108.
The fluent service properties have been deprecated , and currently only work
using java8, and will be removed in next version.
So, you can now build dm with java9+ (9,10,11).
For java11, take care to use the --no-daemon option when launching gradlew
command:
{code:java}
./gradlew --no-daemon org.apache.felix.dependencymanager.annotation:jar
./gradlew --no-daemon jar
./gradlew --no-daemon check
{code}
was (Author: pderop):
Fixed in revision revision 1844108.
The fluent service properties have been deprecated , and currently only work
using java8, and will be removed in next version.
> DM does not support java9+
> --
>
> Key: FELIX-5967
> URL: https://issues.apache.org/jira/browse/FELIX-5967
> Project: Felix
> Issue Type: Improvement
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> Dependency Manager can't be built/used on java9+ (9,10,11), because of the
> following issues:
> 1) for configuration types, when we parse interface "default methods", the
> way we are parsing does not work in java 9+, and a patch must be applied.
> See [1].
> 2) for dm-lambda, the way to parse the lambda parameter names for "fluent"
> service properties (which requires the -parameters javac option) does not
> work in java 9+.
> For example, the following does not work
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> So, the "property" lambda parameter name can't be parsed in Java9+. This is
> likely because starting from java9, the -parameters option is not generating
> anymore the metadata for the lambda parameter names (see [2]). For the
> moment, the fluent service properties willl work only using java8, but not
> anymore on java9+, and the most reasonable thing is to deprecate the usage of
> fluent service properties, meaning that instead of:
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> you then must replace by:
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class,
> "property","service property value"));{code}
> So, the fluent service properties must be commented as in restriction if
> java9+ is used. No need to bump the dm-lambda bundle version, becaue it still
> works using java8.
> 3) the gradle version needs to be updated, and for java11 support, the
> "--no-daemon" option must be used when building.
> [1]
> [https://dzone.com/articles/correct-reflective-access-to-interface-default-methods]
> [2]https://bugs.openjdk.java.net/browse/JDK-8138729
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5336) Add support for prototype scope services in DM4
[ https://issues.apache.org/jira/browse/FELIX-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop resolved FELIX-5336. -- Resolution: Fixed Committed a fix in revision 1844112, in order to avoid the double instantiation of scoped services. (test case: ScopedServiceUnexpectedlyInstantiatedTest.java) Also, Committed a fix which auto detects if the component has an init method: when the component does not provide an init method, then the prototype instance is not created. > Add support for prototype scope services in DM4 > --- > > Key: FELIX-5336 > URL: https://issues.apache.org/jira/browse/FELIX-5336 > Project: Felix > Issue Type: New Feature > Components: Dependency Manager, Dependency Manager Annotations, > Dependency Manager Lambda, Dependency Manager Runtime >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Major > Fix For: org.apache.felix.dependencymanager-r12 > > Attachments: FELIX-5336.tgz > > > In the users mailing list, there is a wish to add support in DM4 for OSGi > prototype scope services, which allows any service consumer to get its own > instance of a given service dependency. > See http://www.mail-archive.com/users@felix.apache.org/msg17473.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-5967) DM does not support java9+
[
https://issues.apache.org/jira/browse/FELIX-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop resolved FELIX-5967.
--
Resolution: Fixed
Fixed in revision revision 1844108.
The fluent service properties have been deprecated , and currently only work
using java8, and will be removed in next version.
> DM does not support java9+
> --
>
> Key: FELIX-5967
> URL: https://issues.apache.org/jira/browse/FELIX-5967
> Project: Felix
> Issue Type: Improvement
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> Dependency Manager can't be built/used on java9+ (9,10,11), because of the
> following issues:
> 1) for configuration types, when we parse interface "default methods", the
> way we are parsing does not work in java 9+, and a patch must be applied.
> See [1].
> 2) for dm-lambda, the way to parse the lambda parameter names for "fluent"
> service properties (which requires the -parameters javac option) does not
> work in java 9+.
> For example, the following does not work
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> So, the "property" lambda parameter name can't be parsed in Java9+. This is
> likely because starting from java9, the -parameters option is not generating
> anymore the metadata for the lambda parameter names (see [2]). For the
> moment, the fluent service properties willl work only using java8, but not
> anymore on java9+, and the most reasonable thing is to deprecate the usage of
> fluent service properties, meaning that instead of:
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class, property ->
> "service property value"));{code}
> you then must replace by:
> {code:java}
> compnent(comp -> comp.impl(Foo.class).provides(FooService.class,
> "property","service property value"));{code}
> So, the fluent service properties must be commented as in restriction if
> java9+ is used. No need to bump the dm-lambda bundle version, becaue it still
> works using java8.
> 3) the gradle version needs to be updated, and for java11 support, the
> "--no-daemon" option must be used when building.
> [1]
> [https://dzone.com/articles/correct-reflective-access-to-interface-default-methods]
> [2]https://bugs.openjdk.java.net/browse/JDK-8138729
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5336) Add support for prototype scope services in DM4
[
https://issues.apache.org/jira/browse/FELIX-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653279#comment-16653279
]
Pierre De Rop commented on FELIX-5336:
--
While trying to release the R12 candidate release, another issue regarding
service scopes has been noticed:
By default, when you define a scoped service using the DM API, then a prototype
instance is always created in case you implement a component.init method in
order to add extra required dependencies. So, the prototype instance is there
only to invoke the component.init method, but is never started or stopped. It
is only there to register the PrototypeServiceFactory once all required
dependencies (including required extra dependencies defined in the
component.init method) are injected in the prototype instance. And when someone
request a service instance (using the PrototypeServiceFactory.get mehod for
example), then at this point a new component instance is created, all
dependencies are cloned to it, and the new component instance is then started
and returned to the user. Finally, the component clone is stopped when the
PrototypeServiceFactory.unget() method is called.
Now, if you don't need the component.init() method and if you don't want to let
DM create a prototype instance, then you can set the init callback to null,
explicitely:
{code:java}
Component.setCallbacks(null, "start", "stop", null){code}
This ensures that no prototype instance is created.
When you use DM Annotations, this is what is done by default, except if you
annotate your init method with @Init.
Now, when you define a prototype component using the DM API, it is easy to
forget to set the "init" callback to null when you actually don't have an init
callback in the component, and in this case, the consequence is that the
component prototype instance is created uselessly.
DM API should auto detect if the init method is defined, and if yes, then the
prototype instance should be created. Else, the prototype instance should not
be created.
This will avoid people to wonder why the prototype instance is created.
> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
> Issue Type: New Feature
> Components: Dependency Manager, Dependency Manager Annotations,
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r12
>
> Attachments: FELIX-5336.tgz
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi
> prototype scope services, which allows any service consumer to get its own
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5336) Add support for prototype scope services in DM4
[
https://issues.apache.org/jira/browse/FELIX-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653264#comment-16653264
]
Pierre De Rop commented on FELIX-5336:
--
While trying to release the R12 candidate release, someone reported to me a bug
regarding this Jira issue: sometimes a scoped service is instantiated and
started unexpectedly:
Example: let's say we have two scoped services S1, and S2 (with
scope=PROTOTYPE), and S1 depends on S2:
{code:java}
@Component(scope=PROTOTYPE)
class S1Impl implemements S1 {
@ServiceDependency
S2 s2;
...
}
@Component(scope=PROTOTYPE)
class S2Impl implemements S2 {
...
}
{code}
Now, the bug is the following: when someone requests S1, then S2 is
instantiated and started twice.
This is because when we track the service dependency for S1Impl, we
dereference the service S2 before registering the PrototypeServiceFactory in
the service registry. This is clearly a serious bug which justify to cancel the
R2 candidate release (show stopper issue , to my opinion).
> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
> Issue Type: New Feature
> Components: Dependency Manager, Dependency Manager Annotations,
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r12
>
> Attachments: FELIX-5336.tgz
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi
> prototype scope services, which allows any service consumer to get its own
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
