[jira] [Updated] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3456: - Comment: was deleted (was: ComponentContext.enable and .disable must set the enabled and disabled state immediately but any action resulting from this must be asynchronous. The current implementation violates the spec in that the status is not immediately set. But the actual action occurrs asynchronously as mandated in section 112.5.1. This is to my knowledge the only explicit notion of timing. Particularly there is no requirement to either activate or deactivate components synchronously or asynchronously on SCR or bundle startup or stop. Experience showed me that any attempt to make these asynchronous (remember we had them both asynchronous at one point in time) had issues. Stopping components asynchronously on bundle or SCR shutdown or service unregistration causes problems (been there done that). Starting components asynchronously causes non-deterministic startup behaviour while not being much more stable with respect to deadlocks. So, I really don't want to change that. If we need to fix something to make ComponentContext.enable and .disable more spec compliant (setting the state immediately while doing the action asynchronously), we can do so) > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.1.diff, FELIX-3456-1.diff, > FELIX-3456-3.diff, FELIX-3456-4.diff, FELIX-3456-5.diff, FELIX-3456-5a.diff, > FELIX-3456-5b.diff, FELIX-3456-fmeschbe.patch > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoughts about > this issue? > Thanks -- This message i
[jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278389#comment-13278389 ] Felix Meschberger commented on FELIX-3456: -- ComponentContext.enable and .disable must set the enabled and disabled state immediately but any action resulting from this must be asynchronous. The current implementation violates the spec in that the status is not immediately set. But the actual action occurrs asynchronously as mandated in section 112.5.1. This is to my knowledge the only explicit notion of timing. Particularly there is no requirement to either activate or deactivate components synchronously or asynchronously on SCR or bundle startup or stop. Experience showed me that any attempt to make these asynchronous (remember we had them both asynchronous at one point in time) had issues. Stopping components asynchronously on bundle or SCR shutdown or service unregistration causes problems (been there done that). Starting components asynchronously causes non-deterministic startup behaviour while not being much more stable with respect to deadlocks. So, I really don't want to change that. If we need to fix something to make ComponentContext.enable and .disable more spec compliant (setting the state immediately while doing the action asynchronously), we can do so > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.1.diff, FELIX-3456-1.diff, > FELIX-3456-3.diff, FELIX-3456-4.diff, FELIX-3456-5.diff, FELIX-3456-5a.diff, > FELIX-3456-5b.diff, FELIX-3456-fmeschbe.patch > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoughts about > thi
[jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278354#comment-13278354 ] David Jencks commented on FELIX-3456: - >> makes the enable/activate and disable/deactivate happen per spec as >> enable/disable immediate and activate/deactivate asynchronous. >As I said before, these are already asynchronous because the >BundleComponentActivator.enableComponent and .disableComponent schedule the >actual call to activateInternal and deactivateInternal for asynchronous >execution. The activate/deactivate were already asynchronous but the enable/disable were too, which is contrary to the spec and IMO a pretty bad idea. This part of my change is to separate the enable from activate and disable from deactivate. I think we haven't heard of problems only because no one uses this much. But, maybe the requirement in the spec just makes no sense and I don't see why yet. > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.1.diff, FELIX-3456-1.diff, > FELIX-3456-3.diff, FELIX-3456-4.diff, FELIX-3456-5.diff, FELIX-3456-5a.diff, > FELIX-3456-5b.diff, FELIX-3456-fmeschbe.patch > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoughts about > this issue? > Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3514) Enable support for dynamic import
[ https://issues.apache.org/jira/browse/FELIX-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-3514: - Attachment: org.apache.felix.resolver.patch This patch enables a bit of code to do dynamic resolution. The patch needs plenty of review because I am not confident I got all the details correct. For example, I did not perform a check in the resolver to see if the current host wiring has a package source for the requested package or not. I think this could or should be something done outside of the resolver before attempting to do a dynamic resolve operation. > Enable support for dynamic import > - > > Key: FELIX-3514 > URL: https://issues.apache.org/jira/browse/FELIX-3514 > Project: Felix > Issue Type: Bug > Components: Resolver > Environment: All >Reporter: Thomas Watson > Attachments: org.apache.felix.resolver.patch > > > The OSGi R5 Resolver API does not provide a way to (easily) resolve dynamic > imports. This is important if the resolver is to be used at runtime. The > current resolver implementation has a bit of disabled code commented out that > could be used to implement this. I will attach a patch that enables a new > method on ResolverImpl to enable dynamic resolution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3514) Enable support for dynamic import
Thomas Watson created FELIX-3514: Summary: Enable support for dynamic import Key: FELIX-3514 URL: https://issues.apache.org/jira/browse/FELIX-3514 Project: Felix Issue Type: Bug Components: Resolver Environment: All Reporter: Thomas Watson The OSGi R5 Resolver API does not provide a way to (easily) resolve dynamic imports. This is important if the resolver is to be used at runtime. The current resolver implementation has a bit of disabled code commented out that could be used to implement this. I will attach a patch that enables a new method on ResolverImpl to enable dynamic resolution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Can maven-bundle-plugin use *.bnd files?
yes I'm suggesting documentation for this particular directive would be useful along with the other specifically documented directives like Export-Package which are also explained in more detail in the bnd documentation. thanks david jencks On May 17, 2012, at 11:53 AM, Felix Meschberger wrote: > Hi, > > IIUIC als BND directives with a leading dash can be used in maven by > replacing the dash with an underscore and using the result as an element > name. Thus <_include> for -include or <_exportcontents> for -exportcontents. > > Regards > Felix > > > Am 17.05.2012 um 08:42 schrieb David Jencks: > >> I'm not sure how the felix site is generated >> >> Would it be possible to include something like this in the >> https://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html page >> as the last >> Instructions >> >> ? >> >> <_include> >> You can use standard .bnd files for instructions instead of the xml-style >> instructions explained here with the _include instruction like this: >> <_include>osgi.bnd >> >> >> I don't think its entirely obvious that this particular instruction works as >> well here as in a .bnd file :-) >> >> thanks >> david jencks >> >> >> On May 16, 2012, at 4:57 PM, Stuart McCulloch wrote: >> >>> On 17 May 2012, at 00:43, David Jencks wrote: >>> I thought I remembered seeing some project that used the maven-bundle-plugin but put the instructions in a *.bnd file, but when I've experimented I can't get it to work. Anyone know if this is possible, how to do it, or if not, anyone else think it would be a good idea? >>> >>> Just use <_include>test.bnd as per >>> the bnd docs: http://www.aqute.biz/Bnd/Format#directives >>> >>> Note: paths are relative to the project directory >>> thanks david jencks >>> >> >
Re: Can maven-bundle-plugin use *.bnd files?
Hi, IIUIC als BND directives with a leading dash can be used in maven by replacing the dash with an underscore and using the result as an element name. Thus <_include> for -include or <_exportcontents> for -exportcontents. Regards Felix Am 17.05.2012 um 08:42 schrieb David Jencks: > I'm not sure how the felix site is generated > > Would it be possible to include something like this in the > https://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html page > as the last > Instructions > > ? > > <_include> > You can use standard .bnd files for instructions instead of the xml-style > instructions explained here with the _include instruction like this: > <_include>osgi.bnd > > > I don't think its entirely obvious that this particular instruction works as > well here as in a .bnd file :-) > > thanks > david jencks > > > On May 16, 2012, at 4:57 PM, Stuart McCulloch wrote: > >> On 17 May 2012, at 00:43, David Jencks wrote: >> >>> I thought I remembered seeing some project that used the >>> maven-bundle-plugin but put the instructions in a *.bnd file, but when I've >>> experimented I can't get it to work. Anyone know if this is possible, how >>> to do it, or if not, anyone else think it would be a good idea? >> >> Just use <_include>test.bnd as per >> the bnd docs: http://www.aqute.biz/Bnd/Format#directives >> >> Note: paths are relative to the project directory >> >>> thanks >>> david jencks >>> >> >
[jira] [Resolved] (FELIX-3508) IPojo Manipulator left out 'array of enums' in generated metadata
[ https://issues.apache.org/jira/browse/FELIX-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3508. -- Resolution: Fixed Fixed in trunk > IPojo Manipulator left out 'array of enums' in generated metadata > - > > Key: FELIX-3508 > URL: https://issues.apache.org/jira/browse/FELIX-3508 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Göktürk Gezer >Assignee: Clement Escoffier >Priority: Minor > Labels: ipojo, ipojo-manipulator > Fix For: ipojo-manipulator-1.8.6 > > > Manipulation process recognizes enums as annotation attribute in custom > handler annotations. However it fails to recognize array of enums, and these > arrays does not goes into generated IPojo component metadata for custom > handler. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3508) IPojo Manipulator left out 'array of enums' in generated metadata
[ https://issues.apache.org/jira/browse/FELIX-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278045#comment-13278045 ] Clement Escoffier commented on FELIX-3508: -- I've reproduced the issue (and wrote a test). It seems that they are just completely ignored. > IPojo Manipulator left out 'array of enums' in generated metadata > - > > Key: FELIX-3508 > URL: https://issues.apache.org/jira/browse/FELIX-3508 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-manipulator-1.8.4 >Reporter: Göktürk Gezer >Assignee: Clement Escoffier >Priority: Minor > Labels: ipojo, ipojo-manipulator > Fix For: ipojo-manipulator-1.8.6 > > > Manipulation process recognizes enums as annotation attribute in custom > handler annotations. However it fails to recognize array of enums, and these > arrays does not goes into generated IPojo component metadata for custom > handler. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Felix SCR Annotations - Reference Binding with Map parameter
works now, Thank you Daniel
[jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277809#comment-13277809 ] Felix Meschberger commented on FELIX-3456: -- > makes the enable/activate and disable/deactivate happen per spec as > enable/disable immediate and activate/deactivate asynchronous. As I said before, these are already asynchronous because the BundleComponentActivator.enableComponent and .disableComponent schedule the actual call to activateInternal and deactivateInternal for asynchronous execution. > Component ignores required static service addition when in Activating state > --- > > Key: FELIX-3456 > URL: https://issues.apache.org/jira/browse/FELIX-3456 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 > Environment: Using org.apache.felix.scr svn rev 1298268 on Mac >Reporter: Richard Ellis >Priority: Critical > Attachments: FELIX-3456-1.1.diff, FELIX-3456-1.diff, > FELIX-3456-3.diff, FELIX-3456-4.diff, FELIX-3456-5.diff, FELIX-3456-5a.diff, > FELIX-3456-5b.diff, FELIX-3456-fmeschbe.patch > > > I have a component with two required static service references (A and B). In > my scenario A and B are registered nearly simultaneously on different threads > and this causes the DependencyManager to ignore the addition of one of these > two services (B). This causes the component to remain unsatisfied and never > activate, since the service that was ignored is not re-registered at any time > and nothing subsequently causes the component to re-activate. > This happens as follows: > 12:30:59:317 Thread 1 - Registers Service B/257 > 12:30:59:320 Thread 2 - Registers Service A/258 > 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 > 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, > activate component > 12:30:59:321 Thread 2 - State transition : Unsatisfied -> Activating > 12:30:59:321 Thread 2 - Activating component > 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 > 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB > 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored > for static reference <--- I believe we end up here because Thread 2 has moved > the component from Unsatisfied to Activating and the reference is a static > reference > 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate > 12:30:59:321 Thread 2 - State transition : Activating -> Unsatisfied > Because the addition of Service B has been ignored and serviceB is a required > dependency my component then never activates even though my reqiured service > is present. > There is a comment in DependencyManager#serviceAdded method: > // FELIX-1413: if the dependency is static and the component is > // satisfied (active) added services are not considered until > // the component is reactivated for other reasons. > This suggests that the static service should only be ignored if the component > is satisfied(active), which would be correct, but in this case the component > is only activating (and will fail to activate because one of the two > dependencies is not yet satisfied) and there is no check of state at this > time. > A simple fix would be to check the state of the component as well as if the > service is static e.g. > replace if ( m_dependencyMetadata.isStatic() ) > with if ( m_dependencyMetadata.isStatic() && m_componentManager.getState() == > AbstractComponentManager.STATE_ACTIVE ) > This is an easy fix, but I guess may leave a small window where a static > reference could get replaced while a component was still activating if > another instance of the same service was registered on a different thread. > There are other fixes that could be done by synchronizing more around service > additions. > Is anyone willing to make this fix or does anyone have any thoughts about > this issue? > Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3507) scr greedy and reluctant policy options from compendium 4.3
[ https://issues.apache.org/jira/browse/FELIX-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3507. -- Resolution: Fixed Applied the patch and incremented the API export version to 1.7 due to the new Reference.isReluctant() method. > scr greedy and reluctant policy options from compendium 4.3 > --- > > Key: FELIX-3507 > URL: https://issues.apache.org/jira/browse/FELIX-3507 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.6.0 >Reporter: David Jencks >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: FELIX-3507-1.diff, FELIX-3507-annotations-1.diff > > > The compendium 4.3 has a policy-option for references with new behavior for > "greedy". I've implemented this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: DS 1.2 annotations
Hi Am 17.05.2012 um 01:51 schrieb David Jencks: > I thought I'd seen a message on a similar topic but can't find it right now. Me too ;-) > > DS 1.2 introduces annotations that work a bit differently from the felix DS > annotations. Furthermore it looks like the (unreleased) current bnd code > handles generating the xml from them, with possible overrides from an > instruction/"header" in a .bnd file. Or the bundle plugin configuration. > > I've suggested a patch that extends the felix annotations to expose the new > policy-option. Thanks. Got it and testing it right now. > > Is there any point in extending the felix scr plugin to handle the "official" > DS annotations since bnd already deals with them? I'd guess no I do > think we should check how well the bnd support works through maven. We have been discussing it. I am ... undecided. On the one hand, we already have an easily accessible implementation of those annotations (we should verify whether the bundle plugin way really works). On the other hand, I see the plugin to be a one-stop shop for DS annotations. Currently I am slightly inclined to be in favor to add support to the plugin... Regards Felix > > thanks > david jencks >
Re: DS patches
Hi David, Am 15.05.2012 um 05:15 schrieb David Jencks: > It looks like the jira to email link broke with the jira upgrade along with > the ability to attach files to issues so here's a less informative manual > version > > I just posted a couple patches for SCR: > > https://issues.apache.org/jira/browse/FELIX-3507 implements the new DS 1.2 > policy-option reluctant and greedy options with some tests. I hope this is > not controversial :-) No ;-) Thanks for supplying a path. I am going to apply it (and update the API export version to 1.7 due to the added method in the Reference interface). I have created a sub task for the annotation part. > > https://issues.apache.org/jira/browse/FELIX-3456 now has some -5 patches that > I think are an OK solution to the concurrency problems. Will look into it. Regards Felix
[jira] [Updated] (FELIX-3507) scr greedy and reluctant policy options from compendium 4.3
[ https://issues.apache.org/jira/browse/FELIX-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3507: - Component/s: Specification compliance > scr greedy and reluctant policy options from compendium 4.3 > --- > > Key: FELIX-3507 > URL: https://issues.apache.org/jira/browse/FELIX-3507 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.6.0 >Reporter: David Jencks >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: FELIX-3507-1.diff, FELIX-3507-annotations-1.diff > > > The compendium 4.3 has a policy-option for references with new behavior for > "greedy". I've implemented this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3507) scr greedy and reluctant policy options from compendium 4.3
[ https://issues.apache.org/jira/browse/FELIX-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-3507: Assignee: Felix Meschberger > scr greedy and reluctant policy options from compendium 4.3 > --- > > Key: FELIX-3507 > URL: https://issues.apache.org/jira/browse/FELIX-3507 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 >Reporter: David Jencks >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: FELIX-3507-1.diff, FELIX-3507-annotations-1.diff > > > The compendium 4.3 has a policy-option for references with new behavior for > "greedy". I've implemented this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3507) scr greedy and reluctant policy options from compendium 4.3
[ https://issues.apache.org/jira/browse/FELIX-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277796#comment-13277796 ] Felix Meschberger commented on FELIX-3507: -- Thanks for providing the patch (FELIX-3507-1.diff). I am going to apply it. I leave the application of the annotation patch to subtask FELIX-3513. > scr greedy and reluctant policy options from compendium 4.3 > --- > > Key: FELIX-3507 > URL: https://issues.apache.org/jira/browse/FELIX-3507 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 >Reporter: David Jencks >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: FELIX-3507-1.diff, FELIX-3507-annotations-1.diff > > > The compendium 4.3 has a policy-option for references with new behavior for > "greedy". I've implemented this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3513) Add support for policy-option
[ https://issues.apache.org/jira/browse/FELIX-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277791#comment-13277791 ] Felix Meschberger commented on FELIX-3513: -- Proposed patch attached to FELIX-3507 (https://issues.apache.org/jira/secure/attachment/12527481/FELIX-3507-annotations-1.diff) > Add support for policy-option > - > > Key: FELIX-3513 > URL: https://issues.apache.org/jira/browse/FELIX-3513 > Project: Felix > Issue Type: Sub-task > Components: Maven SCR Plugin >Affects Versions: scr generator 1.1.4, scr annotations 1.6.0 >Reporter: Felix Meschberger > > Support for the reference policy-option should be added to the SCR plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3513) Add support for policy-option
Felix Meschberger created FELIX-3513: Summary: Add support for policy-option Key: FELIX-3513 URL: https://issues.apache.org/jira/browse/FELIX-3513 Project: Felix Issue Type: Sub-task Components: Maven SCR Plugin Affects Versions: scr annotations 1.6.0, scr generator 1.1.4 Reporter: Felix Meschberger Support for the reference policy-option should be added to the SCR plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Felix SCR Annotations - Reference Binding with Map parameter
Hi,
Am 17.05.2012 um 12:18 schrieb Daniel Kuffner:
> Hi All,
>
> I have a question regarding the Felix SCR annotations regarding
> bind/unbind references.
>
> The Declarative Services specification defines the following method
> signatures for binding methods:
> 1. void (ServiceReference);
> 2. void ();
> 3. void (, Map);
Using these signatures requires the component to be declared with the DS V 1.1.
namespace. Otherwise the signature is not checked and thus not used.
>
> I have tried all variants and it seem to be that variant 3 doesn't work.
> I get following error message:
>
> @Reference: Missing method setServiceB for reference serviceB
> @Reference: Missing method unsetServiceB for reference serviceB
>
> Is that a known limitation or do I miss something.
> I use SCR Generator 1.1.4
>
>
> Here is the example code:
>
> import org.apache.felix.scr.annotations.Component;
> import org.apache.felix.scr.annotations.Reference;
> import org.apache.felix.scr.annotations.ReferenceCardinality;
>
> import java.util.Map;
>
> @Component(immediate = true)
Add specVersion="1.1" to declare the component with the DS v.1.1 namespace.
Regards
Felix
> public class ReferenceMapProblem {
>
>@Reference(cardinality = ReferenceCardinality.MANDATORY_UNARY,
>bind = "setServiceB",
>unbind = "unsetServiceB")
>private IServiceB service;
>
>protected void setServiceB(IServiceB s, Map map) {
>// ...
>}
>
>protected void unsetServiceB(IServiceB s, Map map) {
>// ...
>}
> }
[jira] [Created] (FELIX-3512) SCR Annotation Reference Documentation - "interface" must be "referenceInterface"
Daniel Kuffner created FELIX-3512: - Summary: SCR Annotation Reference Documentation - "interface" must be "referenceInterface" Key: FELIX-3512 URL: https://issues.apache.org/jira/browse/FELIX-3512 Project: Felix Issue Type: Bug Components: Documentation Reporter: Daniel Kuffner Please documentation of Reference on http://felix.apache.org/site/scr-annotations.html The table contains a annotation attribute called "interface" which doesn't exist. The correct name is "referenceInterface" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Felix SCR Annotations - Reference Binding with Map parameter
Hi All,
I have a question regarding the Felix SCR annotations regarding
bind/unbind references.
The Declarative Services specification defines the following method
signatures for binding methods:
1. void (ServiceReference);
2. void ();
3. void (, Map);
I have tried all variants and it seem to be that variant 3 doesn't work.
I get following error message:
@Reference: Missing method setServiceB for reference serviceB
@Reference: Missing method unsetServiceB for reference serviceB
Is that a known limitation or do I miss something.
I use SCR Generator 1.1.4
Here is the example code:
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Reference;
import org.apache.felix.scr.annotations.ReferenceCardinality;
import java.util.Map;
@Component(immediate = true)
public class ReferenceMapProblem {
@Reference(cardinality = ReferenceCardinality.MANDATORY_UNARY,
bind = "setServiceB",
unbind = "unsetServiceB")
private IServiceB service;
protected void setServiceB(IServiceB s, Map map) {
// ...
}
protected void unsetServiceB(IServiceB s, Map map) {
// ...
}
}
