[jira] [Commented] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active
[ https://issues.apache.org/jira/browse/FELIX-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756405#comment-13756405 ] Timothy Ward commented on FELIX-4212: - Hi Richard, Thanks for locating the relevant part of the spec. The R4.3 JavaDoc for BundleWiring.getCapabilities() doesn't mention the resolver (hence my confusion) The wording is as follows: - java.util.List getCapabilities(java.lang.String namespace) Returns the capabilities provided by this bundle wiring. A capability may not be required by any bundle wiring and thus there may be no wires for the capability. A bundle wiring for a non-fragment revision provides a subset of the declared capabilities from the bundle revision and all attached fragment revisions. Not all declared capabilities may be provided since some may be discarded. For example, if a package is declared to be exported and import, only one is selected and the other is discarded. Parameters: namespace - The name space of the capabilities to return or null to return the capabilities from all name spaces. Returns: A list containing a snapshot of the BundleCapabilitys, or an empty list if this bundle wiring provides no capabilities in the specified name space. If this bundle wiring is not in use, null will be returned. For a given name space, the list contains the wires in the order the capabilities were specified in the manifests of the bundle revision and the attached fragments of this bundle wiring. There is no ordering defined between capabilities in different name spaces. -- This was updated in R5 to: --- java.util.List getCapabilities(java.lang.String namespace) Returns the capabilities provided by this bundle wiring. Only capabilities considered by the resolver are returned. For example, capabilities with effective directive not equal to resolve are not returned. A capability may not be required by any bundle wiring and thus there may be no wires for the capability. A bundle wiring for a non-fragment revision provides a subset of the declared capabilities from the bundle revision and all attached fragment revisions†. Not all declared capabilities may be provided since some may be discarded. For example, if a package is declared to be both exported and imported, only one is selected and the other is discarded. A bundle wiring for a fragment revision with a symbolic name must provide exactly one identity capability. † The identity capability provided by attached fragment revisions must not be included in the capabilities of the host bundle wiring. Parameters: namespace - The namespace of the capabilities to return or null to return the capabilities from all namespaces. Returns: A list containing a snapshot of the BundleCapabilitys, or an empty list if this bundle wiring provides no capabilities in the specified namespace. If this bundle wiring is not in use, null will be returned. For a given namespace, the list contains the wires in the order the capabilities were specified in the manifests of the bundle revision and the attached fragments† of this bundle wiring. There is no ordering defined between capabilities in different namespaces. I've put in a quick test. My bundle manifest contains: -- Provide-Capability: test.namespace, test.namespace; effective:=active Require-Capability: test.namespace; filter:="(foo=bar)"; resolution:=optional, test.namespace; filter:="(foo=bar)"; effective:=active -- and I see the following: Felix 4.2.1: Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Felix 4.2.0: Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Felix 4.0.3: Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Equinox 3.8.2: -- Bundle Revision test.namespace effective null test.namespace effective active test.namespace effective null test.namespace effective active Bundle Wiring test.namespace effective null Equinox 3.7.2: -- Bundle Revision test.namespace effective null test.namespace effective null Bundle Wiring test.namespace effective null Looks like I should raise a bug against Equinox 3.7.x ... > Felix framework doesn't provide access to Generic Requirements and > Capabilities with effective:=active > -- > > Key: FELIX-4212 >
[jira] [Closed] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active
[ https://issues.apache.org/jira/browse/FELIX-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Ward closed FELIX-4212. --- Resolution: Invalid > Felix framework doesn't provide access to Generic Requirements and > Capabilities with effective:=active > -- > > Key: FELIX-4212 > URL: https://issues.apache.org/jira/browse/FELIX-4212 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.2.1 >Reporter: Timothy Ward >Priority: Critical > > I am trying to access Require-Capability and Provide-Capability metadata from > my bundle's manifest using the BundleWiring API. Most capabilities show up > fine, but none of the ones with effective:=active are present. I understand > that these capabilities are ignored by the resolver, and may not have any > wirings, but I expect them to show up anyway. This avoids me having to > provide my own parsing code to turn the manifest entries into Requirements > and Capabilities. > Having checked with the OSGi Core Platform Expert group, active time > requirements and capabilities really should be showing up in the > BundleWiring. My guess is that this will be easy to fix! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-4213) Temporal handler broken with iPOJO 1.10.1
[ https://issues.apache.org/jira/browse/FELIX-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Sauthier reassigned FELIX-4213: - Assignee: Guillaume Sauthier > Temporal handler broken with iPOJO 1.10.1 > - > > Key: FELIX-4213 > URL: https://issues.apache.org/jira/browse/FELIX-4213 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.10.1 >Reporter: Tilen Jez >Assignee: Guillaume Sauthier > > Trying to use Temporal Service Dependency handler with iPOJO 1.10.1 results > in the following error (works fine with 1.10.0): > java.lang.NoSuchMethodError: > org.apache.felix.ipojo.util.DependencyModel.loadSpecification(Ljava/lang/String;Lorg/osgi/framework/BundleContext;)Ljava/lang/Class; > at > org.apache.felix.ipojo.handler.temporal.TemporalHandler.__configure(TemporalHandler.java:248) > at > org.apache.felix.ipojo.handler.temporal.TemporalHandler.configure(TemporalHandler.java) > at org.apache.felix.ipojo.HandlerManager.init(HandlerManager.java:73) > at > org.apache.felix.ipojo.InstanceManager.configure(InstanceManager.java:203) > at > org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:177) > at > org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:309) > at > org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:236) > at > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:290) > at > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:284) > at > org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:100) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4213) Temporal handler broken with iPOJO 1.10.1
[ https://issues.apache.org/jira/browse/FELIX-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Sauthier resolved FELIX-4213. --- Resolution: Fixed Fix Version/s: ipojo-temporal-dependency-handler-1.8.0 Changes pushed in trunk (r1519602). Snapshots should be uploaded in a couple of hours. Please make a try and close if satisfied > Temporal handler broken with iPOJO 1.10.1 > - > > Key: FELIX-4213 > URL: https://issues.apache.org/jira/browse/FELIX-4213 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.10.1 >Reporter: Tilen Jez >Assignee: Guillaume Sauthier > Fix For: ipojo-temporal-dependency-handler-1.8.0 > > > Trying to use Temporal Service Dependency handler with iPOJO 1.10.1 results > in the following error (works fine with 1.10.0): > java.lang.NoSuchMethodError: > org.apache.felix.ipojo.util.DependencyModel.loadSpecification(Ljava/lang/String;Lorg/osgi/framework/BundleContext;)Ljava/lang/Class; > at > org.apache.felix.ipojo.handler.temporal.TemporalHandler.__configure(TemporalHandler.java:248) > at > org.apache.felix.ipojo.handler.temporal.TemporalHandler.configure(TemporalHandler.java) > at org.apache.felix.ipojo.HandlerManager.init(HandlerManager.java:73) > at > org.apache.felix.ipojo.InstanceManager.configure(InstanceManager.java:203) > at > org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:177) > at > org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:309) > at > org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:236) > at > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:290) > at > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:284) > at > org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:100) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Dependency hell
Hi, im trying to integrate https://github.com/pubnub/java/tree/master/java this java project into a service bundle which will abstract most of its usage and only display some simple APIs. But this project depends on alot of jars and Im having real big problems trying to integrate this. First attempt was to just wrap the Pubnub standalone jar which live s in the root folder, but that did not work well with all the other dependencies. Second attempt, I tried to wrap all the libs into a bundle exporting its interfaces, but then I managed to tumble down to a library which is not in the folder, and that I do not have in my Java class path originally. Any suggestions to how I might embark this task? -- Mvh Snorre Lothar von Gohren Edwin MeetMe: http://doodle.com/vonGohren +47 411 611 94
[jira] [Closed] (FELIX-4213) Temporal handler broken with iPOJO 1.10.1
[ https://issues.apache.org/jira/browse/FELIX-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilen Jez closed FELIX-4213. Tested OK with latest snapshot. Thank you. > Temporal handler broken with iPOJO 1.10.1 > - > > Key: FELIX-4213 > URL: https://issues.apache.org/jira/browse/FELIX-4213 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.10.1 >Reporter: Tilen Jez >Assignee: Guillaume Sauthier > Fix For: ipojo-temporal-dependency-handler-1.8.0 > > > Trying to use Temporal Service Dependency handler with iPOJO 1.10.1 results > in the following error (works fine with 1.10.0): > java.lang.NoSuchMethodError: > org.apache.felix.ipojo.util.DependencyModel.loadSpecification(Ljava/lang/String;Lorg/osgi/framework/BundleContext;)Ljava/lang/Class; > at > org.apache.felix.ipojo.handler.temporal.TemporalHandler.__configure(TemporalHandler.java:248) > at > org.apache.felix.ipojo.handler.temporal.TemporalHandler.configure(TemporalHandler.java) > at org.apache.felix.ipojo.HandlerManager.init(HandlerManager.java:73) > at > org.apache.felix.ipojo.InstanceManager.configure(InstanceManager.java:203) > at > org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:177) > at > org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:309) > at > org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:236) > at > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:290) > at > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:284) > at > org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:100) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Metatype release?
Thanks LGTM. How about some tests ;-) Regards Felix Am 02.09.2013 um 23:11 schrieb Carsten Ziegeler: > Ok, I've committed a fix for FELIX-3884, would be great if someone could > cross check the change. > > Carsten > > > 2013/9/3 Felix Meschberger > >> Hi >> >> There are three issues unresolved of which FELIX-3884 is a spec bug. I >> think wr should at least also include that. >> >> Regards >> Felix >> >> >> >> Ursprüngliche Nachricht >> Von: Carsten Ziegeler >> Datum: >> An: dev@felix.apache.org >> Betreff: Metatype release? >> >> >> Hi, >> >> I think it's time for a new release of our metatype implementation. Is >> anyone aware of something we should fix before a release? >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> cziege...@apache.org >> > > > > -- > Carsten Ziegeler > cziege...@apache.org smime.p7s Description: S/MIME cryptographic signature
[jira] [Resolved] (FELIX-3884) [Metatype] Default value and options
[ https://issues.apache.org/jira/browse/FELIX-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-3884. - Resolution: Fixed Added some basic tests > [Metatype] Default value and options > > > Key: FELIX-3884 > URL: https://issues.apache.org/jira/browse/FELIX-3884 > Project: Felix > Issue Type: Task > Components: Metatype Service >Affects Versions: metatype-1.0.6 >Reporter: Felix Meschberger >Assignee: Carsten Ziegeler > Fix For: metatype-1.0.8 > > > There will be a clarification in the Metatype specification for attribute > descriptors (AD): If an AD has a list of option values, the default value > should in fact be one of these listed values. Implementations will be > required to validate this and discard the default value if not on the list. > Currently our implementation just takes the default value(s). We should > change and validate the values and discard those not being part of the option > list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Metatype release?
I've added some basic tests Carsten 2013/9/3 Felix Meschberger > Thanks > > LGTM. How about some tests ;-) > > Regards > Felix > > Am 02.09.2013 um 23:11 schrieb Carsten Ziegeler: > > > Ok, I've committed a fix for FELIX-3884, would be great if someone could > > cross check the change. > > > > Carsten > > > > > > 2013/9/3 Felix Meschberger > > > >> Hi > >> > >> There are three issues unresolved of which FELIX-3884 is a spec bug. I > >> think wr should at least also include that. > >> > >> Regards > >> Felix > >> > >> > >> > >> Ursprüngliche Nachricht > >> Von: Carsten Ziegeler > >> Datum: > >> An: dev@felix.apache.org > >> Betreff: Metatype release? > >> > >> > >> Hi, > >> > >> I think it's time for a new release of our metatype implementation. Is > >> anyone aware of something we should fix before a release? > >> > >> Regards > >> Carsten > >> -- > >> Carsten Ziegeler > >> cziege...@apache.org > >> > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > > -- Carsten Ziegeler cziege...@apache.org
