[jira] [Created] (FELIX-4211) export jetty api / import it with optional flag
Christoph Läubrich created FELIX-4211: - Summary: export jetty api / import it with optional flag Key: FELIX-4211 URL: https://issues.apache.org/jira/browse/FELIX-4211 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Christoph Läubrich the HTTP Service Jetty embedds a jetty server but does not export the api of jetty itself. So it is impossible to use e.g. Jetty GZIP filter without embedding another version of jetty. To improve this, the bundle can exporrt tje jetty bundles and import them with resolution=optional so it would even be possible to provide a never/patched jetty version to the bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4211) export jetty api / import it with optional flag
[ https://issues.apache.org/jira/browse/FELIX-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755984#comment-13755984 ] Christoph Läubrich commented on FELIX-4211: --- Currently this also makes it impossible to use things like Jetty Continuations since you need access to the jetty classes. > export jetty api / import it with optional flag > --- > > Key: FELIX-4211 > URL: https://issues.apache.org/jira/browse/FELIX-4211 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http-2.2.0 >Reporter: Christoph Läubrich > > the HTTP Service Jetty embedds a jetty server but does not export the api of > jetty itself. So it is impossible to use e.g. Jetty GZIP filter without > embedding another version of jetty. > To improve this, the bundle can exporrt tje jetty bundles and import them > with resolution=optional so it would even be possible to provide a > never/patched jetty version to the bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active
Timothy Ward created FELIX-4212: --- Summary: Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active Key: FELIX-4212 URL: https://issues.apache.org/jira/browse/FELIX-4212 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.2.1 Reporter: Timothy Ward Priority: Critical I am trying to access Require-Capability and Provide-Capability metadata from my bundle's manifest using the BundleWiring API. Most capabilities show up fine, but none of the ones with effective:=active are present. I understand that these capabilities are ignored by the resolver, and may not have any wirings, but I expect them to show up anyway. This avoids me having to provide my own parsing code to turn the manifest entries into Requirements and Capabilities. Having checked with the OSGi Core Platform Expert group, active time requirements and capabilities really should be showing up in the BundleWiring. My guess is that this will be easy to fix! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4213) Temporal handler broken with iPOJO 1.10.1
Tilen Jez created FELIX-4213: Summary: 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 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: Sporadic problems with metatype service
It seems the cache in BundleResources is the problem. I've created FELIX-4214 to track/fix this Carsten 2013/8/30 Carsten Ziegeler > Hi, > > I'm experiencing sporadic problems with the metatype service > implementation. In my case I'm using the scr plugin to generate the > metatype information and this generates an xml for each metadata with a > localization attribute set to the base of a custom properties file > containing i18n translations, so something like > localization=OSGI-INF/metatype/myservice > And I have a properties file at OSGI-INF/metatype/myservice.properties > > In most cases, it seems this properties file is not found/read - however, > after N updates of my bundle containing this, it starts to work and the > properties file is picked up. Restarting the framework makes it fail again, > until another couple of bundle updates. > If the default file OSGI-INF/metatype/metatype is specified in the > localization field, this file (metatype.properties) is always picked up. > > I tried both, released version 1.0.6 and latest trunk. > > Maybe this is some strange ordering bug somewhere? I haven't really > debugged into this, but at first glance, it seems if it fails it's never > looking for the OSGI-INF/metatype/myservice.properties entry in the bundle; > when it works its obviously doing that. > > Regards > Carsten > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
[jira] [Created] (FELIX-4214) Static cache in BundleResources is not updated
Carsten Ziegeler created FELIX-4214: --- Summary: Static cache in BundleResources is not updated Key: FELIX-4214 URL: https://issues.apache.org/jira/browse/FELIX-4214 Project: Felix Issue Type: Bug Components: Metatype Service Affects Versions: metatype-1.0.6 Reporter: Carsten Ziegeler Priority: Critical Fix For: metatype-1.0.8 In some cases, the static cache in BundleResources is not updated correctly when a bundle is updated. It seems this is especially a problem, if there is more than one resource file for metatype information. In my case I experienced the problem with the following setup: I'm using the scr plugin to generate the metatype information and this generates an xml for each metadata with a localization attribute set to the base of a custom properties file containing i18n translations, so something like localization=OSGI-INF/metatype/myservice And I have a properties file at OSGI-INF/metatype/myservice.properties In most cases, it seems this properties file is not found/read - however, after N updates of my bundle containing this, it starts to work and the properties file is picked up. Restarting the framework makes it fail again, until another couple of bundle updates. If the default file OSGI-INF/metatype/metatype is specified in the localization field, this file (metatype.properties) is always picked up. Disabling the static cache resourcesByBundle in BundleResources solves the problem -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4214) Static cache in BundleResources is not updated
[ https://issues.apache.org/jira/browse/FELIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756147#comment-13756147 ] Carsten Ziegeler commented on FELIX-4214: - I think the problem is that the cache is not taking the basename into account and as soon as there is more than one metatype file the first one used is returned for all basenames > Static cache in BundleResources is not updated > -- > > Key: FELIX-4214 > URL: https://issues.apache.org/jira/browse/FELIX-4214 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Affects Versions: metatype-1.0.6 >Reporter: Carsten Ziegeler >Priority: Critical > Fix For: metatype-1.0.8 > > > In some cases, the static cache in BundleResources is not updated correctly > when a bundle is updated. It seems this is especially a problem, if there is > more than one resource file for metatype information. In my case I > experienced the problem with the following setup: > I'm using the scr plugin to generate the metatype information and this > generates an xml for each metadata with a localization attribute set to the > base of a custom properties file containing i18n translations, so something > like localization=OSGI-INF/metatype/myservice > And I have a properties file at OSGI-INF/metatype/myservice.properties > In most cases, it seems this properties file is not found/read - however, > after N updates of my bundle containing this, it starts to work and the > properties file is picked up. Restarting the framework makes it fail again, > until another couple of bundle updates. > If the default file OSGI-INF/metatype/metatype is specified in the > localization field, this file (metatype.properties) is always picked up. > Disabling the static cache resourcesByBundle in BundleResources solves the > problem -- 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-4214) Static cache in BundleResources is not updated
[ https://issues.apache.org/jira/browse/FELIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-4214: --- Assignee: Carsten Ziegeler > Static cache in BundleResources is not updated > -- > > Key: FELIX-4214 > URL: https://issues.apache.org/jira/browse/FELIX-4214 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Affects Versions: metatype-1.0.6 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: metatype-1.0.8 > > > In some cases, the static cache in BundleResources is not updated correctly > when a bundle is updated. It seems this is especially a problem, if there is > more than one resource file for metatype information. In my case I > experienced the problem with the following setup: > I'm using the scr plugin to generate the metatype information and this > generates an xml for each metadata with a localization attribute set to the > base of a custom properties file containing i18n translations, so something > like localization=OSGI-INF/metatype/myservice > And I have a properties file at OSGI-INF/metatype/myservice.properties > In most cases, it seems this properties file is not found/read - however, > after N updates of my bundle containing this, it starts to work and the > properties file is picked up. Restarting the framework makes it fail again, > until another couple of bundle updates. > If the default file OSGI-INF/metatype/metatype is specified in the > localization field, this file (metatype.properties) is always picked up. > Disabling the static cache resourcesByBundle in BundleResources solves the > problem -- 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-4214) Cache in BundleResources works only for a single metatype properties file per bundle
[ https://issues.apache.org/jira/browse/FELIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4214. - Resolution: Fixed Solved by adding the basename to the cache key > Cache in BundleResources works only for a single metatype properties file per > bundle > > > Key: FELIX-4214 > URL: https://issues.apache.org/jira/browse/FELIX-4214 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Affects Versions: metatype-1.0.6 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: metatype-1.0.8 > > > In some cases, the static cache in BundleResources is not updated correctly > when a bundle is updated. It seems this is especially a problem, if there is > more than one resource file for metatype information. In my case I > experienced the problem with the following setup: > I'm using the scr plugin to generate the metatype information and this > generates an xml for each metadata with a localization attribute set to the > base of a custom properties file containing i18n translations, so something > like localization=OSGI-INF/metatype/myservice > And I have a properties file at OSGI-INF/metatype/myservice.properties > In most cases, it seems this properties file is not found/read - however, > after N updates of my bundle containing this, it starts to work and the > properties file is picked up. Restarting the framework makes it fail again, > until another couple of bundle updates. > If the default file OSGI-INF/metatype/metatype is specified in the > localization field, this file (metatype.properties) is always picked up. > Disabling the static cache resourcesByBundle in BundleResources solves the > problem -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4214) Cache in BundleResources works only for a single metatype properties file per bundle
[ https://issues.apache.org/jira/browse/FELIX-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-4214: Summary: Cache in BundleResources works only for a single metatype properties file per bundle (was: Static cache in BundleResources is not updated) > Cache in BundleResources works only for a single metatype properties file per > bundle > > > Key: FELIX-4214 > URL: https://issues.apache.org/jira/browse/FELIX-4214 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Affects Versions: metatype-1.0.6 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Critical > Fix For: metatype-1.0.8 > > > In some cases, the static cache in BundleResources is not updated correctly > when a bundle is updated. It seems this is especially a problem, if there is > more than one resource file for metatype information. In my case I > experienced the problem with the following setup: > I'm using the scr plugin to generate the metatype information and this > generates an xml for each metadata with a localization attribute set to the > base of a custom properties file containing i18n translations, so something > like localization=OSGI-INF/metatype/myservice > And I have a properties file at OSGI-INF/metatype/myservice.properties > In most cases, it seems this properties file is not found/read - however, > after N updates of my bundle containing this, it starts to work and the > properties file is picked up. Restarting the framework makes it fail again, > until another couple of bundle updates. > If the default file OSGI-INF/metatype/metatype is specified in the > localization field, this file (metatype.properties) is always picked up. > Disabling the static cache resourcesByBundle in BundleResources solves the > problem -- 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
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
AW: Metatype release?
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
[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=13756316#comment-13756316 ] Richard S. Hall commented on FELIX-4212: I'm not sure what you want is correct for BundleWiring.getCapabilities(), etc. From the OSGi R5 API: "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." There is similar wording for getRequirements(). I think you'd have to look into BundleRevision.getDeclaredCapabilities(), etc. I'm not 100% certain this works in Felix either, but it makes more sense than getting them from BundleWiring since the wiring is the result of the resolver and what you are looking for is stuff the resolver ignores. > 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-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 reassigned FELIX-3884: --- Assignee: Carsten Ziegeler > [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
[jira] [Commented] (FELIX-3884) [Metatype] Default value and options
[ https://issues.apache.org/jira/browse/FELIX-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756382#comment-13756382 ] Carsten Ziegeler commented on FELIX-3884: - I've committed a simple implementation in 1519567 which checks the default values against the validator > [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?
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
