Re: [Web Console] Some minor fixes
On Saturday 31 May 2008 04:19, Pedro Pedruzzi wrote: > Patch attached with some minor fixes in the Configuration render. Patches are needed to be posted to JIRA, as that provides a record of you aer providing it on Apache License terms. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
[jira] Commented: (FELIX-581) Allow creating configuration for managed services and service factories
[ https://issues.apache.org/jira/browse/FELIX-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601337#action_12601337 ] Dieter Wimberger commented on FELIX-581: I took a look at the sources (1.0.0 release) and I think that actually there is code in place to do this. After adding some quick and dirty stack trace printing it occurs to me that: 1) pax-web may have an incorrect metatype file: org.xml.sax.SAXException: Fatal Error: URI=null Line=1: Content is not allowed in prolog. If I find time to fix this problem, I may try to figure out if the webconsole allows to create the configuration. 2) ManagedServiceFactory instances cannot be configured because the code does not properly handle how to create and later display configurations for these instances (i.e. the instance needs to use the OCD from the factory). I am trying to fix 2); is a patch against the 1.0.0 release code good, or would you need one against the repository? > Allow creating configuration for managed services and service factories > --- > > Key: FELIX-581 > URL: https://issues.apache.org/jira/browse/FELIX-581 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-1.0.0 >Reporter: Dieter Wimberger > > The web console does not support to create configurations for: > 1) managed services (which did not register any themselves); and > 2) managed service factories (for service instances). > An example for 1) is the pax-web service: at the moment there is no way to > add a configuration for it using the web console. > As of 2) I think that a factory may have multiple Configuration objects > associated, each of them configuring one service instance (this way its > possible to configure, create and delete instances by configuration). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems with URL handler for bundle:// protocol
On May 30, 2008, at 12:48 AM, Richard S. Hall wrote: I will raise a JIRA and attach a patch to do the following: * if the url port is ommitted (thus defaults to -1), use the same behavior as if 0 was used (search in the whole classpath) ok Is this behavior safe? What if two different class path elements can return a resource that matches a particular path? Regards, Alan
[jira] Commented: (FELIX-581) Allow creating configuration for managed services and service factories
[ https://issues.apache.org/jira/browse/FELIX-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601270#action_12601270 ] Dieter Wimberger commented on FELIX-581: I also think that rendering the configuration makes only sense if the MetaType information is available. However, Preferences and Metatype are not really coupled, so you may retrieve MetaType information for: 1) any bundle; or 2) for the bundles that registered a ManagedService or ManagedServiceFactory; even if no Configuration object is available from the configuration admin. What I would suggest is either to go over all installed bundles looking for corresponding MetaTypeInformation (1 above), or if one wants to be more selective, only look for the corresponding service references with BundleContext.getServiceReferences(), and then get the corresponding bundles to find the Metatype information (2 above). To create the factory configurations one can simply use ConfigurationAdmin.createFactoryConfiguration(), which will create a new unique PID for the instance. I have just downloaded the binaries for the web console, so can't tell quickly if this would be hard or difficult to add. > Allow creating configuration for managed services and service factories > --- > > Key: FELIX-581 > URL: https://issues.apache.org/jira/browse/FELIX-581 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-1.0.0 >Reporter: Dieter Wimberger > > The web console does not support to create configurations for: > 1) managed services (which did not register any themselves); and > 2) managed service factories (for service instances). > An example for 1) is the pax-web service: at the moment there is no way to > add a configuration for it using the web console. > As of 2) I think that a factory may have multiple Configuration objects > associated, each of them configuring one service instance (this way its > possible to configure, create and delete instances by configuration). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems with URL handler for bundle:// protocol
I'm trying to export a document from a bundle and make it available on a known uri. Furthermore, I'm trying to export this document using spring-dm. On Fri, May 30, 2008 at 8:36 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > > On May 30, 2008, at 1:09 AM, Guillaume Nodet wrote: > >> On Fri, May 30, 2008 at 9:48 AM, Richard S. Hall <[EMAIL PROTECTED]> >> wrote: >>> >>> Guillaume Nodet wrote: >>> While I agree that these are issues that should be addressed, we are >>> really >>> talking about special cases here, since you generally shouldn't be trying >>> to >>> construct your own bundle resource URL since the URL structure is >>> supposed >>> to be opaque and framework dependent. >>> >>> -> richard >> >> Yeah, I agree this is felix dependant, but it's nonetheless really handy. >> I suppose at some point, I would have to rewrite my own url handler to >> handle this >> in a less felix specific way. > > > My curiosity is now piqued. What exactly are you doing? > > > Regards, > Alan > > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[Web Console] Some minor fixes
Patch attached with some minor fixes in the Configuration render. -- Pedro Pedruzzi | Engenharia de Software | V2COM | +55 11 3094-3939
[jira] Resolved: (FELIX-579) NPE in AbstractComponentManager
[ https://issues.apache.org/jira/browse/FELIX-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-579. - Resolution: Fixed Fix Version/s: scr-1.0.1 Implemented guarding of the BundleComponentActivator for logging in Rev. 661839. Please close this issue, if it solves your problem. Thanks. > NPE in AbstractComponentManager > --- > > Key: FELIX-579 > URL: https://issues.apache.org/jira/browse/FELIX-579 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.0 >Reporter: Carsten Ziegeler >Assignee: Felix Meschberger > Fix For: scr-1.0.1 > > > Sometimes an NPE occurs in the AbstractCompnentManager in line 327 and line > 288. It seems that at this point the component manager is already disposed, > and the activator is set to null. However the activator is used to log. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-579) NPE in AbstractComponentManager
[ https://issues.apache.org/jira/browse/FELIX-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-579: --- Assignee: Felix Meschberger > NPE in AbstractComponentManager > --- > > Key: FELIX-579 > URL: https://issues.apache.org/jira/browse/FELIX-579 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.0.0 >Reporter: Carsten Ziegeler >Assignee: Felix Meschberger > > Sometimes an NPE occurs in the AbstractCompnentManager in line 327 and line > 288. It seems that at this point the component manager is already disposed, > and the activator is set to null. However the activator is used to log. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-581) Allow creating configuration for managed services and service factories
[ https://issues.apache.org/jira/browse/FELIX-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601231#action_12601231 ] Felix Meschberger commented on FELIX-581: - Currently the web console configuration support requires meta type information as from the MetaType service to draw the configuration GUI. But it may be usefull to be able to configure just about any ManagedService and ManagedServiceFactory - yet the respective entry would probably just be a very simple and crude. All in all, this sounds like a useful extension. > Allow creating configuration for managed services and service factories > --- > > Key: FELIX-581 > URL: https://issues.apache.org/jira/browse/FELIX-581 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-1.0.0 >Reporter: Dieter Wimberger > > The web console does not support to create configurations for: > 1) managed services (which did not register any themselves); and > 2) managed service factories (for service instances). > An example for 1) is the pax-web service: at the moment there is no way to > add a configuration for it using the web console. > As of 2) I think that a factory may have multiple Configuration objects > associated, each of them configuring one service instance (this way its > possible to configure, create and delete instances by configuration). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-578) ComponentFactoryImpl.newInstance() must create the component synchronously
[ https://issues.apache.org/jira/browse/FELIX-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-578. - Resolution: Fixed Fix Version/s: scr-1.0.1 Fixed in Rev. 661830: ComponentFactoryImpl.newInstance() now ensures the component is enabled synchronously, that is the ComponentInstance returned will provide the actual component instance in its getInstance() method. Please close this bug, if it fixes your issue. Thanks. > ComponentFactoryImpl.newInstance() must create the component synchronously > -- > > Key: FELIX-578 > URL: https://issues.apache.org/jira/browse/FELIX-578 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.1 > > > The ComponentFactoryImpl.newInstance() method internally calls the > AbstractComponentManager.enable() method to enable and activate the newly > created component instance. The enable() method in turn schedules the > enableInternal() method to run asynchronously. > In the context of the ComponentFactoryImpl.newInstance() method this > asynchronous enablement is not correct, as the caller expects the > ComponentInstance returned from the newInstance to be active. > Hence the ComponentFactoryImpl.newInstance() method must be able to enable > the created component synchronously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-581) Allow creating configuration for managed services and service factories
Allow creating configuration for managed services and service factories --- Key: FELIX-581 URL: https://issues.apache.org/jira/browse/FELIX-581 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-1.0.0 Reporter: Dieter Wimberger The web console does not support to create configurations for: 1) managed services (which did not register any themselves); and 2) managed service factories (for service instances). An example for 1) is the pax-web service: at the moment there is no way to add a configuration for it using the web console. As of 2) I think that a factory may have multiple Configuration objects associated, each of them configuring one service instance (this way its possible to configure, create and delete instances by configuration). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems with URL handler for bundle:// protocol
On May 30, 2008, at 1:09 AM, Guillaume Nodet wrote: On Fri, May 30, 2008 at 9:48 AM, Richard S. Hall <[EMAIL PROTECTED]> wrote: Guillaume Nodet wrote: While I agree that these are issues that should be addressed, we are really talking about special cases here, since you generally shouldn't be trying to construct your own bundle resource URL since the URL structure is supposed to be opaque and framework dependent. -> richard Yeah, I agree this is felix dependant, but it's nonetheless really handy. I suppose at some point, I would have to rewrite my own url handler to handle this in a less felix specific way. My curiosity is now piqued. What exactly are you doing? Regards, Alan
[SCR] Bulk Issue Changes
Hi all, You may have noticed the bulk changes I did on the Declarative Services (SCR) issues: I marked all issues fixed for inclusion in the 1.0 release as being fixed by that version. Regards Felix
[jira] Commented: (FELIX-158) Add Bundle.getBundleContext() method
[ https://issues.apache.org/jira/browse/FELIX-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601211#action_12601211 ] Felix Meschberger commented on FELIX-158: - I think this method is implemented a long time now in the framework. So this may probably be closed, right ? > Add Bundle.getBundleContext() method > > > Key: FELIX-158 > URL: https://issues.apache.org/jira/browse/FELIX-158 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Framework >Reporter: Richard S. Hall >Assignee: Richard S. Hall > > It looks likely that OSGi R4.1 will include this method for accessing bundle > contexts in order to simplify creating cross-framework bundles that require > such functionality, such as Declarative Services. This is a easy method to > implement. It also needs to be guarded by security checks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-464) Cannot retrieve service to be unbound in unbind method taking ServiceReference
[ https://issues.apache.org/jira/browse/FELIX-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-464: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Cannot retrieve service to be unbound in unbind method taking ServiceReference > -- > > Key: FELIX-464 > URL: https://issues.apache.org/jira/browse/FELIX-464 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > Sometimes, the service about to be unbound needs to be retrieved from the > ComponentContext if the unbind method takes the ServiceReference instead of > the service object itself. In these cases, the service fails to be returned > because the AbstractComponentManager.getDependencyManager(String) only > returns DependencyManager instances whose size is not zero. > This now constitutes a race condition, as the service count has already been > decremented in the DependencyManager when the unbind method is called. The > service itself, though, is actually still available. > The fix is to always return any available DependencyManager regardless of the > perceived size. The DependencyManager will then return the service or not > dependending on whether the service is still available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-106) SCR doesn't support XML documents with namespaces
[ https://issues.apache.org/jira/browse/FELIX-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-106: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > SCR doesn't support XML documents with namespaces > - > > Key: FELIX-106 > URL: https://issues.apache.org/jira/browse/FELIX-106 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Guillaume Sauthier >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: scr-1.0.0 > > > For instance, the following (valid) XML will lead to an Exception : > http://www.osgi.org/xmlns/scr/v1.0.0"; > xmlns:scr="http://www.osgi.org/xmlns/scr/v1.0.0"; > name="scr.MyService"> > > > Does KXML2 supports namespaces ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-373) Log the unsatisfied dependencies of a component which prevent activation of the component
[ https://issues.apache.org/jira/browse/FELIX-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-373: Fix Version/s: scr-1.0.0 > Log the unsatisfied dependencies of a component which prevent activation of > the component > - > > Key: FELIX-373 > URL: https://issues.apache.org/jira/browse/FELIX-373 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > A component may only be activated if all references may be satisifed. > Otherwise the component stays unsatisfied. > It would be a big releave if the unsatifsifed dependencies would be logged > such that a system administrator may easily resolve why a certain component > is not activated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-357) activation and deactivation may run concurrently
[ https://issues.apache.org/jira/browse/FELIX-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-357: Fix Version/s: scr-1.0.0 > activation and deactivation may run concurrently > > > Key: FELIX-357 > URL: https://issues.apache.org/jira/browse/FELIX-357 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > In some situations like multiple static service references actively changing > state the AbstractComponentManager.activateInternal and > AbstractComponentManager.deactivateInternal may run concurrently due to the > fixes introduced by FELIX-341 where the deactivateInternal method is now > immediately called but the activateInternal method is still scheduled for > asynchronous execution. > The current measures in these methods to selectively set the state do not > seem to be adequate to prevent concurrent execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-366) Bound Service Replacement incorrect
[ https://issues.apache.org/jira/browse/FELIX-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-366: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Bound Service Replacement incorrect > --- > > Key: FELIX-366 > URL: https://issues.apache.org/jira/browse/FELIX-366 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > Currently SCR implements incorrect bound service replacement for references > of unary cardinality: Instead of first binding the new (replacement) service > and then unbinding the old (outgoing) service, the old service is first > unbound and then the replacement bound. This violates the specification in > section 112.5.10, Bound Service Replacement, of the Declarative Services > Specification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-425) DependencyManager does not correctly handle service counting
[ https://issues.apache.org/jira/browse/FELIX-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-425: Fix Version/s: scr-1.0.0 > DependencyManager does not correctly handle service counting > > > Key: FELIX-425 > URL: https://issues.apache.org/jira/browse/FELIX-425 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > Whenever a referenced service is added to or removed from the framework, the > DependencyManager.serviceAdded or serviceRemoved method is called > respectively. These methods maintain a counter of services registered in the > system matching the selection criteria (service interface and target filter) : >- when a service added whose ServiceReference does not match the target > filter (if any) is ignored. Otherwise the internal >counter is incremented regardless of whether the service will actually > be bound or not >- when a service is removed it is ignored, if it is not bound. The > internal counter is only decremented if the service is bound. > The problem is, that upon service removal the counter should be decremented > if the service matches the target filter regardless of whether the service > bound or not. Otherwise the counter might not be decremented and the > dependency may be marked satisfied even though no (or not enough) service(s) > are available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-264) Update pom to use new bundle plugin
[ https://issues.apache.org/jira/browse/FELIX-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-264: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Update pom to use new bundle plugin > --- > > Key: FELIX-264 > URL: https://issues.apache.org/jira/browse/FELIX-264 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > After adding support for Configuration Admin Service with FELIX-258 the > pom.xml must be adapted to also import new packages. Along this way, it would > probably make sense to migrate to use the new bundle plugin and to export the > org.osgi.service.component package from the scr bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-128) Implementing missing ComponentContext methods
[ https://issues.apache.org/jira/browse/FELIX-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-128: Fix Version/s: scr-1.0.0 > Implementing missing ComponentContext methods > - > > Key: FELIX-128 > URL: https://issues.apache.org/jira/browse/FELIX-128 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: org.apache.felix.scr project, Rev. 438041 >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: ComponentContext_fm20060829.diff > > > The scr project currently misses methods for the ComponentContext > implementation, namely the getUsingBundle() and service location methods. I > assume, these methods are fairly easy to implement: > (1) getUsingBundle: set a private field of the ComponentContextImpl to the > requiring bundle if created from a service factory. Otherwise this field > remains null. > (2) service location: find the DependencyManager whose metadata has the > requested name and select a service. > Attached is a patch, which implements this functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-109) java.lang.ClassCastException when the component descriptor contains elements
[ https://issues.apache.org/jira/browse/FELIX-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-109: Fix Version/s: scr-1.0.0 > java.lang.ClassCastException when the component descriptor contains > elements > --- > > Key: FELIX-109 > URL: https://issues.apache.org/jira/browse/FELIX-109 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: WinXP, Sun JDK 1.5 >Reporter: Didier DONSEZ >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: ComponentMetadata_fm_20060830.diff > > > There is a bug in org.apache.felix.scr > when the component descriptor contains elements > java.lang.ClassCastException: java.lang.String > at > org.apache.felix.scr.ComponentMetadata.validate(ComponentMetadata.java:254) > at org.apache.felix.scr.XmlHandler.endElement(XmlHandler.java:175) > at > org.apache.felix.scr.parser.KXml2SAXParser.parseXML(KXml2SAXParser.java:72) > at > org.apache.felix.scr.GenericActivator.initialize(GenericActivator.java:148) > at > org.apache.felix.scr.GenericActivator.start(GenericActivator.java:99) > at org.apache.felix.framework.Felix._startBundle(Felix.java:1349) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1283) > at > org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:765) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:206) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-385) ReferenceMetadata.setTarget includes the interface name in the target filter
[ https://issues.apache.org/jira/browse/FELIX-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-385: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > ReferenceMetadata.setTarget includes the interface name in the target filter > > > Key: FELIX-385 > URL: https://issues.apache.org/jira/browse/FELIX-385 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > When the target filter is set on a reference metadata, the interface name is > included as a filter term. This is not required as the service access > primarily uses the interface directly and service listener registration adds > the interface to the target filter, if existing, anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-144) Change all headers and remove copyright notices
[ https://issues.apache.org/jira/browse/FELIX-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-144: Fix Version/s: (was: felix-0.8.0) scr-1.0.0 > Change all headers and remove copyright notices > --- > > Key: FELIX-144 > URL: https://issues.apache.org/jira/browse/FELIX-144 > Project: Felix > Issue Type: Task > Components: Bundle Repository (OBR), Conditional Permission Admin, > Configuration Admin, Declarative Services (SCR), Dependency Manager, Device > Access, Event Admin, Framework, HTTP Service, Initial Provisioning, > Installer, IO Connector Service, iPOJO, JMood, Log Service, Manifest > Generator (mangen), Maven Bundle Plugin, Metatype Service, MOSGi, Permission > Admin, Preferences Service, Service Binder, UPnP Subproject, User Admin, Wire > Admin >Affects Versions: felix-0.8.0 >Reporter: Richard S. Hall >Assignee: Richard S. Hall >Priority: Blocker > Fix For: scr-1.0.0 > > > The headers in all of our files are incorrect and should conform to > http://www.apache.org/legal/src-headers.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-132) Integrate SCR with Felix
[ https://issues.apache.org/jira/browse/FELIX-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-132: Fix Version/s: scr-1.0.0 > Integrate SCR with Felix > > > Key: FELIX-132 > URL: https://issues.apache.org/jira/browse/FELIX-132 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: org.apache.felix.scr project, Rev. 427625 >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: SCR_Activator_fm20060830.diff, > SCR_Activator_fm20060906.diff > > > Currently any bundle wanting to contribute components has to implement an > Activator extending the GenericActivator (or refer to the GenericActivator in > the Manifest.MF. Additionally start/stop semantics of the SCR bundle are not > implemented. > Attached is a patch, which enhances the current Activator class as follows: >* On start load components of active bundles >* On stop unload all loaded components >* listen for bundle state changes to load/unload components: >* on BundleEvent.STARTED: Components are loaded >* on BundleEvent.STOPPING: Components are unloaded > The BundleContext instance needed to load the Components is retrieved using > the BundleImpl.getContext() method, which is accessed through reflection on > the bundle instance. > As a consequence of this patch, the GenericActivator class may be rebuilt > into a proper component loader and need not be used as an activator for > component bundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-489) Intermittent deadlock while using declarative services in Tuscany
[ https://issues.apache.org/jira/browse/FELIX-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-489: Fix Version/s: scr-1.0.0 > Intermittent deadlock while using declarative services in Tuscany > > > Key: FELIX-489 > URL: https://issues.apache.org/jira/browse/FELIX-489 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: felix-1.0.0 >Reporter: Rajini Sivaram >Assignee: Karl Pauls > Fix For: scr-1.0.0 > > > One of my tests using declarative services hangs intermittently. The stack > trace from a debugger shows two threads waiting for locks owned by the other. > I am using Felix framework 1.0.3 and SCR 1.0.0. The call from the main thread > to getService is triggered by Tuscany - I am not sure if there are times when > it shouldn't call bundleContext.getService. But the order of locking in the > two threads are different leading to the deadlock - is it something that > could be fixed? The main thread owns the ServiceRegistry lock and is waiting > for the lock on ServiceFactoryComponentManager, while the configuration > updater owns the ServiceFactoryComponentManager lock and is waiting for the > ServiceRegistry lock. > > > Thread [main] (Suspended) >ServiceFactoryComponentManager.getService(Bundle, ServiceRegistration) > line: 111 >ServiceRegistrationImpl.getFactoryUnchecked(Bundle) line: 245 >ServiceRegistrationImpl.getService(Bundle) line: 179 >ServiceRegistry.getService(Bundle, ServiceReference) line: 238 >Felix.getService(Bundle, ServiceReference) line: 2835 >BundleContextImpl.getService(ServiceReference) line: 417 >.. (Tuscany) > > Thread [Configuration Updater] (Suspended) >ServiceRegistry.unregisterService(Bundle, ServiceRegistration) line: 78 >ServiceRegistrationImpl.unregister() line: 99 > > ServiceFactoryComponentManager(AbstractComponentManager).unregisterComponentService() > line: 610 > > ServiceFactoryComponentManager(AbstractComponentManager).deactivateInternal() > line: 464 >ServiceFactoryComponentManager(AbstractComponentManager).reactivate() > line: 142 > > ServiceFactoryComponentManager(ImmediateComponentManager).reconfigure(Dictionary) > line: 399 >ImmediateComponentManager$1.updated(Dictionary) line: 90 >ConfigurationManager$ManagedServiceUpdate.run() line: 863 >UpdateThread.run() line: 89 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-284) Add Management API
[ https://issues.apache.org/jira/browse/FELIX-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-284: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Add Management API > -- > > Key: FELIX-284 > URL: https://issues.apache.org/jira/browse/FELIX-284 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > Attachments: FELIX-284.tgz > > > Currently, it is not directly visible, what state a component has and what > references are satisified. > The intent is to define a simple API - along the lines of the ServiceBinder > architecure interfaces. > These interfaces may then be used to implement integrations into management > applications such as the Felix shell or JMX. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-254) Add support for property values in element body
[ https://issues.apache.org/jira/browse/FELIX-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-254: Fix Version/s: scr-1.0.0 > Add support for property values in element body > -- > > Key: FELIX-254 > URL: https://issues.apache.org/jira/browse/FELIX-254 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: FELIX-254.diff > > > Will attach a patch for XmlHandler and PropertyMetaData adding support for > multiple property values contained in the element body. > (Section 112.4.5, element body) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-131) Fix method lookup and implement enableComponet/disableComponent
[ https://issues.apache.org/jira/browse/FELIX-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-131: Fix Version/s: scr-1.0.0 > Fix method lookup and implement enableComponet/disableComponent > --- > > Key: FELIX-131 > URL: https://issues.apache.org/jira/browse/FELIX-131 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: org.apache.felix.scr project, Rev. 427625 >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: SCR_fm20060830.diff > > > Attached is a patch, which provides fixes to the method lookup mechanism as > well as a tentative implementation of the ComponentContext.enableComponent > and ComponentContext.disableComponent methods. > (1) Method Lookup > The Spec says, that methods activate and deactivate as well as the bind and > unbind methods must be public or protected methods. The currently used > mechanism of using the Class.getMethod(String name, Class[] parameterTypes) > method only returns public methods. To also find protected methods, the > Class.getDeclaredMethod(String name, Class[] parameterTypes) method must be > used. But this method must be called on the class itself as well as all super > classes. > Additionally, any protected method found must be made accessible by calling > the Method.setAccessible(boolean) method. > To implement this common behaviour, I added a > ComponentManagerImpl.getMethod(Class calzz, String name, Class[] > parameterTypes) which tries to find a public or protected method of the given > name with required parameters from the class hierarchy of clazz. > Another minor fix is included with the DependencyManager.getBindingMethod > method: The third case - looking for method wich takes an assignement > compatible parameter - only checked for the parameter cardinality and type > but not for the method name. Besides also supporting protected methods by > walking the class hierarchy using the Class.getDeclaredMethods() method, I > added a check for the method name. > (2) enableComponent/disableComponent > These methods of the ComponentContext interface have not been implented. I > added implementation in that the GenericActivator provides these > implementations, as all registered components or the bundle are known there. > Actual enabling and disabling is done in a separate thread as stipulated by > the spec. > A note on enabling: A component may be initially disabled, in which case the > GenericActivator.initiliaze() class has created the componnent but not > registered it. The fix is, to always register the component regardless of > whether it is a factory component and whether it is enabled or not. > A note on disabling: Currently, the GenericAdapter.disableComponent method > calls the ComponentManager.dispose() method. In my opinion, this is not > entirely correct, as (1) the preconditions regarding component state might be > wrong, (2) the final state of the component (DESTROYED) is probably wrong > (shouldn't it be CREATED, but what would be the transient state - DISABLING > or UNCREATING ?) and (3) at the end the dispose() method clears the > m_activator field, which would actually be required again if re-enabling the > component. > PS: This patch does not include the patch posted for issue FELIX-128 but also > touches ComponentManagerImpl class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-356) DependencyManager.bind may bind to null and does not correctly check for success
[ https://issues.apache.org/jira/browse/FELIX-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-356: Fix Version/s: scr-1.0.0 > DependencyManager.bind may bind to null and does not correctly check for > success > > > Key: FELIX-356 > URL: https://issues.apache.org/jira/browse/FELIX-356 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > In an active environment a service to be bound may disappear between the > access to the service reference and the acquiry of the service itself. As a > consequence the DependencyManager.bind(Object) method may call the > component's bind method with a null instance, which is not expected. > The DependencyManager.bind method should check whether the service still > exists before calling the component's bind method. > As a consequence the checks whether at least one service could be bound for > mandatory references and that at most one service is bound for singular > references have to be rethought: Currently binding fails if the first service > reference cannot be bound for singular references. In such situations the > binding also fails if calling the bind method fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-259) Add support for factory components
[ https://issues.apache.org/jira/browse/FELIX-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-259: Fix Version/s: scr-1.0.0 > Add support for factory components > -- > > Key: FELIX-259 > URL: https://issues.apache.org/jira/browse/FELIX-259 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > Attachments: FELIX-259.diff, FELIX-259_2.diff > > > Implement support for Factory Components currently missing in the Felix scr > project. > I am working on this support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-105) SCR component/reference/cardinality never used
[ https://issues.apache.org/jira/browse/FELIX-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-105: Fix Version/s: scr-1.0.0 > SCR component/reference/cardinality never used > -- > > Key: FELIX-105 > URL: https://issues.apache.org/jira/browse/FELIX-105 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Guillaume Sauthier >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: scr-cardinality.patch > > > In Felix SCR, the [EMAIL PROTECTED] attribute is not used : > Tests (isOptionnal, isMultiple, ...) are done on m_cardinality which is not > assigned with the value from the XML -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-268) SCR module in the pom.xml
[ https://issues.apache.org/jira/browse/FELIX-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-268: Fix Version/s: scr-1.0.0 > SCR module in the pom.xml > - > > Key: FELIX-268 > URL: https://issues.apache.org/jira/browse/FELIX-268 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Clement Escoffier >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: scr_pom.patch > > > The SCR module needs to move inside the general pom file to avoid compilation > failure. Indeed, by changing the plugin, the SCR module needs to be move from > packaging-osgi-bundle profile to the the packaging-bundle profile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-243) Add support for ServiceFactory components
[ https://issues.apache.org/jira/browse/FELIX-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-243: Fix Version/s: scr-1.0.0 > Add support for ServiceFactory components > - > > Key: FELIX-243 > URL: https://issues.apache.org/jira/browse/FELIX-243 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Environment: Felix SCR trunk Rev. 515074 >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: FELIX-243.diff, FELIX-243_2.diff > > > Currently the SCR bundle only supports delayed components but not > ServiceFactory components. That is the servicefactory attribute of the > element is in fact ignored. Another issue is, that for each bundle > using a delayed component which is NOT a ServiceFactory a new instance of the > component is created. > Attaching a patch which solves the issues as follows: >* Creates a new inner DelayedServiceFactoryServiceFactory (name is more > functional than beautiful) class which supports for ServiceFactory > components. Each call to the getService method creates a new instance of the > component. The m_implementationObject is never set in this case. The > ComponentContext used to call the activate method is kept in an map to use > the same ComponentContext to call deactivate when the service is released > through the ungetService method. >* Modified DelayedComponentServiceFactory.getService method to return the > m_implementationObject if not null. Otherwise the m_implementationObject is > created, bound, activated and returned. The ungetService method is just > enhanced with a comment indicating that the delayed component is only > deactivated when the component is deactivated. The ComponentContext created > by the getService method has the owner bundle field set to null as there is > only really a single Component instance shared by all bundles. >* Modified the invokeBindMethod and invokeUnbindMethods to take the object > on which to call the method as a parameter. This accomodates for the > DelayedServiceFactoryServiceFactory which never sets the > m_implementationObject field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-341) Intermittent exception during Felix shutdown
[
https://issues.apache.org/jira/browse/FELIX-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-341:
Fix Version/s: (was: felix-1.0.0)
scr-1.0.0
> Intermittent exception during Felix shutdown
>
>
> Key: FELIX-341
> URL: https://issues.apache.org/jira/browse/FELIX-341
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: felix-1.0.0
>Reporter: Rajini Sivaram
>Assignee: Felix Meschberger
> Fix For: scr-1.0.0
>
>
> One of my testcases intermittently throws an exception during shutdown. I
> have managed to recreate the exception under a debugger, and it shows two
> threads trying to unregister the same service. The test fails only when
> declarative services are used. I am using Felix 1.0.0 framework and the
> latest snapshot of SCR. The test uses multiple versions of a bundle, but I am
> not sure if that has anything to do with the exception.
>
> The exception thrown is:
>
> --- Exception with component : Unexpected problem executing task ---
> java.lang.IllegalStateException: Service already unregistered.
> at org.apache.felix.framework.ServiceRegistrationImpl.unregister
> (ServiceRegistrationImpl.java:105)
> at
> org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503)
> at org.apache.felix.scr.AbstractComponentManager.deactivateInternal
> (AbstractComponentManager.java:369)
> at
> org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55)
> at
> org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java
> :176)
> at
> org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81)
>
> Here is the stack trace of the two threads under the debugger (both are using
> the same object):
>
> Thread [FelixStartLevel] (Suspended (breakpoint at line 97 in
> ServiceRegistrationImpl))
> ServiceRegistrationImpl.unregister() line: 97
> ServiceRegistry.unregisterServices (Bundle) line: 119
> Felix._stopBundle(FelixBundle, boolean) line: 1946
> Felix.stopBundle(FelixBundle, boolean) line: 1866
> Felix.setFrameworkStartLevel (int) line: 1080
> StartLevelImpl.run() line: 258
> Thread.run() line: 803
> Thread [SCR Component Actor] (Suspended (breakpoint at line
> 97 in ServiceRegistrationImpl))
> ServiceRegistrationImpl.unregister() line: 97
>
> ImmediateComponentManager(AbstractComponentManager).unregisterComponentService()
> line: 503
>
> ImmediateComponentManager(AbstractComponentManager).deactivateInternal()
> line: 369
>
> AbstractComponentManager.access$200(AbstractComponentManager) line: 55
> AbstractComponentManager$3.run() line: 176
> ComponentActorThread.run() line: 81
>
>
> The exception thrown is the IllegalStateException from
> public void unregister()
> {
> if (m_svcObj != null)
> {
> m_registry.unregisterService(m_bundle, this);
> m_svcObj = null;
> m_factory = null;
> }
> else
> {
> throw new IllegalStateException("Service already unregistered.");
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-374) Register ManagedService on behalf of components to receive Configuration
[ https://issues.apache.org/jira/browse/FELIX-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-374: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Register ManagedService on behalf of components to receive Configuration > > > Key: FELIX-374 > URL: https://issues.apache.org/jira/browse/FELIX-374 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > Currently the SCR calls the ConfigurationAdmin.getConfiguration(servicePid) > method on behalf of components to retrieve configuration. If no such > configuration exists, this call causes the creation of such configuration > which is empty and may never ever be updated in case the component is not > prepared to take Configuration from the Configuration Admin (perhaps there is > nothing configurable in the component). > The SCR should instead register a ManagedService on behalf of the component > to receive configuration from the Configuration Admin as configuration > becomes available. A good side effect of this is, that configuration provided > to the component in this way has always passed the Configuration Admin > plugins, which is not the case currently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-364) 0..1 dynamic service reference does not bind properly.
[ https://issues.apache.org/jira/browse/FELIX-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-364: Fix Version/s: scr-1.0.0 > 0..1 dynamic service reference does not bind properly. > -- > > Key: FELIX-364 > URL: https://issues.apache.org/jira/browse/FELIX-364 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: Java 1.6 >Reporter: I-Ann Chen >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > Attachments: patch.txt > > > There are 2 parts to the issue. Both are with a component with a reference to > a service where cardinality=0..1 and policy=dynamic. > 1. If the bundle providing the service is stopped (without another bundle > providing the same service) and restarted, the service is not re-bound to the > component. > 2. If the service is started after the component referencing it, then the > service is never bound to the component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-384) Possible deadlock on framework startlevel change
[ https://issues.apache.org/jira/browse/FELIX-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-384: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Possible deadlock on framework startlevel change > > > Key: FELIX-384 > URL: https://issues.apache.org/jira/browse/FELIX-384 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger >Priority: Critical > Fix For: scr-1.0.0 > > > Felix SCR uses java synchronization on component manager instances to prevent > synchronous execution of certain actions like activation and deactivation. In > concert with the locking implemented by the Felix framework, deadlocks may > occurr in certain situations. > For example: If the framework has been started but the SCR Activator queue > still has a deadlock and the framework is instructed to shutdown. > The start level service will now stop bundles in the FelixStartLevel thread. > At one point in time Bundle X will be stopped and the framework holds the > bundle lock while stopping the bundle. Stopping the bundle causes a > synchronous STOPPING event being handled by the SCR, which causes immediate > deactivation of all components of the bundle. This causes the > AbstractComponentManager.deactivateInternal method to be called which is > synchronized on the instance. > At the same time, the components of Bundle X may still be scheduled for > activation in the SCR Activator queue handled by the SCR Component Actor > thread. This thread may be activating a component of Bundle X trying to > register the component as a service in the > AbstractComponentManager.activateInternal method (synchronized on the > instance). Registering the service tries to acquire the bundle lock first. > The result is a deadlock between the FelixStartLevel thread (holding the > bundle lock and waiting for the component manager lock) and the SCR Component > Actor thread (holding the component lock and waiting for the bundle lock). > While this is probably a seldom situation, it must be prevent from happening > nevertheless. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-140) Drop GenericActivator from SCR
[ https://issues.apache.org/jira/browse/FELIX-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-140: Fix Version/s: scr-1.0.0 > Drop GenericActivator from SCR > -- > > Key: FELIX-140 > URL: https://issues.apache.org/jira/browse/FELIX-140 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: Felix SVN Rev. 440841 >Reporter: Felix Meschberger >Assignee: Richard S. Hall > Fix For: scr-1.0.0 > > Attachments: DeclarativeServices_140_fm_20060916.patch > > > After applying a series of patches to move SCR closer to specification > compliance, the GenericActivator should now be transferred in a container > class of per-bundle components. > I am working on a patch for this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-258) Support Configuration Admin configuration
[ https://issues.apache.org/jira/browse/FELIX-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-258: Fix Version/s: scr-1.0.0 > Support Configuration Admin configuration > - > > Key: FELIX-258 > URL: https://issues.apache.org/jira/browse/FELIX-258 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > Attachments: FELIX-258.diff > > > 112.6, Component Properties, and 112.7, Deployment, state that the > Configuration Admin service must be queried for configuration properties to > provide to the ComponentContext. > I will attach a patch, which provides this integration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-337) Immediate components are registered as delayed
[ https://issues.apache.org/jira/browse/FELIX-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-337: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Immediate components are registered as delayed > -- > > Key: FELIX-337 > URL: https://issues.apache.org/jira/browse/FELIX-337 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0, felix-1.0.0 >Reporter: Jeremy Volkman >Assignee: Felix Meschberger >Priority: Critical > Fix For: scr-1.0.0 > > > DS doesn't properly detect implicit immediate components (components with no > "immediate" attribute and no service registrations). > From the spec, section 112.2.2: > "A component is an immediate component if it is not a factory > component and either does not specify a service or specifies a service > and the immediate attribute of the component element set to true." > Currently, a component defaults to 'immediate="false"', and the only way to > change this value is to explicitly define it in the component description. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-368) Service binding odities if (un)bind methods take ServiceReferences
[ https://issues.apache.org/jira/browse/FELIX-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-368: Fix Version/s: scr-1.0.0 > Service binding odities if (un)bind methods take ServiceReferences > -- > > Key: FELIX-368 > URL: https://issues.apache.org/jira/browse/FELIX-368 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > When a service is bound by calling the configured bind method, the service > may be given as the service itself or as its ServiceReference. The intent is > to be able to first inspect the reference properties before actually getting > the service or to delay activation of a service > component until the service is really needed. > Currently, the service object is always accessed before calling the bind > method regardless of whether the service object is really needed or not. > Likewise for the unbind method, which always requires the service object > regardless of whether it is used to call the unbind method. > In addition, the handling of the arguments of the bind and unbind methods > using the m_bindUsesServiceReference field is wrong if the on of the methods > takes the service instance while the other takes a ServiceReference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-110) completion of the current Felix SCR implementation to take into account components elements
[ https://issues.apache.org/jira/browse/FELIX-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-110: Fix Version/s: scr-1.0.0 > completion of the current Felix SCR implementation to take into account > components elements > > > Key: FELIX-110 > URL: https://issues.apache.org/jira/browse/FELIX-110 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: WinXP, Sun JDK 5.0 >Reporter: Didier DONSEZ > Fix For: scr-1.0.0 > > Attachments: patch.zip > > > I completed the current Felix SCR implementation to take into > account elements. > The modified files are in attachement and the modified source sections > are bracketed by // CHANGED lines -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-392) Better handle unexpected issues when trying to get a activation or binding method by reflection
[ https://issues.apache.org/jira/browse/FELIX-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-392: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Better handle unexpected issues when trying to get a activation or binding > method by reflection > --- > > Key: FELIX-392 > URL: https://issues.apache.org/jira/browse/FELIX-392 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > Sometimes it may happen, that trying to get an activation (activate, > deactive) or binding (bind, unbind) method throws an unexpected Throwable. > For example in one use case, when updating a bundle (before refreshing > packages), trying to get a bind method of one the new components throws a > LinkageError which is just logged but may leave the component in an undefined > half-started state. > The AbstractComponentManager.getMethod method should catch any throwables and > encapsulate them such that this situation may be handled properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-18) Implement Declarative Services
[ https://issues.apache.org/jira/browse/FELIX-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-18: --- Fix Version/s: scr-1.0.0 > Implement Declarative Services > -- > > Key: FELIX-18 > URL: https://issues.apache.org/jira/browse/FELIX-18 > Project: Felix > Issue Type: New Feature > Components: Declarative Services (SCR), Specification compliance >Reporter: Richard S. Hall > Fix For: scr-1.0.0 > > > See section 112 in the OSGi R4 Service Compendium for a full description of > the task. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-279) Concurrency Issues when enabling components
[ https://issues.apache.org/jira/browse/FELIX-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-279: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Concurrency Issues when enabling components > --- > > Key: FELIX-279 > URL: https://issues.apache.org/jira/browse/FELIX-279 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > When bundles are started and their components registered, enabled and > activated and configuration is provided to them, timing issues may occurr, > such that in the end some components may not be started at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-112) activate() calls do not match with deactivate() calls for a delayed component (immediate="false") and service instances are multiple (although there is no factory)
[ https://issues.apache.org/jira/browse/FELIX-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-112: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > activate() calls do not match with deactivate() calls for a delayed component > (immediate="false") and service instances are multiple (although there is no > factory) > --- > > Key: FELIX-112 > URL: https://issues.apache.org/jira/browse/FELIX-112 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: felix-0.8.0 > Environment: WinXP, Sun JDK 5.0 >Reporter: Didier DONSEZ > Fix For: scr-1.0.0 > > > activate() calls do not match with deactivate() calls for a delayed component > (immediate="false") > and service instances are multiple (although there is no factory) > See the first trace. > If the component is immediate (immediate="false"), the behavior is correct : > see the second trace. > The instance is the same singleton for the two clients. > Didier > > TRACE WITH immediate="false" > > > > >class="fr.imag.adele.bundle.helloservicescr.impl.HelloServiceImpl"/> > > > > > > -> ps > START LEVEL 1 >ID State Level Name > [ 0] [Active ] [0] System Bundle (0.8.0.SNAPSHOT) > [ 1] [Active ] [1] ShellService (0.8.0.SNAPSHOT) > [ 2] [Active ] [1] ShellTUI (0.8.0.SNAPSHOT) > [ 3] [Active ] [1] BundleRepository (0.8.0.SNAPSHOT) > [ 4] [Active ] [1] servlet (2.1) > [ 5] [Active ] [1] osgi.compendium (4) > [ 6] [Active ] [1] Service Component Runtime (0.8.0.SNAPSHOT) > [ 7] [Resolved ] [1] Hello Service Specification 1.2 (0.3.0) > [ 8] [Resolved ] [1] Hello Command (with SCR) (0.1.0) > [ 9] [Resolved ] [1] Hello Service Impl 1.1 SCR (0.1.0) > [ 10] [Resolved ] [1] Hello Requester Impl 1.1 SCR (0.1.0) > -> start 9 > --- [Hello.Service] Validated and registered component > --- [Hello.Service] ManagerFactory.createManager > --- [Hello.Service] Enabling component > --- [Hello.Service] State transition : CREATING -> CREATED > --- [Hello.Service] State transition : CREATED -> VALIDATING > --- [Hello.Service] State transition : VALIDATING -> VALID > --- [Hello.Service] registering services > -> start 8 > --- [Hello.Cmd] Validated and registered component > --- [Hello.Cmd] ManagerFactory.createManager > --- [Hello.Cmd] Enabling component > --- [Hello.Cmd] State transition : CREATING -> CREATED > --- [Hello.Cmd] State transition : CREATED -> VALIDATING > --- [Hello.Cmd] State transition : VALIDATING -> VALID > --- [Hello.Cmd] registering services > --- [Hello.Cmd] DelayedComponentServiceFactory.getService() > --- [Hello.Service] DelayedComponentServiceFactory.getService() > (Bundle #9) call activate > (Bundle #8) call activate > -> hello Didier > Hello Didier (from [EMAIL PROTECTED]) !! > -> stop 8 > --- [Hello.Cmd] State transition : VALID -> DESTROYING > --- [Hello.Cmd] unregistering the services > (Bundle #8) call deactivate > --- [Hello.Cmd] getting unbind: unbindHelloService > --- [Hello.Cmd] State transition : DESTROYING -> DESTROYED > -> start 8 > --- [Hello.Cmd] Validated and registered component > --- [Hello.Cmd] ManagerFactory.createManager > --- [Hello.Cmd] Enabling component > --- [Hello.Cmd] State transition : CREATING -> CREATED > --- [Hello.Cmd] State transition : CREATED -> VALIDATING > --- [Hello.Cmd] State transition : VALIDATING -> VALID > --- [Hello.Cmd] registering services > --- [Hello.Cmd] DelayedComponentServiceFactory.getService() > --- [Hello.Service] DelayedComponentServiceFactory.getService() > (Bundle #9) call activate > (Bundle #8) call activate > -> hello Rick > Hello Rick (from [EMAIL PROTECTED]) !! > -> start 10 > --- [Hello.Requester.11] Validated and registered component > --- [Hello.Requester.11] ManagerFactory.createManager > --- [Hello.Requester.11] Enabling component > --- [Hello.Requester.11] State transition : CREATING -> CREATED > --- [Hello.Requester.11] State transition : CREATED -> VALIDATING > --- [Hello.Service] DelayedComponentServiceFactory.getService() > (Bundle #9) call activate > (Bundle #10) call activate > --- [Hello.Requester.11] State transition : VALIDATING -> VALID > -> (Bundle #10) 1:[EMAIL PROTECTED] says ' > Hello World !! > ' > (Bundle #10) 2:[EMAIL PROTECTED] says ' > Hello World !! > ' > (Bundle #10) 3:[EMAIL PROTECTED] says ' > Hello World !! > ' > (Bundle #10) 4:[EMAIL PROTECTED] says ' > Hello World !! > ' > (Bundle #10) 5:[EMAIL PROTECTED] says ' > Hello World !! > ' > hello Ric
[jira] Updated: (FELIX-277) Improve SCR packaging to make it simpler to deploy and use
[ https://issues.apache.org/jira/browse/FELIX-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-277: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Improve SCR packaging to make it simpler to deploy and use > -- > > Key: FELIX-277 > URL: https://issues.apache.org/jira/browse/FELIX-277 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Richard S. Hall >Assignee: Felix Meschberger >Priority: Minor > Fix For: scr-1.0.0 > > > To me, it seems that it would be more usable if we made > "org.osgi.service.log" a dynamically imported package (or optional), since it > isn't really required. > Also, I think we could suck in the Service Tracker package using > , so that we don't have a dependency on compendium, which > has a dependency on servlet... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-387) Fix support for reference service target properties
[ https://issues.apache.org/jira/browse/FELIX-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-387: Fix Version/s: (was: felix-1.0.0) scr-1.0.0 > Fix support for reference service target properties > --- > > Key: FELIX-387 > URL: https://issues.apache.org/jira/browse/FELIX-387 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.0.0 > > > Currently Felix SCR does not reflect the service reference target settings in > the component properties and on the other hand setting such target properties > has no influence on the service dependencies. > Reference target properties are defined in Section 112.6, Component > Properties, with respect to reflect the reference target setting as > properties and 112.7, Deployment, with respect to overwriting the reference > target with configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OBR in the web console
On Fri, May 30, 2008 at 8:10 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Definitely yes ! I had to remove it because it used functionality not > available any more. I have to rewrite it to directly go to the OBR API. Sounds good. /niklas
[jira] Closed: (FELIX-368) Service binding odities if (un)bind methods take ServiceReferences
[ https://issues.apache.org/jira/browse/FELIX-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-368. --- This may be closed by now. > Service binding odities if (un)bind methods take ServiceReferences > -- > > Key: FELIX-368 > URL: https://issues.apache.org/jira/browse/FELIX-368 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > When a service is bound by calling the configured bind method, the service > may be given as the service itself or as its ServiceReference. The intent is > to be able to first inspect the reference properties before actually getting > the service or to delay activation of a service > component until the service is really needed. > Currently, the service object is always accessed before calling the bind > method regardless of whether the service object is really needed or not. > Likewise for the unbind method, which always requires the service object > regardless of whether it is used to call the unbind method. > In addition, the handling of the arguments of the bind and unbind methods > using the m_bindUsesServiceReference field is wrong if the on of the methods > takes the service instance while the other takes a ServiceReference. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OBR in the web console
Hi Niklas, Am Freitag, den 30.05.2008, 15:42 +0200 schrieb Niklas Gustavsson: > Hi > > What's the current status of the OBR support in the web console? From > what I can see, the support was removed a little while back. Any plans > for reintroducing it? Definitely yes ! I had to remove it because it used functionality not available any more. I have to rewrite it to directly go to the OBR API. Regards Felix
[jira] Updated: (FELIX-580) Allows maven-bunde-plugin to generate a repository file outide a maven repository with absolute url
[ https://issues.apache.org/jira/browse/FELIX-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-580: Attachment: obr-patch.patch The attached patch allows the creation of OBRs with absolute URL on bundle file. The OBR file is not necessary deployed on a maven repository. The contribution is twofold: The deploy goal can take an prefix attribute used to compute absolute URLs. This allows deploying an OBR file with pointing on bundles located on another server (the configured deployment repository and the altDeploymentRepository attribute are generally used to deploy the OBR file, but I add an url attribute to differentiate the two potential locations). If the prefix is not specified, the process is executed normally and the url attribute is ignored. The deploy-file goal checks if a project is attached to the build. If it is, it uses this project. This allows simplifying the usage (no more need to specify the pom file and the obr.xml file). The url attribute (giving information to upload the repository file) supports the maven syntax too. Absolute URLs are computed if the bundleURL (that can be an absolute url) attribute and file attribute are not specified. In this case, the prefix attribute is used to computes the URL. This attribute has a default value pointing on repo1.maven.org/maven2. > Allows maven-bunde-plugin to generate a repository file outide a maven > repository with absolute url > --- > > Key: FELIX-580 > URL: https://issues.apache.org/jira/browse/FELIX-580 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Clement Escoffier > Attachments: obr-patch.patch > > > The actual maven-bunde-plugin:deploy goal generates OBR repository files but > this file is necessary at the root of a maven repository where the artifacts > are deployed. So, creating a new OBR often requires to duplicate bundle > files. The deploy-file goal can generate this kind of OBR (with absolute URL > and no duplication) but does not support multi-module project and is a pain > to configure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-580) Allows maven-bunde-plugin to generate a repository file outide a maven repository with absolute url
Allows maven-bunde-plugin to generate a repository file outide a maven repository with absolute url --- Key: FELIX-580 URL: https://issues.apache.org/jira/browse/FELIX-580 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Clement Escoffier The actual maven-bunde-plugin:deploy goal generates OBR repository files but this file is necessary at the root of a maven repository where the artifacts are deployed. So, creating a new OBR often requires to duplicate bundle files. The deploy-file goal can generate this kind of OBR (with absolute URL and no duplication) but does not support multi-module project and is a pain to configure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [Vote] Release iPOJO 0.8.0
> -Message d'origine- > De : Karl Pauls [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 30 mai 2008 04:16 > À : dev@felix.apache.org > Objet : Re: [Vote] Release iPOJO 0.8.0 > > > I hate to raise some issues with this release since I know it was a > pain for > > Clement to create and I, as much as anyone, want to get an iPOJO > release out > > the door; however, we might need address some of these issues: > > > > Serious issues > > -- > > > > * org.apache.felix.ipojo.ant embeds ObjectWeb code, but nothing in > > NOTICE and no license. > > * org.apache.felix.ipojo.composite embeds ObjectWeb code, but > > nothing in NOTICE and no license. > > Good catch! > > I'm not sure how this one should be handled. The issue is that they > don't include ObjectWeb source! They artifacts however, embed code > from ObjectWeb (bsd) via a transitive dependency. I agree that at > least the artifacts should add this to their NOTICE. Whether it is a > hard requirement or not I don't know enough about the legal situation > but I would argue we should be strict because I think we should give > credit where credit is due ... > > > * org.apache.felix.ipojo.manipulator doesn't include ASM license > > (perhaps this is not so serious, since it is mentioned in the > > notice file). > > And the license is bsd - I don't think this is a showstopper. > > > * org.apache.felix.ipojo.handler.temporal does not include > > NOTICE/LICENSE files. > > Darn. I missed that one. This is a bad. > > > I think we have to fix the issues (i.e., cut a new release) for at > least org.apache.felix.ipojo.handler.temporal. Furthermore, I would > redo org.apache.felix.ipojo.ant and org.apache.felix.ipojo.composite > unless the general opinion is that this is not that bad. Clement, you > are the release manager on this one, what is your opinion? Hum, I think we have to redo these artifacts, and so cut a 0.8.1 for temporal, ant and composite. I'll do this as soon as I'm back in France (i.e. the next week) Clement > > regards, > > Karl > > > Minor issues > > > > > > * org.apache.felix.ipojo.handler.extender.pattern says it includes > > OSGi software, but it doesn't. > > * org.apache.felix.ipojo.handler.white.board.pattern says it > > includes OSGi software, but it doesn't. > > * Change artifact names for extender and whiteboard handlers; e.g., > > change "org.apache.felix.ipojo.handler.extender.pattern" to > > "org.apache.felix.ipojo.handler.extender" and > > "org.apache.felix.ipojo.handler.white.board.pattern" to > > "org.apache.felix.ipojo.handler.whiteboard". > > * Eliminate bz2 digest files (I know maven generates these, but > just > > delete them to avoid the mess). > > > > > > -> richard > > > > Clement Escoffier wrote: > >> > >> Hi all, > >> > >> > >> I finally cut the first release of the iPOJO framework. > >> > >> > >> Eleven artifacts compose this first release (version 0.8.0): > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.metadata/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.manipulator/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.ant/ > >> > >> > >> http://people.apache.org/~clement/releases/org/apache/felix/maven- > ipojo-plug > >> in/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.arch/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.annotations/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.handler.extender.pattern/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.handler.white.board.pattern/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.handler.temporal/ > >> > >> > >> > http://people.apache.org/~clement/releases/org/apache/felix/org.apache. > felix > >> .ipojo.arch/ > >> > >> > >> The KEYS for verifying the signature is also in the directories, the > >> > >> MD5 and SHA1 files are maven generated. > >> > >> So please check the releases and cast your votes - the vote will be > open > >> for > >> one week (as there several artifacts): > >> > >> > >> [ ] +1 release all > >> > >> [ ] 0 don't care > >> > >> [ ] -1 do NOT release, because > >> > >> > >> Thanks and Regards > >> > >> > >> Clement > >> > >> > >> > > > > > > -- > Karl Pauls > [EMAIL PROTECTED]
[jira] Created: (FELIX-579) NPE in AbstractComponentManager
NPE in AbstractComponentManager --- Key: FELIX-579 URL: https://issues.apache.org/jira/browse/FELIX-579 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.0.0 Reporter: Carsten Ziegeler Sometimes an NPE occurs in the AbstractCompnentManager in line 327 and line 288. It seems that at this point the component manager is already disposed, and the activator is set to null. However the activator is used to log. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
OBR in the web console
Hi What's the current status of the OBR support in the web console? From what I can see, the support was removed a little while back. Any plans for reintroducing it? /niklas
[jira] Commented: (FELIX-528) Support nested folders in fileinstall
[ https://issues.apache.org/jira/browse/FELIX-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601132#action_12601132 ] Toni Menzel commented on FELIX-528: --- Does ANYONE care about this NEW (for felix) component anymore ? I mean, there are some rather trivial patches flying arround Jira in this component now since nearly two months. Since nobody commits or rejects those patches, i don't see chances for bigger enhancements to be added as well. So, it would be nice if somebody could clarify the future of this component in felix ? Otherwise i would suggest other place for this component with lower barriers of entry to make things happen. (?) Toni > Support nested folders in fileinstall > - > > Key: FELIX-528 > URL: https://issues.apache.org/jira/browse/FELIX-528 > Project: Felix > Issue Type: New Feature > Components: File Install >Reporter: Toni Menzel >Priority: Minor > Attachments: FELIX-528.patch > > > Currently FileInstall just supports "flat" jar-Files as bundles in its load > folder. > How about supporting (nested) folders? > This way, you could: > 1. just drop an arbitrary folder structure and fileinstall would install all > bundles inside. > 2. you could enable/disable entire "bundle-sets" with: > 2a. in/move it out of the folder > 2b. rename the folder with prefix that means "unrecognized folder" > Just a thought.. > Toni -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-578) ComponentFactoryImpl.newInstance() must create the component synchronously
ComponentFactoryImpl.newInstance() must create the component synchronously -- Key: FELIX-578 URL: https://issues.apache.org/jira/browse/FELIX-578 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Reporter: Felix Meschberger Assignee: Felix Meschberger The ComponentFactoryImpl.newInstance() method internally calls the AbstractComponentManager.enable() method to enable and activate the newly created component instance. The enable() method in turn schedules the enableInternal() method to run asynchronously. In the context of the ComponentFactoryImpl.newInstance() method this asynchronous enablement is not correct, as the caller expects the ComponentInstance returned from the newInstance to be active. Hence the ComponentFactoryImpl.newInstance() method must be able to enable the created component synchronously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems with URL handler for bundle:// protocol
JIRA raised and patch attached: https://issues.apache.org/jira/browse/FELIX-577 On Fri, May 30, 2008 at 10:09 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 9:48 AM, Richard S. Hall <[EMAIL PROTECTED]> wrote: >> Guillaume Nodet wrote: >>> >>> The "bundle:" protocol URL handler is built in Felix framework, but >>> does not seem to work well for me at the moment. The idea behing this >>> URL handler is to be able to access any resource inside a bundle. The >>> syntax is as following: >>> >>> bundle://[bundleId].[bundleRev]:[classPathId]/[path] >>> >>> where [bundleId] is the id of the bundle, [bundleRev] is the revision >>> of the bundle (when new versions are installed), [classPathId] is the >>> index in the list of jars that make the classpath (internal structure) >>> and [path] is the path of the resource in the bundle. >>> >>> My problem is that [bundleRev] and [classPathId] refer to internal >>> structures and can't be accessed from outside the felix framework. >>> [classPathId] can be set to 0 to look inside the whole classpath >>> entries, but if not specified, the default value of the url port is -1 >>> and an IndexOutOfBounds exception is thrown. >>> >> >> Yes, the exception sounds like a bug that should be fixed. >> >>> Another problem is that [bundleRev] can not be ommitted and (in >>> addition to the parsing having a bug) there is no default value. >>> >> >> Perhaps we should just define the default value to be the current revision. >> >>> I will raise a JIRA and attach a patch to do the following: >>> * if the url port is ommitted (thus defaults to -1), use the same >>> behavior as if 0 was used (search in the whole classpath) >>> >> >> ok >> >>> * fix the revision bundle parsing, which returns the bundle id if >>> none is specified: it will return -1 if the bundle revision was not >>> set >>> >> >> ok >> >>> * fix the look up mechanism so that when no bundle revision is >>> specified, (revision == -1), all bundle revisions will be searched in >>> reverse order (the most recent revision first) >>> >> >> Personally, I would just search the most recent and be done with it, >> otherwise we could end up with situations where we are splitting across >> revisions. > > Sounds good. > >>> The last problem is really difficult to work around as there is no way >>> to find the bundle revision from a client bundle and there is no >>> default value, so the only way to make that work is to specify 0 and >>> expect the bundle to have not been updated (which ovbiously is not a >>> good idea). >>> >> >> While I agree that these are issues that should be addressed, we are really >> talking about special cases here, since you generally shouldn't be trying to >> construct your own bundle resource URL since the URL structure is supposed >> to be opaque and framework dependent. >> >> -> richard > > Yeah, I agree this is felix dependant, but it's nonetheless really handy. > I suppose at some point, I would have to rewrite my own url handler to > handle this > in a less felix specific way. > >>> Feedback welcome. >>> >>> >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Updated: (FELIX-577) Problems with the bundle url protocol
[ https://issues.apache.org/jira/browse/FELIX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-577: -- Attachment: FELIX-577.patch > Problems with the bundle url protocol > - > > Key: FELIX-577 > URL: https://issues.apache.org/jira/browse/FELIX-577 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.0.4 >Reporter: Guillaume Nodet > Fix For: felix-1.0.5 > > Attachments: FELIX-577.patch > > > The "bundle:" protocol URL handler is built in Felix framework, but > does not seem to work well for me at the moment. The idea behing this > URL handler is to be able to access any resource inside a bundle. The > syntax is as following: > bundle://[bundleId].[bundleRev]:[classPathId]/[path] > where [bundleId] is the id of the bundle, [bundleRev] is the revision > of the bundle (when new versions are installed), [classPathId] is the > index in the list of jars that make the classpath (internal structure) > and [path] is the path of the resource in the bundle. > My problem is that [bundleRev] and [classPathId] refer to internal > structures and can't be accessed from outside the felix framework. > [classPathId] can be set to 0 to look inside the whole classpath > entries, but if not specified, the default value of the url port is -1 > and an IndexOutOfBounds exception is thrown. > Another problem is that [bundleRev] can not be ommitted and (in > addition to the parsing having a bug) there is no default value. > I will raise a JIRA and attach a patch to do the following: > * if the url port is ommitted (thus defaults to -1), use the same > behavior as if 0 was used (search in the whole classpath) > * fix the revision bundle parsing, which returns the bundle id if > none is specified: it will return -1 if the bundle revision was not > set > * fix the look up mechanism so that when no bundle revision is > specified, (revision == -1), all bundle revisions will be searched in > reverse order (the most recent revision first) > The last problem is really difficult to work around as there is no way > to find the bundle revision from a client bundle and there is no > default value, so the only way to make that work is to specify 0 and > expect the bundle to have not been updated (which ovbiously is not a > good idea). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-577) Problems with the bundle url protocol
[ https://issues.apache.org/jira/browse/FELIX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601041#action_12601041 ] Richard S. Hall commented on FELIX-577: --- As mentioned on the mailing list, I think it should only search the most recent revision if no revision is specified to avoid situations where resource lookups might be split across revisions. Otherwise, it sounds like a good approach. > Problems with the bundle url protocol > - > > Key: FELIX-577 > URL: https://issues.apache.org/jira/browse/FELIX-577 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.0.4 >Reporter: Guillaume Nodet > Fix For: felix-1.0.5 > > > The "bundle:" protocol URL handler is built in Felix framework, but > does not seem to work well for me at the moment. The idea behing this > URL handler is to be able to access any resource inside a bundle. The > syntax is as following: > bundle://[bundleId].[bundleRev]:[classPathId]/[path] > where [bundleId] is the id of the bundle, [bundleRev] is the revision > of the bundle (when new versions are installed), [classPathId] is the > index in the list of jars that make the classpath (internal structure) > and [path] is the path of the resource in the bundle. > My problem is that [bundleRev] and [classPathId] refer to internal > structures and can't be accessed from outside the felix framework. > [classPathId] can be set to 0 to look inside the whole classpath > entries, but if not specified, the default value of the url port is -1 > and an IndexOutOfBounds exception is thrown. > Another problem is that [bundleRev] can not be ommitted and (in > addition to the parsing having a bug) there is no default value. > I will raise a JIRA and attach a patch to do the following: > * if the url port is ommitted (thus defaults to -1), use the same > behavior as if 0 was used (search in the whole classpath) > * fix the revision bundle parsing, which returns the bundle id if > none is specified: it will return -1 if the bundle revision was not > set > * fix the look up mechanism so that when no bundle revision is > specified, (revision == -1), all bundle revisions will be searched in > reverse order (the most recent revision first) > The last problem is really difficult to work around as there is no way > to find the bundle revision from a client bundle and there is no > default value, so the only way to make that work is to specify 0 and > expect the bundle to have not been updated (which ovbiously is not a > good idea). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Release iPOJO 0.8.0
> I hate to raise some issues with this release since I know it was a pain for > Clement to create and I, as much as anyone, want to get an iPOJO release out > the door; however, we might need address some of these issues: > > Serious issues > -- > > * org.apache.felix.ipojo.ant embeds ObjectWeb code, but nothing in > NOTICE and no license. > * org.apache.felix.ipojo.composite embeds ObjectWeb code, but > nothing in NOTICE and no license. Good catch! I'm not sure how this one should be handled. The issue is that they don't include ObjectWeb source! They artifacts however, embed code from ObjectWeb (bsd) via a transitive dependency. I agree that at least the artifacts should add this to their NOTICE. Whether it is a hard requirement or not I don't know enough about the legal situation but I would argue we should be strict because I think we should give credit where credit is due ... > * org.apache.felix.ipojo.manipulator doesn't include ASM license > (perhaps this is not so serious, since it is mentioned in the > notice file). And the license is bsd - I don't think this is a showstopper. > * org.apache.felix.ipojo.handler.temporal does not include > NOTICE/LICENSE files. Darn. I missed that one. This is a bad. I think we have to fix the issues (i.e., cut a new release) for at least org.apache.felix.ipojo.handler.temporal. Furthermore, I would redo org.apache.felix.ipojo.ant and org.apache.felix.ipojo.composite unless the general opinion is that this is not that bad. Clement, you are the release manager on this one, what is your opinion? regards, Karl > Minor issues > > > * org.apache.felix.ipojo.handler.extender.pattern says it includes > OSGi software, but it doesn't. > * org.apache.felix.ipojo.handler.white.board.pattern says it > includes OSGi software, but it doesn't. > * Change artifact names for extender and whiteboard handlers; e.g., > change "org.apache.felix.ipojo.handler.extender.pattern" to > "org.apache.felix.ipojo.handler.extender" and > "org.apache.felix.ipojo.handler.white.board.pattern" to > "org.apache.felix.ipojo.handler.whiteboard". > * Eliminate bz2 digest files (I know maven generates these, but just > delete them to avoid the mess). > > > -> richard > > Clement Escoffier wrote: >> >> Hi all, >> >> >> I finally cut the first release of the iPOJO framework. >> >> >> Eleven artifacts compose this first release (version 0.8.0): >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.metadata/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.manipulator/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.ant/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/maven-ipojo-plug >> in/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.arch/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.annotations/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.handler.extender.pattern/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.handler.white.board.pattern/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.handler.temporal/ >> >> >> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix >> .ipojo.arch/ >> >> >> The KEYS for verifying the signature is also in the directories, the >> >> MD5 and SHA1 files are maven generated. >> >> So please check the releases and cast your votes - the vote will be open >> for >> one week (as there several artifacts): >> >> >> [ ] +1 release all >> >> [ ] 0 don't care >> >> [ ] -1 do NOT release, because >> >> >> Thanks and Regards >> >> >> Clement >> >> >> > -- Karl Pauls [EMAIL PROTECTED]
[jira] Created: (FELIX-577) Problems with the bundle url protocol
Problems with the bundle url protocol - Key: FELIX-577 URL: https://issues.apache.org/jira/browse/FELIX-577 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.0.4 Reporter: Guillaume Nodet Fix For: felix-1.0.5 The "bundle:" protocol URL handler is built in Felix framework, but does not seem to work well for me at the moment. The idea behing this URL handler is to be able to access any resource inside a bundle. The syntax is as following: bundle://[bundleId].[bundleRev]:[classPathId]/[path] where [bundleId] is the id of the bundle, [bundleRev] is the revision of the bundle (when new versions are installed), [classPathId] is the index in the list of jars that make the classpath (internal structure) and [path] is the path of the resource in the bundle. My problem is that [bundleRev] and [classPathId] refer to internal structures and can't be accessed from outside the felix framework. [classPathId] can be set to 0 to look inside the whole classpath entries, but if not specified, the default value of the url port is -1 and an IndexOutOfBounds exception is thrown. Another problem is that [bundleRev] can not be ommitted and (in addition to the parsing having a bug) there is no default value. I will raise a JIRA and attach a patch to do the following: * if the url port is ommitted (thus defaults to -1), use the same behavior as if 0 was used (search in the whole classpath) * fix the revision bundle parsing, which returns the bundle id if none is specified: it will return -1 if the bundle revision was not set * fix the look up mechanism so that when no bundle revision is specified, (revision == -1), all bundle revisions will be searched in reverse order (the most recent revision first) The last problem is really difficult to work around as there is no way to find the bundle revision from a client bundle and there is no default value, so the only way to make that work is to specify 0 and expect the bundle to have not been updated (which ovbiously is not a good idea). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems with URL handler for bundle:// protocol
On Fri, May 30, 2008 at 9:48 AM, Richard S. Hall <[EMAIL PROTECTED]> wrote: > Guillaume Nodet wrote: >> >> The "bundle:" protocol URL handler is built in Felix framework, but >> does not seem to work well for me at the moment. The idea behing this >> URL handler is to be able to access any resource inside a bundle. The >> syntax is as following: >> >> bundle://[bundleId].[bundleRev]:[classPathId]/[path] >> >> where [bundleId] is the id of the bundle, [bundleRev] is the revision >> of the bundle (when new versions are installed), [classPathId] is the >> index in the list of jars that make the classpath (internal structure) >> and [path] is the path of the resource in the bundle. >> >> My problem is that [bundleRev] and [classPathId] refer to internal >> structures and can't be accessed from outside the felix framework. >> [classPathId] can be set to 0 to look inside the whole classpath >> entries, but if not specified, the default value of the url port is -1 >> and an IndexOutOfBounds exception is thrown. >> > > Yes, the exception sounds like a bug that should be fixed. > >> Another problem is that [bundleRev] can not be ommitted and (in >> addition to the parsing having a bug) there is no default value. >> > > Perhaps we should just define the default value to be the current revision. > >> I will raise a JIRA and attach a patch to do the following: >> * if the url port is ommitted (thus defaults to -1), use the same >> behavior as if 0 was used (search in the whole classpath) >> > > ok > >> * fix the revision bundle parsing, which returns the bundle id if >> none is specified: it will return -1 if the bundle revision was not >> set >> > > ok > >> * fix the look up mechanism so that when no bundle revision is >> specified, (revision == -1), all bundle revisions will be searched in >> reverse order (the most recent revision first) >> > > Personally, I would just search the most recent and be done with it, > otherwise we could end up with situations where we are splitting across > revisions. Sounds good. >> The last problem is really difficult to work around as there is no way >> to find the bundle revision from a client bundle and there is no >> default value, so the only way to make that work is to specify 0 and >> expect the bundle to have not been updated (which ovbiously is not a >> good idea). >> > > While I agree that these are issues that should be addressed, we are really > talking about special cases here, since you generally shouldn't be trying to > construct your own bundle resource URL since the URL structure is supposed > to be opaque and framework dependent. > > -> richard Yeah, I agree this is felix dependant, but it's nonetheless really handy. I suppose at some point, I would have to rewrite my own url handler to handle this in a less felix specific way. >> Feedback welcome. >> >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Problems with URL handler for bundle:// protocol
Guillaume Nodet wrote: The "bundle:" protocol URL handler is built in Felix framework, but does not seem to work well for me at the moment. The idea behing this URL handler is to be able to access any resource inside a bundle. The syntax is as following: bundle://[bundleId].[bundleRev]:[classPathId]/[path] where [bundleId] is the id of the bundle, [bundleRev] is the revision of the bundle (when new versions are installed), [classPathId] is the index in the list of jars that make the classpath (internal structure) and [path] is the path of the resource in the bundle. My problem is that [bundleRev] and [classPathId] refer to internal structures and can't be accessed from outside the felix framework. [classPathId] can be set to 0 to look inside the whole classpath entries, but if not specified, the default value of the url port is -1 and an IndexOutOfBounds exception is thrown. Yes, the exception sounds like a bug that should be fixed. Another problem is that [bundleRev] can not be ommitted and (in addition to the parsing having a bug) there is no default value. Perhaps we should just define the default value to be the current revision. I will raise a JIRA and attach a patch to do the following: * if the url port is ommitted (thus defaults to -1), use the same behavior as if 0 was used (search in the whole classpath) ok * fix the revision bundle parsing, which returns the bundle id if none is specified: it will return -1 if the bundle revision was not set ok * fix the look up mechanism so that when no bundle revision is specified, (revision == -1), all bundle revisions will be searched in reverse order (the most recent revision first) Personally, I would just search the most recent and be done with it, otherwise we could end up with situations where we are splitting across revisions. The last problem is really difficult to work around as there is no way to find the bundle revision from a client bundle and there is no default value, so the only way to make that work is to specify 0 and expect the bundle to have not been updated (which ovbiously is not a good idea). While I agree that these are issues that should be addressed, we are really talking about special cases here, since you generally shouldn't be trying to construct your own bundle resource URL since the URL structure is supposed to be opaque and framework dependent. -> richard Feedback welcome.
Problems with URL handler for bundle:// protocol
The "bundle:" protocol URL handler is built in Felix framework, but does not seem to work well for me at the moment. The idea behing this URL handler is to be able to access any resource inside a bundle. The syntax is as following: bundle://[bundleId].[bundleRev]:[classPathId]/[path] where [bundleId] is the id of the bundle, [bundleRev] is the revision of the bundle (when new versions are installed), [classPathId] is the index in the list of jars that make the classpath (internal structure) and [path] is the path of the resource in the bundle. My problem is that [bundleRev] and [classPathId] refer to internal structures and can't be accessed from outside the felix framework. [classPathId] can be set to 0 to look inside the whole classpath entries, but if not specified, the default value of the url port is -1 and an IndexOutOfBounds exception is thrown. Another problem is that [bundleRev] can not be ommitted and (in addition to the parsing having a bug) there is no default value. I will raise a JIRA and attach a patch to do the following: * if the url port is ommitted (thus defaults to -1), use the same behavior as if 0 was used (search in the whole classpath) * fix the revision bundle parsing, which returns the bundle id if none is specified: it will return -1 if the bundle revision was not set * fix the look up mechanism so that when no bundle revision is specified, (revision == -1), all bundle revisions will be searched in reverse order (the most recent revision first) The last problem is really difficult to work around as there is no way to find the bundle revision from a client bundle and there is no default value, so the only way to make that work is to specify 0 and expect the bundle to have not been updated (which ovbiously is not a good idea). Feedback welcome. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [Vote] Release iPOJO 0.8.0
I hate to raise some issues with this release since I know it was a pain for Clement to create and I, as much as anyone, want to get an iPOJO release out the door; however, we might need address some of these issues: Serious issues -- * org.apache.felix.ipojo.ant embeds ObjectWeb code, but nothing in NOTICE and no license. * org.apache.felix.ipojo.composite embeds ObjectWeb code, but nothing in NOTICE and no license. * org.apache.felix.ipojo.manipulator doesn't include ASM license (perhaps this is not so serious, since it is mentioned in the notice file). * org.apache.felix.ipojo.handler.temporal does not include NOTICE/LICENSE files. Minor issues * org.apache.felix.ipojo.handler.extender.pattern says it includes OSGi software, but it doesn't. * org.apache.felix.ipojo.handler.white.board.pattern says it includes OSGi software, but it doesn't. * Change artifact names for extender and whiteboard handlers; e.g., change "org.apache.felix.ipojo.handler.extender.pattern" to "org.apache.felix.ipojo.handler.extender" and "org.apache.felix.ipojo.handler.white.board.pattern" to "org.apache.felix.ipojo.handler.whiteboard". * Eliminate bz2 digest files (I know maven generates these, but just delete them to avoid the mess). -> richard Clement Escoffier wrote: Hi all, I finally cut the first release of the iPOJO framework. Eleven artifacts compose this first release (version 0.8.0): http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.metadata/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.manipulator/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.ant/ http://people.apache.org/~clement/releases/org/apache/felix/maven-ipojo-plug in/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.arch/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.annotations/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.handler.extender.pattern/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.handler.white.board.pattern/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.handler.temporal/ http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix .ipojo.arch/ The KEYS for verifying the signature is also in the directories, the MD5 and SHA1 files are maven generated. So please check the releases and cast your votes - the vote will be open for one week (as there several artifacts): [ ] +1 release all [ ] 0 don't care [ ] -1 do NOT release, because Thanks and Regards Clement
