Re: [VOTE] Apache Felix Dependency Manager Release Candidate R2
+1 (verified and tested) Xander On Thu, Mar 19, 2015 at 11:09 PM, Pierre De Rop wrote: > Hello all, > > A critical bug has been found in the previous Dependency Manager R1 > release, and I need to open a vote for a new R2 top-level release. > > We solved the following issues: > > * [FELIX-4832] - ClassCastException with autoconfig Iterable fields > * [FELIX-4833] - Revisit some javadocs in the DM annotations. > > You can use this UNIX script to download the release and verify the > signatures: > > > http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh > > Usage: > sh check_staged_release.sh r2 /tmp/felix-staging > > This script, unlike the original Felix check_stage_release.sh, is specific > to the new Dependency Manager release process (see FELIX-4818) and will > download staging from https://dist.apache.org/repos/dist/dev/felix instead > of http://repository.apache.org/content/repositories. > > To rebuild the DM binaries from the source, you can then refer to > > https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/resources/src/README.src > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > Thank you; > /Pierre >
Re: [VOTE] Apache Felix Dependency Manager Release Candidate R1
+1 Verified and tested. Cheers, Xander On Thu, Mar 5, 2015 at 8:51 AM, Pierre De Rop wrote: > Hello all, > > After a year of work with various people, I'm opening a vote for the new R1 > top-level and major release candidate of the Dependency Manager. > > We solved 23 issues in this release: > > FELIX-2706: Support callback delegation for Configuration Dependecies > FELIX-3914: Log unsuccessful field injections > FELIX-4158: ComponentDeclaration should give access to component > information > FELIX-4304: DependencyManager ComponentImpl should not assume all service > properties are stored in a Hashtable > FELIX-4394: Race problems in DependencyManager Configuration Dependency > FELIX-4426: Allow DM to manage collections of services > FELIX-4588: createCopy method ConfigurationDependency produces a > malfunctioning clone > FELIX-4594: Propagation from dependencies overwrites service properties > FELIX-4598: BundleDependency can effectively track only one bundle > FELIX-4600: Cherrypicking of propagated properties > FELIX-4602: TemporalServiceDependency does not properly propagate > RuntimeExceptions > FELIX-4667: "top" command for the Dependency Manager Shell > FELIX-4672: Allow callbacks to third party instance for adapters > FELIX-4673: Log any error thrown when trying to create a null object. > FELIX-4676: Add Provide-Capability for DependencyManager Runtime bundle > FELIX-4680: Add more DM ServiceDependency callback signatures > FELIX-4683: Allow to configure the DependencyManager shell scope > FELIX-4684: Replace DependencyManager Runtime "factorySet" by a cleaner API > FELIX-4709: Incorrect Named Dependencies are binded to the Service Instance > FELIX-4777: Dynamic initialization time configuration of > @ConfigurationDependency > FELIX-4805: Deprecate DM annotation metatypes > FELIX-4807: New thread model for Dependency Manager > FELIX-4816: bndtools-ify Dependency Manager > > You can use this UNIX script to download the release and verify the > signatures: > > > http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh > > Usage: > sh check_staged_release.sh r1 /tmp/felix-staging > > This script, unlike the original Felix check_stage_release.sh, is specific > to the new Dependency Manager release process (see FELIX-4818) and will > download staging from https://dist.apache.org/repos/dist/dev/felix instead > of http://repository.apache.org/content/repositories. > > To rebuild the DM binaries from the source, you can then refer to > > https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/resources/src/README.src > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > Many thanks; >
[jira] [Resolved] (FELIX-4597) Race issue causing ConcurrentModificationException in org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111)
[ https://issues.apache.org/jira/browse/FELIX-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-4597. --- Resolution: Fixed Resolved by returning a copy of the set on addHttpContext instead of the original set. > Race issue causing ConcurrentModificationException in > org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111) > - > > Key: FELIX-4597 > URL: https://issues.apache.org/jira/browse/FELIX-4597 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.3.0 > Reporter: Xander Uiterlinden >Assignee: Xander Uiterlinden > > Quite frequently when launching our application we're getting a > ConcurrentModificationException, see the following stacktrace: > java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) > at java.util.HashMap$KeyIterator.next(HashMap.java:1453) > at > org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111) > at > org.apache.felix.http.whiteboard.internal.tracker.HttpContextTracker.added(HttpContextTracker.java:37) > at > org.apache.felix.http.whiteboard.internal.tracker.HttpContextTracker.added(HttpContextTracker.java:24) > at > org.apache.felix.http.whiteboard.internal.tracker.AbstractTracker.addingService(AbstractTracker.java:36) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:8 > This is caused by a race issue where one thread is adding HttpContext where > another thread is adding a servlet for this context at the same time. > Thread A: > In ExtenderManager.addHttpContext(service, ref) the http context is added to > the context manager which returns a collection of mappings. This collection > is the actual collection as administered by the HttpContextHolder. > In a for loop* on these mappings the mappings are registered with the > HttpService. > Collection mappings = > this.contextManager.addHttpContext(bundle, contextId, service); > Thread B: > When adding a servlet on the other thread, getHttpContext(mapping, ref) is > called which calls getHttpContext(bundle, contextId, mapping). Here the > HttpContextHolder is obtained by HttpContextHolder holder = > this.idMap.get(id). After which holder.addMapping(mapping) is called. This > addMapping is called while thread A is still in it's for loop iterating over > the mappings. > This requires synchronization. It would actually be nice to be able to > synchronize on a particular HttpContext. This would require some method > refactoring. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (FELIX-4597) Race issue causing ConcurrentModificationException in org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111)
[ https://issues.apache.org/jira/browse/FELIX-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden reassigned FELIX-4597: - Assignee: Xander Uiterlinden > Race issue causing ConcurrentModificationException in > org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111) > - > > Key: FELIX-4597 > URL: https://issues.apache.org/jira/browse/FELIX-4597 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.3.0 > Reporter: Xander Uiterlinden >Assignee: Xander Uiterlinden > > Quite frequently when launching our application we're getting a > ConcurrentModificationException, see the following stacktrace: > java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) > at java.util.HashMap$KeyIterator.next(HashMap.java:1453) > at > org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111) > at > org.apache.felix.http.whiteboard.internal.tracker.HttpContextTracker.added(HttpContextTracker.java:37) > at > org.apache.felix.http.whiteboard.internal.tracker.HttpContextTracker.added(HttpContextTracker.java:24) > at > org.apache.felix.http.whiteboard.internal.tracker.AbstractTracker.addingService(AbstractTracker.java:36) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932) > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864) > at > org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) > at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:8 > This is caused by a race issue where one thread is adding HttpContext where > another thread is adding a servlet for this context at the same time. > Thread A: > In ExtenderManager.addHttpContext(service, ref) the http context is added to > the context manager which returns a collection of mappings. This collection > is the actual collection as administered by the HttpContextHolder. > In a for loop* on these mappings the mappings are registered with the > HttpService. > Collection mappings = > this.contextManager.addHttpContext(bundle, contextId, service); > Thread B: > When adding a servlet on the other thread, getHttpContext(mapping, ref) is > called which calls getHttpContext(bundle, contextId, mapping). Here the > HttpContextHolder is obtained by HttpContextHolder holder = > this.idMap.get(id). After which holder.addMapping(mapping) is called. This > addMapping is called while thread A is still in it's for loop iterating over > the mappings. > This requires synchronization. It would actually be nice to be able to > synchronize on a particular HttpContext. This would require some method > refactoring. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FELIX-4597) Race issue causing ConcurrentModificationException in org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111)
Xander Uiterlinden created FELIX-4597: - Summary: Race issue causing ConcurrentModificationException in org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111) Key: FELIX-4597 URL: https://issues.apache.org/jira/browse/FELIX-4597 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.3.0 Reporter: Xander Uiterlinden Quite frequently when launching our application we're getting a ConcurrentModificationException, see the following stacktrace: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$KeyIterator.next(HashMap.java:1453) at org.apache.felix.http.whiteboard.internal.manager.ExtenderManager.add(ExtenderManager.java:111) at org.apache.felix.http.whiteboard.internal.tracker.HttpContextTracker.added(HttpContextTracker.java:37) at org.apache.felix.http.whiteboard.internal.tracker.HttpContextTracker.added(HttpContextTracker.java:24) at org.apache.felix.http.whiteboard.internal.tracker.AbstractTracker.addingService(AbstractTracker.java:36) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:932) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:864) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:8 This is caused by a race issue where one thread is adding HttpContext where another thread is adding a servlet for this context at the same time. Thread A: In ExtenderManager.addHttpContext(service, ref) the http context is added to the context manager which returns a collection of mappings. This collection is the actual collection as administered by the HttpContextHolder. In a for loop* on these mappings the mappings are registered with the HttpService. Collection mappings = this.contextManager.addHttpContext(bundle, contextId, service); Thread B: When adding a servlet on the other thread, getHttpContext(mapping, ref) is called which calls getHttpContext(bundle, contextId, mapping). Here the HttpContextHolder is obtained by HttpContextHolder holder = this.idMap.get(id). After which holder.addMapping(mapping) is called. This addMapping is called while thread A is still in it's for loop iterating over the mappings. This requires synchronization. It would actually be nice to be able to synchronize on a particular HttpContext. This would require some method refactoring. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (FELIX-4304) DependencyManager ComponentImpl should not assume all service properties are stored in a Hashtable
[ https://issues.apache.org/jira/browse/FELIX-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden reassigned FELIX-4304: - Assignee: Xander Uiterlinden > DependencyManager ComponentImpl should not assume all service properties are > stored in a Hashtable > -- > > Key: FELIX-4304 > URL: https://issues.apache.org/jira/browse/FELIX-4304 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 >Reporter: Herko ter Horst >Assignee: Xander Uiterlinden > Attachments: ComponentImpl.java.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > In org.apache.felix.dm.impl.ComponentImpl.getServiceProperties() a copy of > the internal field m_serviceProperties is created by casting to Hashtable and > calling clone(). However, as clients are allowed to call > setServiceProperties(Dictionary properties) which assigns the parameter value > to the field, it is very possible for m_serviceProperties to contain some > other Dictionary implementation. > The attached patch doesn't solves this problem in getServiceProperties() by > making a copy by enumerating over all keys and putting them in a newly > created Hashtable. > Alternatively (or in addition), setProperties() could be changed to ensure > the parameter value isn't directly assigned to the field. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FELIX-3910) Race conditions in DependencyManager
[ https://issues.apache.org/jira/browse/FELIX-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774356#comment-13774356 ] Xander Uiterlinden commented on FELIX-3910: --- Ik just reviewed the patch. I see it introduces a SerialExecutor to prevent race conditions. With revision r1488970 I introduced a guarded block to guarantee execution of callback methods in the correct order. See the enqueueCallback, waitForCallbackLock, execute and releaseCallback methods. Maybe we can remove the serial executor introduced in the patch and use this mechanism for the non-aspect aware callbacks as well ? > Race conditions in DependencyManager > > > Key: FELIX-3910 > URL: https://issues.apache.org/jira/browse/FELIX-3910 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 > Environment: jdk1.6, jdk1.7, linux fc16 >Reporter: Pierre De Rop > Attachments: FELIX-3910-patch, FELIX-3910.patch.2, FELIX-3910.patch.3 > > > In a multi threaded context, where dependencies are injected concurrently > from different threads, we came across some exceptions which seem to take > place from dependencymanager. > I have tried to reproduce the problems using a paxexam test which I will > commit. > Not all exceptions are reproduced by the test case, but I think that the > testcase really reproduces a problem. > I also have a candidate patch, which I will submit to this jira issue. > Here are the exceptions we have seen: > first stacktrace seen: > === > ERROR: Bundle test.dm [21] EventDispatcher: Error during dispatch. > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.dm.impl.dependencies.ServiceDependencyImpl.addedService(ServiceDependencyImpl.java:481) > at > org.apache.felix.dm.tracker.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1325) > at > org.apache.felix.dm.tracker.AbstractTracked.trackAdding(AbstractTracked.java:290) > at > org.apache.felix.dm.tracker.AbstractTracked.track(AbstractTracked.java:236) > at > org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChangedHideAspects(ServiceTracker.java:1206) > at > org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1101) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > at > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > at > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) > at org.apache.felix.framework.Felix.registerService(Felix.java:3275) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320) > at test.dm.race.RaceTest$RegistrationHelper$1.run(RaceTest.java:104) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > second exceptions: > == > ERROR: EventDispatcher: Error during dispatch. > (java.lang.NullPointerException) > java.lang.NullPointerException > at > org.apache.felix.dm.impl.ComponentImpl.invokeCallbackMethod(ComponentImpl.java:686) > at > org.apache.felix.dm.impl.dependencies.ServiceDependencyImpl.invoke(ServiceDependencyImpl.java:704) > at > org.apache.felix.dm.impl.dependencies.ServiceDependencyImpl.invokeRemoved(ServiceDependencyImpl.java:666) > at > org.apache.felix.dm.impl.dependencies.ServiceDependencyImpl.removedService(ServiceDependencyImpl.java:520) > at > org.apache.felix.dm.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1351) > at > org.apache.felix.dm.tracker.AbstractTracked.untrack(AbstractTracked.java:359) > at > org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChangedHideAspects(ServiceTracker.java:1285) > at > org.apache.felix.dm.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1101) > at > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDisp
[jira] [Work started] (FELIX-4226) Add option to have the dependency manager log against a single BundleContext's LogService.
[ https://issues.apache.org/jira/browse/FELIX-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4226 started by Xander Uiterlinden. > Add option to have the dependency manager log against a single > BundleContext's LogService. > -- > > Key: FELIX-4226 > URL: https://issues.apache.org/jira/browse/FELIX-4226 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 > Reporter: Xander Uiterlinden >Assignee: Xander Uiterlinden > > DependencyManager uses the OSGi LogService for it's logging. The LogService > is provided per bundle. As a typical application consists of many bundles, > many different LogServices will be used by the dependencymanager. > A common pattern for an application is to implement a LogListener to catch > all log events and pass them to a logging framework, e.g. log4j, > commons-logging etc. All of these framework have the notion of a logger name > or class. This is usually also the element of which the log levels can be > configured. In a LogEntry provided by the OSGi logging framework typically > only the bundlename makes sense to be used as the logger name/class. > Due to the fact that an application can have many dependency managers and > thus use several different LogServices all tied to their own bundlecontext, > this logger name is going to be differ. > It would be practical to be able to instruct the dependency manager to log > against a single LogService only so the bundle name provided in the log event > can also practically be used as a logger name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4226) Add option to have the dependency manager log against a single BundleContext's LogService.
Xander Uiterlinden created FELIX-4226: - Summary: Add option to have the dependency manager log against a single BundleContext's LogService. Key: FELIX-4226 URL: https://issues.apache.org/jira/browse/FELIX-4226 Project: Felix Issue Type: Improvement Components: Dependency Manager Affects Versions: dependencymanager-3.1.0 Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden DependencyManager uses the OSGi LogService for it's logging. The LogService is provided per bundle. As a typical application consists of many bundles, many different LogServices will be used by the dependencymanager. A common pattern for an application is to implement a LogListener to catch all log events and pass them to a logging framework, e.g. log4j, commons-logging etc. All of these framework have the notion of a logger name or class. This is usually also the element of which the log levels can be configured. In a LogEntry provided by the OSGi logging framework typically only the bundlename makes sense to be used as the logger name/class. Due to the fact that an application can have many dependency managers and thus use several different LogServices all tied to their own bundlecontext, this logger name is going to be differ. It would be practical to be able to instruct the dependency manager to log against a single LogService only so the bundle name provided in the log event can also practically be used as a logger name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4099) Add support for negations in the multi property filter index
Xander Uiterlinden created FELIX-4099: - Summary: Add support for negations in the multi property filter index Key: FELIX-4099 URL: https://issues.apache.org/jira/browse/FELIX-4099 Project: Felix Issue Type: Wish Components: Dependency Manager Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden Currently the multi property exact filter does only support a simple comparison, but does not support negations, e.g. (&(a=x)(!(b=y))). It would be nice if support for negations could be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4099) Add support for negations in the multi property filter index
[ https://issues.apache.org/jira/browse/FELIX-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-4099. --- Resolution: Fixed Rewrote the multi property exact filter implementation and added negation support. > Add support for negations in the multi property filter index > > > Key: FELIX-4099 > URL: https://issues.apache.org/jira/browse/FELIX-4099 > Project: Felix > Issue Type: Wish > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > Currently the multi property exact filter does only support a simple > comparison, but does not support negations, e.g. (&(a=x)(!(b=y))). It would > be nice if support for negations could be added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4098) Aspect swap sometimes invokes the callbacks in the wrong order in a multithreaded application.
[ https://issues.apache.org/jira/browse/FELIX-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-4098. --- Resolution: Fixed Discovered the swap calculation and invocation also had some other issues. Rewrote this method and added synchronization for the callback method invocation using a guarded block. > Aspect swap sometimes invokes the callbacks in the wrong order in a > multithreaded application. > -- > > Key: FELIX-4098 > URL: https://issues.apache.org/jira/browse/FELIX-4098 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Critical > > In a multithreaded application the swap callback invocations sometimes > overtake each other which causes in callbacks being invoked in the wrong > order. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-4098) Aspect swap sometimes invokes the callbacks in the wrong order in a multithreaded application.
[ https://issues.apache.org/jira/browse/FELIX-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4098 started by Xander Uiterlinden. > Aspect swap sometimes invokes the callbacks in the wrong order in a > multithreaded application. > -- > > Key: FELIX-4098 > URL: https://issues.apache.org/jira/browse/FELIX-4098 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Critical > > In a multithreaded application the swap callback invocations sometimes > overtake each other which causes in callbacks being invoked in the wrong > order. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4098) Aspect swap sometimes invokes te callbacks in the wrong order in a multithreaded application.
Xander Uiterlinden created FELIX-4098: - Summary: Aspect swap sometimes invokes te callbacks in the wrong order in a multithreaded application. Key: FELIX-4098 URL: https://issues.apache.org/jira/browse/FELIX-4098 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden Priority: Critical In a multithreaded application the swap callback invocations sometimes overtake each other which causes in callbacks being invoked in the wrong order. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4098) Aspect swap sometimes invokes the callbacks in the wrong order in a multithreaded application.
[ https://issues.apache.org/jira/browse/FELIX-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-4098: -- Summary: Aspect swap sometimes invokes the callbacks in the wrong order in a multithreaded application. (was: Aspect swap sometimes invokes te callbacks in the wrong order in a multithreaded application.) > Aspect swap sometimes invokes the callbacks in the wrong order in a > multithreaded application. > -- > > Key: FELIX-4098 > URL: https://issues.apache.org/jira/browse/FELIX-4098 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Critical > > In a multithreaded application the swap callback invocations sometimes > overtake each other which causes in callbacks being invoked in the wrong > order. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (FELIX-4097) Allow debug logging for specific instances of service dependencies to debug wiring issues.
[ https://issues.apache.org/jira/browse/FELIX-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4097 stopped by Xander Uiterlinden. > Allow debug logging for specific instances of service dependencies to debug > wiring issues. > -- > > Key: FELIX-4097 > URL: https://issues.apache.org/jira/browse/FELIX-4097 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 > Reporter: Xander Uiterlinden >Assignee: Xander Uiterlinden >Priority: Minor > > Sometimes it can really help when a specific servicedependency can be tracked > when debugging wiring / dependency injection issues so it would be very > helpful if a servicedependency can be configured with a debug parameter which > a: enables debug logging for this service dependency, b. allows for a > conditional breakpoint to step into the methods of this instance only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-4097) Allow debug logging for specific instances of service dependencies to debug wiring issues.
[ https://issues.apache.org/jira/browse/FELIX-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4097 started by Xander Uiterlinden. > Allow debug logging for specific instances of service dependencies to debug > wiring issues. > -- > > Key: FELIX-4097 > URL: https://issues.apache.org/jira/browse/FELIX-4097 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 > Reporter: Xander Uiterlinden >Assignee: Xander Uiterlinden >Priority: Minor > > Sometimes it can really help when a specific servicedependency can be tracked > when debugging wiring / dependency injection issues so it would be very > helpful if a servicedependency can be configured with a debug parameter which > a: enables debug logging for this service dependency, b. allows for a > conditional breakpoint to step into the methods of this instance only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4097) Allow debug logging for specific instances of service dependencies to debug wiring issues.
[ https://issues.apache.org/jira/browse/FELIX-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-4097. --- Resolution: Fixed added setDebug(String identifier) to ServiceDependency allowing to track a single service dependency by a self specified identifier. This identifier is included in the debug logging and can be used to set conditional breakpoints. > Allow debug logging for specific instances of service dependencies to debug > wiring issues. > -- > > Key: FELIX-4097 > URL: https://issues.apache.org/jira/browse/FELIX-4097 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 > Reporter: Xander Uiterlinden >Assignee: Xander Uiterlinden >Priority: Minor > > Sometimes it can really help when a specific servicedependency can be tracked > when debugging wiring / dependency injection issues so it would be very > helpful if a servicedependency can be configured with a debug parameter which > a: enables debug logging for this service dependency, b. allows for a > conditional breakpoint to step into the methods of this instance only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4097) Allow debug logging for specific instances of service dependencies to debug wiring issues.
Xander Uiterlinden created FELIX-4097: - Summary: Allow debug logging for specific instances of service dependencies to debug wiring issues. Key: FELIX-4097 URL: https://issues.apache.org/jira/browse/FELIX-4097 Project: Felix Issue Type: Improvement Components: Dependency Manager Affects Versions: dependencymanager-3.1.0 Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden Priority: Minor Sometimes it can really help when a specific servicedependency can be tracked when debugging wiring / dependency injection issues so it would be very helpful if a servicedependency can be configured with a debug parameter which a: enables debug logging for this service dependency, b. allows for a conditional breakpoint to step into the methods of this instance only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4014) handleAspectAwareRemoved in ServiceDependencyImpl can cause a possible deadlock
[ https://issues.apache.org/jira/browse/FELIX-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-4014. --- Resolution: Fixed fixed by moving the callback outside of the synchronized block. > handleAspectAwareRemoved in ServiceDependencyImpl can cause a possible > deadlock > --- > > Key: FELIX-4014 > URL: https://issues.apache.org/jira/browse/FELIX-4014 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > the handleAspectAwareRemoved invokes a callback method within a > synchronization block. Since we don't know what will be going there this can > cause (and in our case does cause) concurrency issues. > The fix would be to move the invoke out of the sync block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-4014) handleAspectAwareRemoved in ServiceDependencyImpl can cause a possible deadlock
[ https://issues.apache.org/jira/browse/FELIX-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4014 started by Xander Uiterlinden. > handleAspectAwareRemoved in ServiceDependencyImpl can cause a possible > deadlock > --- > > Key: FELIX-4014 > URL: https://issues.apache.org/jira/browse/FELIX-4014 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > the handleAspectAwareRemoved invokes a callback method within a > synchronization block. Since we don't know what will be going there this can > cause (and in our case does cause) concurrency issues. > The fix would be to move the invoke out of the sync block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4015) Better debugging support through additional shell commands
Xander Uiterlinden created FELIX-4015: - Summary: Better debugging support through additional shell commands Key: FELIX-4015 URL: https://issues.apache.org/jira/browse/FELIX-4015 Project: Felix Issue Type: Wish Components: Dependency Manager Reporter: Xander Uiterlinden Better debugging support in the shell would be nice, suggestions: - Being able to query components by filter (like services ) - Support for "root-cause" finding of unavailable dependencies - Being able to create snapshots and diffs in the set of registered components to detect insufficient cleanup when e.g. stopping a bundle -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4014) handleAspectAwareRemoved in ServiceDependencyImpl can cause a possible deadlock
Xander Uiterlinden created FELIX-4014: - Summary: handleAspectAwareRemoved in ServiceDependencyImpl can cause a possible deadlock Key: FELIX-4014 URL: https://issues.apache.org/jira/browse/FELIX-4014 Project: Felix Issue Type: Bug Components: Dependency Manager Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden the handleAspectAwareRemoved invokes a callback method within a synchronization block. Since we don't know what will be going there this can cause (and in our case does cause) concurrency issues. The fix would be to move the invoke out of the sync block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Felix Dependency Manager Core, Annotation, Runtime version 3.1.0 and Compat, Shell version 3.0.1
+1 Xander Op Jan 23, 2013, om 4:14 PM heeft Marcel Offermans het volgende geschreven: > Hello everybody, > > After contributions from various people, and testing several new major > features, it is time to vote on a new release of the Dependency Manager > bundles. We resolved the following Jira issues this release: > > FELIX-303 - Support for compositions > FELIX-1201 - Issue with DM and CM > FELIX-1278 - DM/ AutoConfig is active event if setCallbacks method has been > invoked > FELIX-1464 - issue when using a negation in ldap service dependency filter > FELIX-1546 - DM/Temporal Dependency/Bound Service Replacement features > FELIX-2078 - Not all callbacks invoked when declaring a service as required > and starting it after dependencies > FELIX-2344 - DM / callback method is not invoked when an extra dependency is > defined within an "init" component method. > FELIX-2348 - DM/ ResourceAdapter NPE > FELIX-2369 - DM/ Service start method is invoked even if an extra required > dependency is unavailable > FELIX-2816 - dependency manager calls init() twice > FELIX-2947 - Filter indices must use service trackers that track all services > and aspects. > FELIX-2953 - Make the cache that InvocationUtil uses configurable. > FELIX-2954 - DM/ annotated component factory does not allow to provide a > component instance explicitly > FELIX-2955 - IllegalStateException when doing a 'dm notavail' shell command. > FELIX-2956 - DM/ json should be embedded in the annotation scanner plugin > FELIX-2964 - DM/ NPE on some dependency manager adapters, when > "auto-configuration" mode is disabled. > FELIX-2970 - DM/ Factory Configuration Adapter Service does not copy adapter > dependencies > FELIX-2976 - InvocationUtil cache is not used properly for determining that > methods do not exist in a class > FELIX-2987 - DependencyManager ConfigurationDependency update isn't > propagated to super classes > FELIX-3005 - Compatibility API does not add components in DependencyManager > FELIX-3008 - NPE in ServiceRegistryCache when dependency manager bundle is > not started first > FELIX-3042 - [PATCH] Add a convenience clear() method on DependencyManager > FELIX-3057 - getServiceReferences() should not return an empty array > FELIX-3186 - Adapter services do not get their adapted services transparently > replaced when an aspect is added to them. > FELIX-3201 - Offer more functional callback methods for services that have > aspects on them. > FELIX-3218 - ServiceTracker performance is not optimal with a service > dependency that results in n-thousands of injected services. > FELIX-3264 - Dependency manager shell should not print the state of optional > dependencies when not all required ones are available > FELIX-3292 - Allow passing of resource properties to a resource handler for > use with resource adapters. > FELIX-3337 - DependencyManager/Updated configuration dependency does not > propagate to provided service properties > FELIX-3402 - DependencyManager stop can trigger IndexOutOfBoundsException > FELIX-3423 - AdapterImpl copies the DependencyManager.ASPECT service property > when adapting an aspect. > FELIX-3424 - Add support for changed callbacks on Aspect services. > FELIX-3425 - Provide a filter index for adapter services. > FELIX-3475 - DependencyManager compatibility bundle - ServiceDependencyImpl > does not override toString > FELIX-3564 - Memory leak in Filterindex / ServiceRegistryCache > FELIX-3592 - ServiceDependencyImpl does not copy the swapped callback in it's > constructor. > FELIX-3617 - Missing toString methods in DependencyManager compat bundle > FELIX-3682 - Dependency Manager Annotation-3.0.0 module doesn't expose OSGI > meta information in MANIFEST.MF > FELIX-3828 - Aspect and Adapter filter indices to not handle components that > have been bound with multiple interfaces correctly. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-161/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 161 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > Greetings, Marcel >
[jira] [Commented] (FELIX-3856) Provide documentation for filter indices
[ https://issues.apache.org/jira/browse/FELIX-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558612#comment-13558612 ] Xander Uiterlinden commented on FELIX-3856: --- both Adapter and Aspect services use a standard filter for their operations. AdapterService: (&(objectClass=foo.Bar)(|(service.id=18233)(org.apache.felix.dependencymanager.aspect=18233))) AspectService: (&(objectClass=foo.Bar)(|(!(service.ranking=*))(service.ranking<=99))(|(service.id=4451)(org.apache.felix.dependencymanager.aspect=4451))) For these an index can be enabled as well. Since their filters are a bit more complex than supported by the MultiPropertyExactFilter they have their own index implementations. These indexes can be enabled through the org.apache.felix.dependencymanager.filterindex property as well. Instead of providing the 'columns' the index is for, a simple *aspect* or *adapter* suffices. example: org.apache.felix.dependencymanager.filterindex=*aspect*;*adapter*;mya,myb,objectClass;objectClass > Provide documentation for filter indices > > > Key: FELIX-3856 > URL: https://issues.apache.org/jira/browse/FELIX-3856 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Angelo van der Sijpt > Attachments: FELIX-3856-Filter-indices-documentation.patch > > > The current Dependency Manager Reference Guide ( > http://felix.apache.org/site/apache-felix-dependency-manager-reference-guide.html > ) is rather mute on the subject of filter indices, only stating they are an > experimental feature. > Now the indices will make it into the upcoming release, we will have to > provide some guidelines for users of this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3856) Provide documentation for filter indices
[ https://issues.apache.org/jira/browse/FELIX-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558265#comment-13558265 ] Xander Uiterlinden commented on FELIX-3856: --- Thanks for the patch. We should also mention the indices for aspect and adapter services, enabled with either *aspect* or *adapter*. > Provide documentation for filter indices > > > Key: FELIX-3856 > URL: https://issues.apache.org/jira/browse/FELIX-3856 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Angelo van der Sijpt > Attachments: FELIX-3856-Filter-indices-documentation.patch > > > The current Dependency Manager Reference Guide ( > http://felix.apache.org/site/apache-felix-dependency-manager-reference-guide.html > ) is rather mute on the subject of filter indices, only stating they are an > experimental feature. > Now the indices will make it into the upcoming release, we will have to > provide some guidelines for users of this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-3828) Aspect and Adapter filter indices to not handle components that have been bound with multiple interfaces correctly.
[ https://issues.apache.org/jira/browse/FELIX-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3828 started by Xander Uiterlinden. > Aspect and Adapter filter indices to not handle components that have been > bound with multiple interfaces correctly. > --- > > Key: FELIX-3828 > URL: https://issues.apache.org/jira/browse/FELIX-3828 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > Both the Aspect and Adapter filter indices currently ignore the objectClass > property in returning service references through the > getAllServiceReferences() and the serviceChanged() methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3828) Aspect and Adapter filter indices to not handle components that have been bound with multiple interfaces correctly.
[ https://issues.apache.org/jira/browse/FELIX-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-3828. --- Resolution: Fixed Added check against objectClass. > Aspect and Adapter filter indices to not handle components that have been > bound with multiple interfaces correctly. > --- > > Key: FELIX-3828 > URL: https://issues.apache.org/jira/browse/FELIX-3828 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > Both the Aspect and Adapter filter indices currently ignore the objectClass > property in returning service references through the > getAllServiceReferences() and the serviceChanged() methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3828) Aspect and Adapter filter indices to not handle components that have been bound with multiple interfaces correctly.
Xander Uiterlinden created FELIX-3828: - Summary: Aspect and Adapter filter indices to not handle components that have been bound with multiple interfaces correctly. Key: FELIX-3828 URL: https://issues.apache.org/jira/browse/FELIX-3828 Project: Felix Issue Type: Bug Components: Dependency Manager Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden Both the Aspect and Adapter filter indices currently ignore the objectClass property in returning service references through the getAllServiceReferences() and the serviceChanged() methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3592) ServiceDependencyImpl does not copy the swapped callback in it's constructor.
[ https://issues.apache.org/jira/browse/FELIX-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-3592. --- Resolution: Fixed copied the swappedCallback value in the constructor of ServiceDependencyImpl > ServiceDependencyImpl does not copy the swapped callback in it's constructor. > - > > Key: FELIX-3592 > URL: https://issues.apache.org/jira/browse/FELIX-3592 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > ServiceDependencyImpl does not clone the swapped callback in it's constructor > causing the dependency to lose this parameter when being cloned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-3592) ServiceDependencyImpl does not copy the swapped callback in it's constructor.
[ https://issues.apache.org/jira/browse/FELIX-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3592 started by Xander Uiterlinden. > ServiceDependencyImpl does not copy the swapped callback in it's constructor. > - > > Key: FELIX-3592 > URL: https://issues.apache.org/jira/browse/FELIX-3592 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > ServiceDependencyImpl does not clone the swapped callback in it's constructor > causing the dependency to lose this parameter when being cloned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (FELIX-3592) ServiceDependencyImpl does not copy the swapped callback in it's constructor.
[ https://issues.apache.org/jira/browse/FELIX-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3592 stopped by Xander Uiterlinden. > ServiceDependencyImpl does not copy the swapped callback in it's constructor. > - > > Key: FELIX-3592 > URL: https://issues.apache.org/jira/browse/FELIX-3592 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > ServiceDependencyImpl does not clone the swapped callback in it's constructor > causing the dependency to lose this parameter when being cloned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3592) ServiceDependencyImpl does not copy the swapped callback in it's constructor.
Xander Uiterlinden created FELIX-3592: - Summary: ServiceDependencyImpl does not copy the swapped callback in it's constructor. Key: FELIX-3592 URL: https://issues.apache.org/jira/browse/FELIX-3592 Project: Felix Issue Type: Bug Components: Dependency Manager Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden ServiceDependencyImpl does not clone the swapped callback in it's constructor causing the dependency to lose this parameter when being cloned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Change of PMC Chair
Congrats! Regards, Xander Op 23 jun. 2012 17:47 schreef "Felix Meschberger" het volgende: > Hi all, > > Upon recommendation of the Felix PMC the Apache Board of Directors on its > last meeting appointed me to be the chair of the Apache Felix PMC. > > It is a pleasure for me take over from Richard. > > I would like to thank Richard for the long hard work he put into this. > This is going to be a really hard ride for me to get up to his level. > > Regards > Felix > > PS. In case someone's wondering, more details about the PMC chair role can > be found at [1]. > > [1] http://www.apache.org/foundation/how-it-works.html#pmc-chair > >
[jira] [Resolved] (FELIX-3564) Memory leak in Filterindex / ServiceRegistryCache
[ https://issues.apache.org/jira/browse/FELIX-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-3564. --- Resolution: Fixed See comment. > Memory leak in Filterindex / ServiceRegistryCache > - > > Key: FELIX-3564 > URL: https://issues.apache.org/jira/browse/FELIX-3564 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 > Environment: Linux Mint 12, x64, Dell E6520 >Reporter: Jan Hoeve >Assignee: Xander Uiterlinden > Labels: memory_leak > > The filter indexes in the ServiceRegistryCache caches ServiceListeners for a > faster lookup. > However, once a ServiceListener is stored in the cache, it will never be > released which will eventually lead to an OutOfMemoryError. > This is caused by the implementation of > BundleContextIntercepter#removeServiceListener. > While debugging, it appears the cache has no filterindex for arguments > null,null and thus leaving the listener in the cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3564) Memory leak in Filterindex / ServiceRegistryCache
[ https://issues.apache.org/jira/browse/FELIX-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396834#comment-13396834 ] Xander Uiterlinden commented on FELIX-3564: --- Fixed by a rather brute force call to FilterIndex.removeListener() for two reasons: - It aligns nicely with the BundleContext.removeListener() API which promises to do nothing when a listener is passed that is not available in this bundleContext; - Another solution would be to explicitly keep track in the ServiceRegistryCache of what listener is registered with which FilterIndex, It's cheaper in memory consumption to have the indices perform an unnecessary map.remove(). The extra processing overhead is negligible. > Memory leak in Filterindex / ServiceRegistryCache > - > > Key: FELIX-3564 > URL: https://issues.apache.org/jira/browse/FELIX-3564 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 > Environment: Linux Mint 12, x64, Dell E6520 >Reporter: Jan Hoeve >Assignee: Xander Uiterlinden > Labels: memory_leak > > The filter indexes in the ServiceRegistryCache caches ServiceListeners for a > faster lookup. > However, once a ServiceListener is stored in the cache, it will never be > released which will eventually lead to an OutOfMemoryError. > This is caused by the implementation of > BundleContextIntercepter#removeServiceListener. > While debugging, it appears the cache has no filterindex for arguments > null,null and thus leaving the listener in the cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-2292. --- Resolution: Fixed Committed the changes. Jetty is upgraded to 7.6.3. > Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) > -- > > Key: FELIX-2292 > URL: https://issues.apache.org/jira/browse/FELIX-2292 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Reporter: Jonathan Bardin > Fix For: http-2.2.2 > > Attachments: jetty7.patch, jetty7GoodFormat.patch, > upgrade-jetty7-latest-patch.patch > > > Hi, > This is a small improvement of the Http Service in order to use jetty 7.0.2 > (org.eclipse.jetty 7.0.2v20100331). > The patch is following. > Regards, > Jonathan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3564) Memory leak in Filterindex / ServiceRegistryCache
[ https://issues.apache.org/jira/browse/FELIX-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden reassigned FELIX-3564: - Assignee: Xander Uiterlinden > Memory leak in Filterindex / ServiceRegistryCache > - > > Key: FELIX-3564 > URL: https://issues.apache.org/jira/browse/FELIX-3564 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 > Environment: Linux Mint 12, x64, Dell E6520 >Reporter: Jan Hoeve >Assignee: Xander Uiterlinden > Labels: memory_leak > > The filter indexes in the ServiceRegistryCache caches ServiceListeners for a > faster lookup. > However, once a ServiceListener is stored in the cache, it will never be > released which will eventually lead to an OutOfMemoryError. > This is caused by the implementation of > BundleContextIntercepter#removeServiceListener. > While debugging, it appears the cache has no filterindex for arguments > null,null and thus leaving the listener in the cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: felix-http to jetty 7
Ok, thanks. I'll do that. I (locally) upgraded jetty to the latest 7 version (7.6.3) and therefore also had to upgrade the cometd dependencies which led me to the cometd sample project. I fixed the sample to work with the upgraded cometd version. Previously the example needed some cometd/dojo javascript files which were not included in the sample. Is this on purpose ? I think it'd be nice when the sample can actually be run out-of-the-box, and therefore would like to include these javascript files from dojo/cometd. Cometd itself is also published under the Apache 2.0 license. Are there any special requirements I have to watch when including these files in the cometd sample project? Cheers, Xander 2012/6/4 Rob Walker > Yep - I'd agree with Felix, if it works and takes us forward then go for > it. > > I worked with Richard on the original HTTP service, and do some occasional > mods/fixes to the newer felix-http one. So let me know if I can help out. > We use the HTTP service in our app. Once I have my current R&D stream done > and released (eta mid July) I can give it a spin to see if it all works our > side. > > -- Rob > > > On 03/06/2012 12:49 PM, Felix Meschberger wrote: > >> Hi, >> >> Originally Sten Roger Sandvik contributed the new HTTP Service >> implementation. Recently I did work in that area. But I am not constantly >> on. >> >> I suggest you go ahead and commit ... >> >> As long as you don't break anything, there should not be a big problem. >> >> Regards >> Felix >> >> Am 03.06.2012 um 11:25 schrieb Xander Uiterlinden: >> >> All, >>> >>> A while ago I submitted a patch to JIRA issue >>> https://issues.apache.org/**jira/browse/FELIX-2292<https://issues.apache.org/jira/browse/FELIX-2292>. >>> I would really like this >>> patch to be applied to the trunk. What would be the best way to get this >>> done ? I do have comitter rights on the Felix project since I'm doing >>> work >>> on the dependency manager, but am a bit hesitant to just commit code on >>> other subprojects. >>> >>> I have some other idea's/requirements for felix-http, who of us/you are >>> all >>> currently playing an active role in this subproject ? >>> >>> Cheers, >>> >>> Xander >>> >> > -- > > > Ascert - Taking systems to the edge > r...@ascert.com > +27 87 550 1701 > www.ascert.com > >
felix-http to jetty 7
All, A while ago I submitted a patch to JIRA issue https://issues.apache.org/jira/browse/FELIX-2292. I would really like this patch to be applied to the trunk. What would be the best way to get this done ? I do have comitter rights on the Felix project since I'm doing work on the dependency manager, but am a bit hesitant to just commit code on other subprojects. I have some other idea's/requirements for felix-http, who of us/you are all currently playing an active role in this subproject ? Cheers, Xander
Re: unexpected import package in DependencyManager ?
Hi Pierre, Thanks for noticing, although I should have myself :( Removed the import. Xander 2012/4/6 Pierre De Rop > Hello everyone, > > it seems there is a problem when compiling DependencyManager project, from > the trunk, because the following import is not resolved from > > dependencymanager/core/./src/main/java/org/apache/felix/dm/impl/index/AdapterFilterIndex.java > > import quicktime.std.music.ToneDescription; > > May be this import is not intentional ? > > kind regards; > /pierre >
[jira] [Commented] (FELIX-3424) Add support for changed callbacks on Aspect services.
[ https://issues.apache.org/jira/browse/FELIX-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248257#comment-13248257 ] Xander Uiterlinden commented on FELIX-3424: --- I think these comments belong to FELIX-3425. I agree with them and changed the two methods mentioned. > Add support for changed callbacks on Aspect services. > - > > Key: FELIX-3424 > URL: https://issues.apache.org/jira/browse/FELIX-3424 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Minor > > Recently changed callbacks have been introduced for service dependencies and > adapter services. This functionality would also be really useful on aspect > services. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3424) Add support for changed callbacks on Aspect services.
[ https://issues.apache.org/jira/browse/FELIX-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-3424. --- Resolution: Fixed Added optional swap callback for aspect services. > Add support for changed callbacks on Aspect services. > - > > Key: FELIX-3424 > URL: https://issues.apache.org/jira/browse/FELIX-3424 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Minor > > Recently changed callbacks have been introduced for service dependencies and > adapter services. This functionality would also be really useful on aspect > services. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3425) Provide a filter index for adapter services.
[ https://issues.apache.org/jira/browse/FELIX-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-3425. --- Resolution: Fixed Added an initial implementation of an adapter filter index. This filter index can be enabled by the *adapter* index code. > Provide a filter index for adapter services. > > > Key: FELIX-3425 > URL: https://issues.apache.org/jira/browse/FELIX-3425 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > The adapter services have quite an expensive filter for their service > dependency on the adapted service. An additional filter index should be > provided to cache these. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3425) Provide a filter index for adapter services.
Provide a filter index for adapter services. Key: FELIX-3425 URL: https://issues.apache.org/jira/browse/FELIX-3425 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Xander Uiterlinden Assignee: Xander Uiterlinden The adapter services have quite an expensive filter for their service dependency on the adapted service. An additional filter index should be provided to cache these. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (FELIX-3425) Provide a filter index for adapter services.
[ https://issues.apache.org/jira/browse/FELIX-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3425 stopped by Xander Uiterlinden. > Provide a filter index for adapter services. > > > Key: FELIX-3425 > URL: https://issues.apache.org/jira/browse/FELIX-3425 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > The adapter services have quite an expensive filter for their service > dependency on the adapted service. An additional filter index should be > provided to cache these. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-3425) Provide a filter index for adapter services.
[ https://issues.apache.org/jira/browse/FELIX-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3425 started by Xander Uiterlinden. > Provide a filter index for adapter services. > > > Key: FELIX-3425 > URL: https://issues.apache.org/jira/browse/FELIX-3425 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > The adapter services have quite an expensive filter for their service > dependency on the adapted service. An additional filter index should be > provided to cache these. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (FELIX-3424) Add support for changed callbacks on Aspect services.
[ https://issues.apache.org/jira/browse/FELIX-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3424 stopped by Xander Uiterlinden. > Add support for changed callbacks on Aspect services. > - > > Key: FELIX-3424 > URL: https://issues.apache.org/jira/browse/FELIX-3424 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Minor > > Recently changed callbacks have been introduced for service dependencies and > adapter services. This functionality would also be really useful on aspect > services. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3423) AdapterImpl copies the DependencyManager.ASPECT service property when adapting an aspect.
[ https://issues.apache.org/jira/browse/FELIX-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden resolved FELIX-3423. --- Resolution: Fixed Prevented the copy of the DependencyManager.ASPECT service property to the adapter's service properties. > AdapterImpl copies the DependencyManager.ASPECT service property when > adapting an aspect. > - > > Key: FELIX-3423 > URL: https://issues.apache.org/jira/browse/FELIX-3423 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > AdapterImpl copies the DependencyManager.ASPECT service property to the > service properties of the adapter service when adapting an aspect. It should > not copy this property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-3424) Add support for changed callbacks on Aspect services.
[ https://issues.apache.org/jira/browse/FELIX-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3424 started by Xander Uiterlinden. > Add support for changed callbacks on Aspect services. > - > > Key: FELIX-3424 > URL: https://issues.apache.org/jira/browse/FELIX-3424 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Minor > > Recently changed callbacks have been introduced for service dependencies and > adapter services. This functionality would also be really useful on aspect > services. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (FELIX-3423) AdapterImpl copies the DependencyManager.ASPECT service property when adapting an aspect.
[ https://issues.apache.org/jira/browse/FELIX-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3423 stopped by Xander Uiterlinden. > AdapterImpl copies the DependencyManager.ASPECT service property when > adapting an aspect. > - > > Key: FELIX-3423 > URL: https://issues.apache.org/jira/browse/FELIX-3423 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > AdapterImpl copies the DependencyManager.ASPECT service property to the > service properties of the adapter service when adapting an aspect. It should > not copy this property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (FELIX-3423) AdapterImpl copies the DependencyManager.ASPECT service property when adapting an aspect.
[ https://issues.apache.org/jira/browse/FELIX-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-3423 started by Xander Uiterlinden. > AdapterImpl copies the DependencyManager.ASPECT service property when > adapting an aspect. > - > > Key: FELIX-3423 > URL: https://issues.apache.org/jira/browse/FELIX-3423 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > AdapterImpl copies the DependencyManager.ASPECT service property to the > service properties of the adapter service when adapting an aspect. It should > not copy this property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3423) AdapterImpl copies the DependencyManager.ASPECT service property when adapting an aspect.
[ https://issues.apache.org/jira/browse/FELIX-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden reassigned FELIX-3423: - Assignee: Xander Uiterlinden > AdapterImpl copies the DependencyManager.ASPECT service property when > adapting an aspect. > - > > Key: FELIX-3423 > URL: https://issues.apache.org/jira/browse/FELIX-3423 > Project: Felix > Issue Type: Bug > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden > > AdapterImpl copies the DependencyManager.ASPECT service property to the > service properties of the adapter service when adapting an aspect. It should > not copy this property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3424) Add support for changed callbacks on Aspect services.
[ https://issues.apache.org/jira/browse/FELIX-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden reassigned FELIX-3424: - Assignee: Xander Uiterlinden > Add support for changed callbacks on Aspect services. > - > > Key: FELIX-3424 > URL: https://issues.apache.org/jira/browse/FELIX-3424 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Assignee: Xander Uiterlinden >Priority: Minor > > Recently changed callbacks have been introduced for service dependencies and > adapter services. This functionality would also be really useful on aspect > services. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3424) Add support for changed callbacks on Aspect services.
Add support for changed callbacks on Aspect services. - Key: FELIX-3424 URL: https://issues.apache.org/jira/browse/FELIX-3424 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Xander Uiterlinden Priority: Minor Recently changed callbacks have been introduced for service dependencies and adapter services. This functionality would also be really useful on aspect services. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3423) AdapterImpl copies the DependencyManager.ASPECT service property when adapting an aspect.
AdapterImpl copies the DependencyManager.ASPECT service property when adapting an aspect. - Key: FELIX-3423 URL: https://issues.apache.org/jira/browse/FELIX-3423 Project: Felix Issue Type: Bug Components: Dependency Manager Reporter: Xander Uiterlinden AdapterImpl copies the DependencyManager.ASPECT service property to the service properties of the adapter service when adapting an aspect. It should not copy this property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229151#comment-13229151 ] Xander Uiterlinden commented on FELIX-2292: --- Find enclosed a patch to upgrade the jetty server to 7.6.1.v20120215. > Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) > -- > > Key: FELIX-2292 > URL: https://issues.apache.org/jira/browse/FELIX-2292 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Reporter: Jonathan Bardin > Fix For: http-2.2.2 > > Attachments: jetty7.patch, jetty7GoodFormat.patch, > upgrade-jetty7-latest-patch.patch > > > Hi, > This is a small improvement of the Http Service in order to use jetty 7.0.2 > (org.eclipse.jetty 7.0.2v20100331). > The patch is following. > Regards, > Jonathan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-2292: -- Attachment: upgrade-jetty7-latest-patch.patch > Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) > -- > > Key: FELIX-2292 > URL: https://issues.apache.org/jira/browse/FELIX-2292 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Reporter: Jonathan Bardin > Fix For: http-2.2.2 > > Attachments: jetty7.patch, jetty7GoodFormat.patch, > upgrade-jetty7-latest-patch.patch > > > Hi, > This is a small improvement of the Http Service in order to use jetty 7.0.2 > (org.eclipse.jetty 7.0.2v20100331). > The patch is following. > Regards, > Jonathan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225170#comment-13225170 ] Xander Uiterlinden commented on FELIX-2292: --- The latest comment on this issue is quite some time ago. For our project we actually need Jetty 7 and would like to use felix.http. Is it still intended to include Jetty 7 in felix.http ? > Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) > -- > > Key: FELIX-2292 > URL: https://issues.apache.org/jira/browse/FELIX-2292 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Reporter: Jonathan Bardin > Fix For: http-2.2.2 > > Attachments: jetty7.patch, jetty7GoodFormat.patch > > > Hi, > This is a small improvement of the Http Service in order to use jetty 7.0.2 > (org.eclipse.jetty 7.0.2v20100331). > The patch is following. > Regards, > Jonathan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Felix http cometd support
Hi, I've been looking into using the felix http cometd support in our application. I used the "http bundle" from the trunk but ran into a few issues there: - I wanted to use the CometdService to get a hold of the Bayeux object but the http bundle does currently not export the org.apache.felix.http.cometd package; - To be able to relate cometd messages to the current user's session we need access to this session through bayeux.getCurrentRequest(). The Bayeax only offers this request when the "requestAvailable" parameter is set to true in the init parameters of the ContinuationCometdServlet. It seems like there are currently no means to configure these parameters externally. Any thoughts on these issues before submitting them to JIRA ? Regards, Xander Uiterlinden
[jira] [Updated] (FELIX-3186) Adapter services do not get their adapted services transparently replaced when an aspect is added to them.
[ https://issues.apache.org/jira/browse/FELIX-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-3186: -- Attachment: adapteronsomethingwithaspecttestpatch.patch adapteronsomethingwithaspectpatch.patch Find the enclosed patch which resolves the issue. It also adds the possibility to provide a swap callback method for an adapter service which is called when the service the adapter adapts is changed due to an aspect becoming (un)available. The modified adapter tests are also included in a separate patch file. > Adapter services do not get their adapted services transparently replaced > when an aspect is added to them. > -- > > Key: FELIX-3186 > URL: https://issues.apache.org/jira/browse/FELIX-3186 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 > Environment: mac-osx >Reporter: Xander Uiterlinden > Labels: bug > Fix For: dependencymanager-3.0.0 > > Attachments: AspectAdapterTest.java, > adapteronsomethingwithaspectpatch.patch, > adapteronsomethingwithaspecttestpatch.patch > > > A service consumer consumes an adapter service. The adapter service adapts a > service provider. > An aspect is added to the service provider. This should not impact the > service consumer. > Expected behavior is transparent replacement of the service the adapter > adapts with the aspect service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3292) Allow passing of resource properties to a resource handler for use with resource adapters.
[ https://issues.apache.org/jira/browse/FELIX-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-3292: -- Attachment: resourceadapterpatch2.patch Find enclosed a revised patch which merges the standard and custom resource properties. > Allow passing of resource properties to a resource handler for use with > resource adapters. > -- > > Key: FELIX-3292 > URL: https://issues.apache.org/jira/browse/FELIX-3292 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden >Assignee: Marcel Offermans > Labels: patch > Attachments: resourceadapterpatch2.patch, resourcepatch.patch > > > Currently we're using the dependency manager in our project. A feature we > extensively use is the resource adapter. > The resource adapter service gets access to a resource through the > abstraction of a URL. This is a nice abstraction > but raises challenges whenever an implementation requires more properties of > the resource, e.g. the last modification date > or the encoding. > At the moment we're working our way around it by creating implementing a > custom URLHandler. > It would be nicer if the resource adapter could be provided with a set of > optional properties. My suggestion would > be to extend the added(URL resource) method of the ResourceHandler with an > additional argument holding a > untyped set of properties. When provided these will be injected into the > resource adapter implementation. > I'll attach a patch to this issue with the implementation of this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3292) Allow passing of resource properties to a resource handler for use with resource adapters.
[ https://issues.apache.org/jira/browse/FELIX-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178403#comment-13178403 ] Xander Uiterlinden commented on FELIX-3292: --- I agree with your comments. Merging the properties into a single set is makes more sense and addresses nearly all other comments. > Allow passing of resource properties to a resource handler for use with > resource adapters. > -- > > Key: FELIX-3292 > URL: https://issues.apache.org/jira/browse/FELIX-3292 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden >Assignee: Marcel Offermans > Labels: patch > Attachments: resourceadapterpatch2.patch, resourcepatch.patch > > > Currently we're using the dependency manager in our project. A feature we > extensively use is the resource adapter. > The resource adapter service gets access to a resource through the > abstraction of a URL. This is a nice abstraction > but raises challenges whenever an implementation requires more properties of > the resource, e.g. the last modification date > or the encoding. > At the moment we're working our way around it by creating implementing a > custom URLHandler. > It would be nicer if the resource adapter could be provided with a set of > optional properties. My suggestion would > be to extend the added(URL resource) method of the ResourceHandler with an > additional argument holding a > untyped set of properties. When provided these will be injected into the > resource adapter implementation. > I'll attach a patch to this issue with the implementation of this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3292) Allow passing of resource properties to a resource handler for use with resource adapters.
[ https://issues.apache.org/jira/browse/FELIX-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-3292: -- Attachment: resourcepatch.patch patch introducing the possibility to use resource properties with resource adapters. > Allow passing of resource properties to a resource handler for use with > resource adapters. > -- > > Key: FELIX-3292 > URL: https://issues.apache.org/jira/browse/FELIX-3292 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Reporter: Xander Uiterlinden > Labels: patch > Attachments: resourcepatch.patch > > > Currently we're using the dependency manager in our project. A feature we > extensively use is the resource adapter. > The resource adapter service gets access to a resource through the > abstraction of a URL. This is a nice abstraction > but raises challenges whenever an implementation requires more properties of > the resource, e.g. the last modification date > or the encoding. > At the moment we're working our way around it by creating implementing a > custom URLHandler. > It would be nicer if the resource adapter could be provided with a set of > optional properties. My suggestion would > be to extend the added(URL resource) method of the ResourceHandler with an > additional argument holding a > untyped set of properties. When provided these will be injected into the > resource adapter implementation. > I'll attach a patch to this issue with the implementation of this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3292) Allow passing of resource properties to a resource handler for use with resource adapters.
Allow passing of resource properties to a resource handler for use with resource adapters. -- Key: FELIX-3292 URL: https://issues.apache.org/jira/browse/FELIX-3292 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Xander Uiterlinden Currently we're using the dependency manager in our project. A feature we extensively use is the resource adapter. The resource adapter service gets access to a resource through the abstraction of a URL. This is a nice abstraction but raises challenges whenever an implementation requires more properties of the resource, e.g. the last modification date or the encoding. At the moment we're working our way around it by creating implementing a custom URLHandler. It would be nicer if the resource adapter could be provided with a set of optional properties. My suggestion would be to extend the added(URL resource) method of the ResourceHandler with an additional argument holding a untyped set of properties. When provided these will be injected into the resource adapter implementation. I'll attach a patch to this issue with the implementation of this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: Dependency manager feature suggestion: Allow passing resource attributes to resource adapters
Hi all, I'm afraid I sent this message to the wrong list in the first attempt. Please find my feature suggestion below and let me know what you think. -- Forwarded message -- From: Xander Uiterlinden Date: 2011/12/13 Subject: Dependency manager feature suggestion: Allow passing resource attributes to resource adapters To: dev-h...@felix.apache.org Hi all, Currently we're using the dependency manager in our project. A feature we extensively use is the resource adapter. The resource adapter service gets access to a resource through the abstraction of a URL. This is a nice abstraction but raises challenges whenever an implementation requires more properties of the resource, e.g. the last modification date or the encoding. At the moment we're working our way around it by creating implementing a custom URLHandler. It would be nicer if the resource adapter could be provided with a set of optional properties. My suggestion would be to extend the added(URL resource) method of the ResourceHandler with an additional argument holding a untyped set of properties. When provided these will be injected into the resource adapter implementation. Please let me know what you think. Cheers, Xander Uiterlinden
[jira] [Closed] (FELIX-3217) ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services.
[ https://issues.apache.org/jira/browse/FELIX-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden closed FELIX-3217. - Resolution: Duplicate > ServiceTracker performance is not optimal with a service dependency that > results in n-thousands of injected services. > - > > Key: FELIX-3217 > URL: https://issues.apache.org/jira/browse/FELIX-3217 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Environment: MacOS Snow Leopard. > Reporter: Xander Uiterlinden > > ServiceTracker performance is not optimal with a service dependency that > results in n-thousands of injected services. > The ServiceTracker.setInitial() implementation has a nested loop causing > performance issues, e.g. quatratic lookup of service properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3218) ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services.
ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services. - Key: FELIX-3218 URL: https://issues.apache.org/jira/browse/FELIX-3218 Project: Felix Issue Type: Improvement Components: Dependency Manager Environment: MacOS Snow Leopard. Reporter: Xander Uiterlinden Attachments: ServiceTracker.patch ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services. The ServiceTracker.setInitial() implementation has a nested loop causing performance issues, e.g. quatratic lookup of service properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3218) ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services.
[ https://issues.apache.org/jira/browse/FELIX-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-3218: -- Attachment: ServiceTracker.patch See this attached patch to resolve the issue. > ServiceTracker performance is not optimal with a service dependency that > results in n-thousands of injected services. > - > > Key: FELIX-3218 > URL: https://issues.apache.org/jira/browse/FELIX-3218 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Environment: MacOS Snow Leopard. > Reporter: Xander Uiterlinden > Attachments: ServiceTracker.patch > > > ServiceTracker performance is not optimal with a service dependency that > results in n-thousands of injected services. > The ServiceTracker.setInitial() implementation has a nested loop causing > performance issues, e.g. quatratic lookup of service properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3217) ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services.
ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services. - Key: FELIX-3217 URL: https://issues.apache.org/jira/browse/FELIX-3217 Project: Felix Issue Type: Improvement Components: Dependency Manager Environment: MacOS Snow Leopard. Reporter: Xander Uiterlinden ServiceTracker performance is not optimal with a service dependency that results in n-thousands of injected services. The ServiceTracker.setInitial() implementation has a nested loop causing performance issues, e.g. quatratic lookup of service properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2816) dependency manager calls init() twice
[
https://issues.apache.org/jira/browse/FELIX-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144113#comment-13144113
]
Xander Uiterlinden commented on FELIX-2816:
---
This is most likely caused by overlapping init methods. One for the servlet
init and one for the component lifecycle callback method. It can be resolved by
specifying another name for the init callback for the component lifecycle by
using the Component.setCallbacks method.
> dependency manager calls init() twice
> -
>
> Key: FELIX-2816
> URL: https://issues.apache.org/jira/browse/FELIX-2816
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Reporter: Derek Baum
>
> Log messages are placed at the beginning of the component lifecycle methods
> (init, start, stop, destroy).
> The number is the hashCode, which shows that init() is called twice on the
> same Object, without intervening stop() or destroy():
> [Debug] [ ] MyServlet 1397120162 init: update=60
> [Debug] [ ] MyServlet 1397120162 start: endpoint=/myservlet period=60
> history=null
> [Debug] [ ] MyServlet 1397120162 init: update=60
> [Debug] [ ] MyServlet add: gx2
> [Debug] [ ] MyServlet add: denzil
> The component is created as follows:
> manager.add(createComponent()
> .setImplementation(MyServlet.class)
> .add(createConfigurationDependency()
> .setPropagate(true)
> .setPid(PID))
> .add(createServiceDependency()
>
> .setService(HttpService.class).setRequired(true))
> .add(createServiceDependency()
> .setService(UserAdmin.class).setRequired(true))
> .add(createServiceDependency()
>
> .setService(MyStateStore.class).setRequired(false)
> .setCallbacks("addStore",
> "removeStore"))
> .add(createServiceDependency()
>
> .setService(HistoryService.class).setRequired(false))
> .add(createServiceDependency()
>
> .setService(LogService.class).setRequired(false))
> );
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
[ https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-3201: -- Attachment: dm-test-patch.txt dm-core-patch.txt Attached a both a patch to the ServiceDependency, ServiceUtil and ServiceDependencyImpl which implements the improvement described. It also includes a test case. > Offer more functional callback methods for services that have aspects on them. > -- > > Key: FELIX-3201 > URL: https://issues.apache.org/jira/browse/FELIX-3201 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager > Environment: n/a > Reporter: Xander Uiterlinden > Labels: features > Attachments: dm-core-patch.txt, dm-test-patch.txt > > > When programmatically adding service dependencies using the Apache felix > dependency manager there are two ways to have the component brought its > dependencies when they come available. These are the following: > - have the service injected in the component; this is usually sufficient for > cases where there's only one service expected to satisfy the dependency > (1-to-1) . > - explicitly specify callback methods; callbacks can be used when there might > be more than one service satisfying the dependency (1-to-n). When a > dependency is marked optional, the callback method also helps to determine > when the dependency actually became satisfied. > When using callback methods with the dependency manager you can specify the > following callbacks: > - added; gets called when the service required has become available. > - changed; gets called when the service properties of a added required > service have changed. > - removed; gets called when the service required has become unavailable. > At first these callbacks seem pretty simple. Just add the service to the > component's internal administration on the added callback and remove it from > the administration whenever the removed callback is called. But, the > dependency manager also supports the concept of aspect services which make > using the callback method in a correct way a bit more difficult. > Aspect services are services that are put on top of another service while > still implementing the original service's interface. They allow you to > implement cross-cutting functional requirements. > In the OSGi service registry aspect services are individual services just > like 'regular' singleton services. When using callback methods for > dependencies a component is informed of the add/remove of an aspect service, > just like it is when a 'regular' service is added/removed. When using > injection for dependencies the aspect is transparently injected. The > callbacks also handling aspect services the same way as 'regular' services > makes it difficult for a component developer to correctly implement these > callbacks. > For example take the following scenario: > Component A expresses a service dependency to Service B. > Without any aspects in the container the following callbacks would be added > on Component A. > added(Service B) > But whenever there's an aspect running on top of Service B, the order of > callbacks would be as follows: > added(Service B) > added(Service B aspect) > removed(Service B) > When backed by a typical HashMap administration this would result in: > put(B.id, B) > put(B.id, B) > remove(B.id) > This sequence would result in an empty Map, which is not a desirable > situation. In order to ease the dependency handling an additional callback > method is needed which hides the complexity as described above and translates > the callbacks to the following more functional callbacks: > added; called when the service required has become available. > swapped; called when the service required needs to be replaced due to add or > removal of an aspect. This to be sure the component uses the aspect that's on > top of the aspect chain for the required service. > changed; called when the service properties of an added required service have > changed. > removed; called when the service required has become unavailable. > With these callbacks a developer does not have to worry about the possible > sequences in which added/removed can occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
Offer more functional callback methods for services that have aspects on them. -- Key: FELIX-3201 URL: https://issues.apache.org/jira/browse/FELIX-3201 Project: Felix Issue Type: Improvement Components: Dependency Manager Environment: n/a Reporter: Xander Uiterlinden When programmatically adding service dependencies using the Apache felix dependency manager there are two ways to have the component brought its dependencies when they come available. These are the following: - have the service injected in the component; this is usually sufficient for cases where there's only one service expected to satisfy the dependency (1-to-1) . - explicitly specify callback methods; callbacks can be used when there might be more than one service satisfying the dependency (1-to-n). When a dependency is marked optional, the callback method also helps to determine when the dependency actually became satisfied. When using callback methods with the dependency manager you can specify the following callbacks: - added; gets called when the service required has become available. - changed; gets called when the service properties of a added required service have changed. - removed; gets called when the service required has become unavailable. At first these callbacks seem pretty simple. Just add the service to the component's internal administration on the added callback and remove it from the administration whenever the removed callback is called. But, the dependency manager also supports the concept of aspect services which make using the callback method in a correct way a bit more difficult. Aspect services are services that are put on top of another service while still implementing the original service's interface. They allow you to implement cross-cutting functional requirements. In the OSGi service registry aspect services are individual services just like 'regular' singleton services. When using callback methods for dependencies a component is informed of the add/remove of an aspect service, just like it is when a 'regular' service is added/removed. When using injection for dependencies the aspect is transparently injected. The callbacks also handling aspect services the same way as 'regular' services makes it difficult for a component developer to correctly implement these callbacks. For example take the following scenario: Component A expresses a service dependency to Service B. Without any aspects in the container the following callbacks would be added on Component A. added(Service B) But whenever there's an aspect running on top of Service B, the order of callbacks would be as follows: added(Service B) added(Service B aspect) removed(Service B) When backed by a typical HashMap administration this would result in: put(B.id, B) put(B.id, B) remove(B.id) This sequence would result in an empty Map, which is not a desirable situation. In order to ease the dependency handling an additional callback method is needed which hides the complexity as described above and translates the callbacks to the following more functional callbacks: added; called when the service required has become available. swapped; called when the service required needs to be replaced due to add or removal of an aspect. This to be sure the component uses the aspect that's on top of the aspect chain for the required service. changed; called when the service properties of an added required service have changed. removed; called when the service required has become unavailable. With these callbacks a developer does not have to worry about the possible sequences in which added/removed can occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3186) Adapter services do not get their adapted services transparently replaced when an aspect is added to them.
[ https://issues.apache.org/jira/browse/FELIX-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135140#comment-13135140 ] Xander Uiterlinden commented on FELIX-3186: --- The testcase also finishes with a warning which needs to be checked: WARNING: Invocation of 'added' failed. (java.lang.IllegalStateException: Can only register services while bundle is active or activating.) > Adapter services do not get their adapted services transparently replaced > when an aspect is added to them. > -- > > Key: FELIX-3186 > URL: https://issues.apache.org/jira/browse/FELIX-3186 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 > Environment: mac-osx >Reporter: Xander Uiterlinden > Labels: bug > Fix For: dependencymanager-3.0.0 > > Attachments: AspectAdapterTest.java > > > A service consumer consumes an adapter service. The adapter service adapts a > service provider. > An aspect is added to the service provider. This should not impact the > service consumer. > Expected behavior is transparent replacement of the service the adapter > adapts with the aspect service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3186) Adapter services do not get their adapted services transparently replaced when an aspect is added to them.
Adapter services do not get their adapted services transparently replaced when an aspect is added to them. -- Key: FELIX-3186 URL: https://issues.apache.org/jira/browse/FELIX-3186 Project: Felix Issue Type: Bug Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Environment: mac-osx Reporter: Xander Uiterlinden Fix For: dependencymanager-3.0.0 Attachments: AspectAdapterTest.java A service consumer consumes an adapter service. The adapter service adapts a service provider. An aspect is added to the service provider. This should not impact the service consumer. Expected behavior is transparent replacement of the service the adapter adapts with the aspect service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3186) Adapter services do not get their adapted services transparently replaced when an aspect is added to them.
[ https://issues.apache.org/jira/browse/FELIX-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xander Uiterlinden updated FELIX-3186: -- Attachment: AspectAdapterTest.java See attached testcase for reproduction of the issue. > Adapter services do not get their adapted services transparently replaced > when an aspect is added to them. > -- > > Key: FELIX-3186 > URL: https://issues.apache.org/jira/browse/FELIX-3186 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 > Environment: mac-osx >Reporter: Xander Uiterlinden > Labels: bug > Fix For: dependencymanager-3.0.0 > > Attachments: AspectAdapterTest.java > > > A service consumer consumes an adapter service. The adapter service adapts a > service provider. > An aspect is added to the service provider. This should not impact the > service consumer. > Expected behavior is transparent replacement of the service the adapter > adapts with the aspect service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
