[jira] [Commented] (FELIX-4168) Adapter services don't call callbacks for existing services when adding a required dependency after setup
[ https://issues.apache.org/jira/browse/FELIX-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184461#comment-14184461 ] Angelo van der Sijpt commented on FELIX-4168: - Fine with me, thanks! > Adapter services don't call callbacks for existing services when adding a > required dependency after setup > - > > Key: FELIX-4168 > URL: https://issues.apache.org/jira/browse/FELIX-4168 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 >Reporter: Angelo van der Sijpt > Attachments: FELIX_4168AdapterWithDynamicallyAddedDependencies.java > > > I have the following scenario, > - an adapter service comes up for some underlying service; > - some time during start (either during init(), start(), or add()), I add a > required service dependency, with callbacks; > - the service on which we depend, is already available. > I would expect the callbacks get called during startup of the component. > However, this doesn't happen. > I have been able to localize this a little further, > - this only happens when the service is already available (i.e., services > that show up later work fine), > - the service does not get pulled because of the new dependency (which is > should), > - it doesn't matter which callback function I register the depencies from, > - it can be solved partially by setting the required dependencies to be > instanceBound(), but then still the service doesn't get pulled before a > service becomes available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Accept PojoSR code donation
+1 Nice one! On 11 Mar 2014, at 15:29, Marcel Offermans wrote: > +1 > > On Mar 5, 2014 3:49 PM, Guillaume Nodet wrote: > Karl Pauls is willing to donate PojoSR (https://code.google.com/p/pojosr/) > to Felix. > > This vote is about officially accepting the donation. > > [ ] +1 Accept PojoSR code into Felix > [ ] -1 Do not > > Cheers, > Guillaume Nodet
[jira] [Commented] (FELIX-4168) Adapter services don't call callbacks for existing services when adding a required dependency after setup
[ https://issues.apache.org/jira/browse/FELIX-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13712099#comment-13712099 ] Angelo van der Sijpt commented on FELIX-4168: - I agree that some additional documentation on the sure of instanceBound is helpful, probably located somewhere near the description of callback methods. I now use setInstanceBound(true), and that works fine. That said, I don't think we should make an exception for dependencies which are already available: I like the peace of mind that when I declare my dependencies correctly, the system will always behave in the same way. > Adapter services don't call callbacks for existing services when adding a > required dependency after setup > - > > Key: FELIX-4168 > URL: https://issues.apache.org/jira/browse/FELIX-4168 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 >Reporter: Angelo van der Sijpt > Attachments: FELIX_4168AdapterWithDynamicallyAddedDependencies.java > > > I have the following scenario, > - an adapter service comes up for some underlying service; > - some time during start (either during init(), start(), or add()), I add a > required service dependency, with callbacks; > - the service on which we depend, is already available. > I would expect the callbacks get called during startup of the component. > However, this doesn't happen. > I have been able to localize this a little further, > - this only happens when the service is already available (i.e., services > that show up later work fine), > - the service does not get pulled because of the new dependency (which is > should), > - it doesn't matter which callback function I register the depencies from, > - it can be solved partially by setting the required dependencies to be > instanceBound(), but then still the service doesn't get pulled before a > service becomes available. -- 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-4168) Adapter services don't call callbacks for existing services when adding a required dependency after setup
[ https://issues.apache.org/jira/browse/FELIX-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710852#comment-13710852 ] Angelo van der Sijpt commented on FELIX-4168: - Your comment makes a lot of sense to me. So yes, as far as I'm concerned, we can close this issue with "Angelo, RTFM." > Adapter services don't call callbacks for existing services when adding a > required dependency after setup > - > > Key: FELIX-4168 > URL: https://issues.apache.org/jira/browse/FELIX-4168 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 >Reporter: Angelo van der Sijpt > Attachments: FELIX_4168AdapterWithDynamicallyAddedDependencies.java > > > I have the following scenario, > - an adapter service comes up for some underlying service; > - some time during start (either during init(), start(), or add()), I add a > required service dependency, with callbacks; > - the service on which we depend, is already available. > I would expect the callbacks get called during startup of the component. > However, this doesn't happen. > I have been able to localize this a little further, > - this only happens when the service is already available (i.e., services > that show up later work fine), > - the service does not get pulled because of the new dependency (which is > should), > - it doesn't matter which callback function I register the depencies from, > - it can be solved partially by setting the required dependencies to be > instanceBound(), but then still the service doesn't get pulled before a > service becomes available. -- 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-4168) Adapter services don't call callbacks for existing services when adding a required dependency after setup
[ https://issues.apache.org/jira/browse/FELIX-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt updated FELIX-4168: Attachment: FELIX_4168AdapterWithDynamicallyAddedDependencies.java I added a testcase which shows the initial issue. However, I suspect there is a little more going on than this. > Adapter services don't call callbacks for existing services when adding a > required dependency after setup > - > > Key: FELIX-4168 > URL: https://issues.apache.org/jira/browse/FELIX-4168 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.1.0 >Reporter: Angelo van der Sijpt > Attachments: FELIX_4168AdapterWithDynamicallyAddedDependencies.java > > > I have the following scenario, > - an adapter service comes up for some underlying service; > - some time during start (either during init(), start(), or add()), I add a > required service dependency, with callbacks; > - the service on which we depend, is already available. > I would expect the callbacks get called during startup of the component. > However, this doesn't happen. > I have been able to localize this a little further, > - this only happens when the service is already available (i.e., services > that show up later work fine), > - the service does not get pulled because of the new dependency (which is > should), > - it doesn't matter which callback function I register the depencies from, > - it can be solved partially by setting the required dependencies to be > instanceBound(), but then still the service doesn't get pulled before a > service becomes available. -- 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-4168) Adapter services don't call callbacks for existing services when adding a required dependency after setup
Angelo van der Sijpt created FELIX-4168: --- Summary: Adapter services don't call callbacks for existing services when adding a required dependency after setup Key: FELIX-4168 URL: https://issues.apache.org/jira/browse/FELIX-4168 Project: Felix Issue Type: Bug Components: Dependency Manager Affects Versions: dependencymanager-3.1.0 Reporter: Angelo van der Sijpt Attachments: FELIX_4168AdapterWithDynamicallyAddedDependencies.java I have the following scenario, - an adapter service comes up for some underlying service; - some time during start (either during init(), start(), or add()), I add a required service dependency, with callbacks; - the service on which we depend, is already available. I would expect the callbacks get called during startup of the component. However, this doesn't happen. I have been able to localize this a little further, - this only happens when the service is already available (i.e., services that show up later work fine), - the service does not get pulled because of the new dependency (which is should), - it doesn't matter which callback function I register the depencies from, - it can be solved partially by setting the required dependencies to be instanceBound(), but then still the service doesn't get pulled before a service becomes available. -- 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] [Closed] (FELIX-3913) Felix Event Admin documentation does not state its configuration PID
[ https://issues.apache.org/jira/browse/FELIX-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt closed FELIX-3913. --- Right, the PID looks okay. However, did you notice there is still some work to be done on the rest of that section? (For instance, the table still needs to be ported.) > Felix Event Admin documentation does not state its configuration PID > > > Key: FELIX-3913 > URL: https://issues.apache.org/jira/browse/FELIX-3913 > Project: Felix > Issue Type: Bug > Components: Event Admin > Reporter: Angelo van der Sijpt >Assignee: Felix Meschberger >Priority: Trivial > Attachments: > FELIX-3913-Included-the-Event-Admin-PID-in-its-documentation.patch > > > The documentation for Event Admin on > http://felix.apache.org/site/apache-felix-event-admin.html states that it can > be configured using a Configuration Admin, but omits the PID of the service > to configure. -- 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-3913) Felix Event Admin documentation does not state its configuration PID
[ https://issues.apache.org/jira/browse/FELIX-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt updated FELIX-3913: Attachment: FELIX-3913-Included-the-Event-Admin-PID-in-its-documentation.patch I've included a patch for the site which includes this information. > Felix Event Admin documentation does not state its configuration PID > > > Key: FELIX-3913 > URL: https://issues.apache.org/jira/browse/FELIX-3913 > Project: Felix > Issue Type: Bug > Components: Event Admin > Reporter: Angelo van der Sijpt >Priority: Trivial > Attachments: > FELIX-3913-Included-the-Event-Admin-PID-in-its-documentation.patch > > > The documentation for Event Admin on > http://felix.apache.org/site/apache-felix-event-admin.html states that it can > be configured using a Configuration Admin, but omits the PID of the service > to configure. -- 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-3913) Felix Event Admin documentation does not state its configuration PID
Angelo van der Sijpt created FELIX-3913: --- Summary: Felix Event Admin documentation does not state its configuration PID Key: FELIX-3913 URL: https://issues.apache.org/jira/browse/FELIX-3913 Project: Felix Issue Type: Bug Components: Event Admin Reporter: Angelo van der Sijpt Priority: Trivial The documentation for Event Admin on http://felix.apache.org/site/apache-felix-event-admin.html states that it can be configured using a Configuration Admin, but omits the PID of the service to configure. -- 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=13574501#comment-13574501 ] Angelo van der Sijpt commented on FELIX-3856: - Right, http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/apache-felix-dependency-manager-reference-guide.html looks better. It also (now) is the first hit in Google. > 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 >Assignee: Marcel Offermans > Attachments: FELIX-3856-Filter-indices-documentation.patch, > Felix-3856-Filter-indices-for-aspects-and-adapters.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=13574360#comment-13574360 ] Angelo van der Sijpt commented on FELIX-3856: - I've noticed the changes have been committed quite a while ago, but the generated page ( http://felix.apache.org/site/apache-felix-dependency-manager-reference-guide.html ) still lists filters as 'experimental'. Is something up with the mirroring or generation? > 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 >Assignee: Marcel Offermans > Attachments: FELIX-3856-Filter-indices-documentation.patch, > Felix-3856-Filter-indices-for-aspects-and-adapters.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
Re: [VOTE] Release Felix Dependency Manager Core, Annotation, Runtime version 3.1.0 and Compat, Shell version 3.0.1
+1 (extremely non-binding) I verified it with an Android project with lots of services, and the indexing speedup is significant. Angelo On Jan 24, 2013, at 9:57 AM, Guillaume Nodet wrote: > +1 > > > On Wed, Jan 23, 2013 at 4:14 PM, Marcel Offermans < > marcel.offerm...@luminis.nl> wrote: > >> 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 >> >> > > > -- > > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > FuseSource, Integration everywhere > http://fusesource.com
Re: Releasing the dependency manager...
Hi, Over the past few days, I have been updating the documentation for filter indices. If you agree, could you commit that for me? See https://issues.apache.org/jira/browse/FELIX-3856 . Thanks! Angelo On Jan 23, 2013, at 2:05 PM, Pierre De Rop wrote: > Hello Marcel, > > I have finished to commit some fixes in the annotation side, and I think > you can now cut a release. > Mainly, I did the following: > > [FELIX-3863] - Generate DependencyManager Annotation MetaData In Project > Folder > [FELIX-3865] - Update DependencyManager annotation plugin with latest bndlb > 1.50 > [FELIX-3866] - Added support for "swap" attribute in AspectService and > AdpaterService annotations. > > thanks; > > kind regards; > /Pierre > > > On Mon, Jan 21, 2013 at 1:49 PM, Marcel Offermans < > marcel.offerm...@luminis.nl> wrote: > >> Hello Pierre, >> >> Sure, no rush, check the code. As far as I could see, the changes we made >> so far are all backward compatible, so I don't expect you have to change >> anything there. Aligning the annotations is something I did not do or look >> at, so if you could do that, that would be great. Just let me know when >> you're done. :) >> >> Greetings, Marcel >> >> On Jan 21, 2013, at 11:59 , Pierre De Rop wrote: >> >>> Hi Marcel, >>> >>> oops, I missed your post three days ago. If this not too late, can you >>> please give me one day in order to check the DM annotation side ? I'm not >>> sure but may be I should align the DM annotations to the latest bnd >>> version. I will check this today. >>> >>> thanks >>> >>> /Pierre >>> >>> >>> On Fri, Jan 18, 2013 at 9:44 AM, Jan Willem Janssen < >>> janwillem.jans...@luminis.eu> wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/18/13 8:59 AM, Marcel Offermans wrote: > Just a quick heads-up to the list that I want to release a new > version of the dependency manager soon. The codebase has been > stable and tested by several committers here for some time now, and > there have been some new and interesting improvements. So, unless > someone has showstopping bugs they have not reported yet, I'm going > to proceed. I do not have any showstoppers for releasing a new version of Felix DM, so, go for it! ;) - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is:/ Luminis Technologies B.V. IJsselburcht 3 6825 BS Arnhem +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ+Qt6AAoJEKF/mP2eHDc4ZoAP/iRoFd7XBlwx3gaIzKEHpYde LTzB8deRvFYc4H82RvePdoJ0L5VCWFvcm04frMgAXd/NrEmBZDpZeoJzp76qCaqb NnGRwEqjEf4zVWeW2JQU9KLV59UEjdQt+BzUV1m1aiSzZ4Hkimp+VW732DQ5ViYJ uOvZWeNYz0MKya2lrphbIRoiOJJOc1F6fDOZ5+1oFIWTeKn91h/gZwrJGkz7Tx0M GeZZsFO1JLVRjPKYld/pdJvFOQgXs7wgRZVFqcE+2Tfea6s1nHZ70j7U9HWP4eC/ D1ijp3bmavJd9zpIaMdPniSgn0V7nMGu54ju6/rN3kk4N8biRNo4YK+oP+PwOjiz l9pP+quCzt6TuCEqGDaqR+lE5Wo3nr2x1B5fU981ZHqdsnkFUCeYzkmvDFJfA7oq NB61Uu6lto54JNukHb3skCnxAOfEK7QvBXsZ5XQOGwjKfj6kXDH10lr8zMNB9y5y TGbrx57IYjmmMqly3JTh4Lpm9eo0tj6Y7XdocA0nMZhuD6wRBx0dGXGnV4Pc03bc MThPpHNQHBgsi92x1k+d8t6sQjQwa7jmnZXzf6IspxwLUMtlQWVy1xeHRQPbRDwS VldX1pn62tz8J3N6iuMwD/A0Or7oG+QMUk5LW21uxmTA+7tPDWppyq/KTyWsdQYE r2a1RpSCb9n5J+rXoUya =YLvg -END PGP SIGNATURE- >> >>
[jira] [Updated] (FELIX-3856) Provide documentation for filter indices
[ https://issues.apache.org/jira/browse/FELIX-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt updated FELIX-3856: Attachment: Felix-3856-Filter-indices-for-aspects-and-adapters.patch Added a second patch with documentation for aspect- and adapter indices. > 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, > Felix-3856-Filter-indices-for-aspects-and-adapters.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=13558350#comment-13558350 ] Angelo van der Sijpt commented on FELIX-3856: - I know of their existence, but I don't know how they work. If you can give me a quick explanation, I'll make into a nice piece of prose with some examples. > 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] [Updated] (FELIX-3856) Provide documentation for filter indices
[ https://issues.apache.org/jira/browse/FELIX-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt updated FELIX-3856: Attachment: FELIX-3856-Filter-indices-documentation.patch This patch contains the filter index documentation. > 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] [Created] (FELIX-3856) Provide documentation for filter indices
Angelo van der Sijpt created FELIX-3856: --- Summary: 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 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
Re: Releasing the dependency manager...
Hi Marcel, No bugs for me, and I am rather excited about the upcoming indexing. Will this be in as an official feature in this release? If so, I will see to it that I update the documentation around that (as I promised) as soon as possible. Angelo On Jan 18, 2013, at 8:59 AM, Marcel Offermans wrote: > Just a quick heads-up to the list that I want to release a new version of the > dependency manager soon. The codebase has been stable and tested by several > committers here for some time now, and there have been some new and > interesting improvements. So, unless someone has showstopping bugs they have > not reported yet, I'm going to proceed. > > Greetings, Marcel > >
Re: [VOTE] Accept the UserAdmin donation by Jan Willem Janssen
Looking good! +1 Angelo On Aug 3, 2012, at 6:37 PM, Stuart McCulloch wrote: > On 3 Aug 2012, at 16:57, Marcel Offermans wrote: > >> A little while ago, Jan Willem Janssen donated a complete implementation of >> the UserAdmin compendium service [1] to our project. I would like to start a >> formal vote on accepting this code. >> >> Please vote: >> >> [ ] +1 Accept this donation. >> [ ] 0 Don't care. >> [ ] -1 Don't accept this donation (please motivate your vote). > > +1 > >> Greetings, Marcel >> >> [1] https://issues.apache.org/jira/browse/FELIX-3600 > >
[jira] [Created] (FELIX-3365) Deployment Admin should remove stale resource processors
Deployment Admin should remove stale resource processors Key: FELIX-3365 URL: https://issues.apache.org/jira/browse/FELIX-3365 Project: Felix Issue Type: Improvement Components: Deployment Admin Affects Versions: deploymentadmin-0.9.0 Reporter: Angelo van der Sijpt Deployment Admin's installation process is according to spec, which means that stale resources processors will never be removed ( see https://www.osgi.org/bugzilla/show_bug.cgi?id=139 ). In advance of this spec change, we should include a step in Deployment Admin that removes stale customizer bundles, just after we have called commit() on all resource processors. -- 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] [Closed] (FELIX-3313) dropped() should not be called when updating a resource
[ https://issues.apache.org/jira/browse/FELIX-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt closed FELIX-3313. --- Resolution: Invalid Turns out this behavior is not caused by the way the DeploymentAdmin implementation works (this looks correct in that sense), but by the way ACE generates its deployment packages, see ACE-214 . > dropped() should not be called when updating a resource > --- > > Key: FELIX-3313 > URL: https://issues.apache.org/jira/browse/FELIX-3313 > Project: Felix > Issue Type: Bug > Components: Deployment Admin > Reporter: Angelo van der Sijpt > > When resources are being handled by ResourceProcessors, the dropped() method > is always called for resources that were present in a previous deployment > package. This should _only_ happen if the resources is no longer present in > the current deployment package (see compendium 114.8, steps 10 and 11). -- 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] [Closed] (FELIX-3272) Add property to allow foreign resource processors
[ https://issues.apache.org/jira/browse/FELIX-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt closed FELIX-3272. --- Looks just like my patch, thanks! > Add property to allow foreign resource processors > - > > Key: FELIX-3272 > URL: https://issues.apache.org/jira/browse/FELIX-3272 > Project: Felix > Issue Type: Improvement > Components: Deployment Admin >Affects Versions: deploymentadmin-0.9.0 > Reporter: Angelo van der Sijpt >Assignee: Marcel Offermans > Attachments: FELIX-3272.patch > > > DeploymentAdmin is built in such a way, that a deployment package is > self-contained. However, in my case, I want to use a ResourceProcessor that > is already on the system to process a configuration resource; if I do this, > this will give me a DeploymentException.CODE_FOREIGN_CUSTOMIZER. > Just like system property > org.apache.felix.deploymentadmin.stopunaffectedbundle can customize the > behavior of deployment admin, I propose a new property: > org.apache.felix.deploymentadmin.allowforeigncustomizers , which allows > ResourceProcessors that are already on the system to process resources in a > deployment package. This should not be default behavior, so a system property > should be in order. > I will attach a patch for this shortly. -- 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-3313) dropped() should not be called when updating a resource
dropped() should not be called when updating a resource --- Key: FELIX-3313 URL: https://issues.apache.org/jira/browse/FELIX-3313 Project: Felix Issue Type: Bug Components: Deployment Admin Reporter: Angelo van der Sijpt When resources are being handled by ResourceProcessors, the dropped() method is always called for resources that were present in a previous deployment package. This should _only_ happen if the resources is no longer present in the current deployment package (see compendium 114.8, steps 10 and 11). -- 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-3272) Add property to allow foreign resource processors
[ https://issues.apache.org/jira/browse/FELIX-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt updated FELIX-3272: Attachment: FELIX-3272.patch Patch implementing the proposed solution. > Add property to allow foreign resource processors > - > > Key: FELIX-3272 > URL: https://issues.apache.org/jira/browse/FELIX-3272 > Project: Felix > Issue Type: Improvement > Components: Deployment Admin >Affects Versions: deploymentadmin-0.9.0 > Reporter: Angelo van der Sijpt > Attachments: FELIX-3272.patch > > > DeploymentAdmin is built in such a way, that a deployment package is > self-contained. However, in my case, I want to use a ResourceProcessor that > is already on the system to process a configuration resource; if I do this, > this will give me a DeploymentException.CODE_FOREIGN_CUSTOMIZER. > Just like system property > org.apache.felix.deploymentadmin.stopunaffectedbundle can customize the > behavior of deployment admin, I propose a new property: > org.apache.felix.deploymentadmin.allowforeigncustomizers , which allows > ResourceProcessors that are already on the system to process resources in a > deployment package. This should not be default behavior, so a system property > should be in order. > I will attach a patch for this shortly. -- 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-3272) Add property to allow foreign resource processors
Add property to allow foreign resource processors - Key: FELIX-3272 URL: https://issues.apache.org/jira/browse/FELIX-3272 Project: Felix Issue Type: Improvement Components: Deployment Admin Affects Versions: deploymentadmin-0.9.0 Reporter: Angelo van der Sijpt DeploymentAdmin is built in such a way, that a deployment package is self-contained. However, in my case, I want to use a ResourceProcessor that is already on the system to process a configuration resource; if I do this, this will give me a DeploymentException.CODE_FOREIGN_CUSTOMIZER. Just like system property org.apache.felix.deploymentadmin.stopunaffectedbundle can customize the behavior of deployment admin, I propose a new property: org.apache.felix.deploymentadmin.allowforeigncustomizers , which allows ResourceProcessors that are already on the system to process resources in a deployment package. This should not be default behavior, so a system property should be in order. I will attach a patch for this shortly. -- 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: [VOTE] framework 4.0.2 and related subproject releases
+1 Looks good to me, actually fixes a bug we ran into hours after this vote going up. Kudos for the negative response time! Angelo On Mon, Nov 21, 2011 at 1:35 PM, Felix Meschberger wrote: > +1 > > Regards > Felix > > Am 20.11.2011 um 22:08 schrieb Karl Pauls: > > > I would like to call a vote on the following subproject releases: > > > > framework 4.0.2 > > framework.security 2.0.1 > > main 4.0.2 > > main.distribution 4.0.2 > > > > > > Staging repositories: > > https://repository.apache.org/content/repositories/orgapachefelix-225/ > > > > 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 225 /tmp/felix-staging > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Veto the release (please provide specific comments) > >
Filter specification bug (was: Re: [VOTE] Felix framework 2.0.0 and related subprojects releases)
On Sep 9, 2009, at 8:02 PM, Stuart McCulloch wrote: 2009/9/10 Angelo van der Sijpt On Sep 9, 2009, at 7:00 PM, Richard S. Hall wrote: On 9/9/09 12:54, Angelo van der Sijpt wrote: +1 (very non-authoritive) We checked the new release against our OSGi testing framework ( http://opensource.luminis.net/wiki/display/OSGITEST/OSGi+testing+framework ), and found nothing bad. It's a shame about the new OSGi-provided filter implementation, by the way... Why is that? In some corner cases, the OSGi implementation might conclude that a filter is invalid, while it is actually permitted by the production rules. For instance, (!ab=a) states an attribute name of '!ab', which is not disallowed by spec, and solved correctly by Felix' filter implementation. The provided one assumes that any ! after a ( will signal a negation, and complain that it requires a ( . have you raised a bug for this over at https://www.osgi.org/bugzilla/enter_bug.cgi ? Bug filed as https://www.osgi.org/bugzilla/show_bug.cgi?id=57 . Angelo
Re: [VOTE] Felix framework 2.0.0 and related subprojects releases
On 9 Sep 2009, at 20:38, Karl Pauls wrote: > On Wed, Sep 9, 2009 at 6:54 PM, Angelo van der > Sijpt wrote: >> +1 (very non-authoritive) >> >> We checked the new release against our OSGi testing framework >> (http://opensource.luminis.net/wiki/display/OSGITEST/OSGi+testing+framework >> ), and found nothing bad. > > > I would have been surprised as I did run it as well :-) Ah, nice. This might also be a good time to introduce our graduate student, who will be extending the testing framework, and adding cool features like automated reporting and multi-framework support! > > regards, > > Karl > Angelo
Re: [VOTE] Felix framework 2.0.0 and related subprojects releases
On Sep 9, 2009, at 7:00 PM, Richard S. Hall wrote: On 9/9/09 12:54, Angelo van der Sijpt wrote: +1 (very non-authoritive) We checked the new release against our OSGi testing framework (http://opensource.luminis.net/wiki/display/OSGITEST/OSGi+testing+framework ), and found nothing bad. It's a shame about the new OSGi-provided filter implementation, by the way... Why is that? In some corner cases, the OSGi implementation might conclude that a filter is invalid, while it is actually permitted by the production rules. For instance, (!ab=a) states an attribute name of '!ab', which is not disallowed by spec, and solved correctly by Felix' filter implementation. The provided one assumes that any ! after a ( will signal a negation, and complain that it requires a ( . We are not required to use it, we were just tired of maintaining our own. -> richard Angelo Angelo On 7 Sep 2009, at 01:53, Karl Pauls wrote: I would like to call a vote on the following subproject releases: org.osgi.core 1.4.0 * org.osgi.compendium 1.4.0 * shell 1.4.0 shell.tui 1.4.0 bundlerepository 1.4.1 framework 2.0.0 main 2.0.0 Staging repository: https://repository.apache.org/content/repositories/felix-staging-044// 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 44 /tmp/felix-staging Additionally, a convenience binary release is provided at: http://people.apache.org/~pauls/2.0.0/ Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) * The core and compendium subprojects are being released because framework depends on them, but they will not be published.
Re: [VOTE] Felix framework 2.0.0 and related subprojects releases
+1 (very non-authoritive) We checked the new release against our OSGi testing framework (http://opensource.luminis.net/wiki/display/OSGITEST/OSGi+testing+framework ), and found nothing bad. It's a shame about the new OSGi-provided filter implementation, by the way... Angelo On 7 Sep 2009, at 01:53, Karl Pauls wrote: > I would like to call a vote on the following subproject releases: > > org.osgi.core 1.4.0 * > org.osgi.compendium 1.4.0 * > shell 1.4.0 > shell.tui 1.4.0 > bundlerepository 1.4.1 > framework 2.0.0 > main 2.0.0 > > Staging repository: > https://repository.apache.org/content/repositories/felix-staging-044// > > 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 44 /tmp/felix-staging > > Additionally, a convenience binary release is provided at: > > http://people.apache.org/~pauls/2.0.0/ > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > * The core and compendium subprojects are being released because > framework depends on them, but they will not be published.
[jira] Commented: (FELIX-1146) ConfigAdmin can deliver updates to a managed service factory more than once
[ https://issues.apache.org/jira/browse/FELIX-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747313#action_12747313 ] Angelo van der Sijpt commented on FELIX-1146: - I have not been able to reproduce the issue with 1.2.0, so this looks fine to me! Thanks for the fix! > ConfigAdmin can deliver updates to a managed service factory more than once > --- > > Key: FELIX-1146 > URL: https://issues.apache.org/jira/browse/FELIX-1146 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.0.8 > Reporter: Angelo van der Sijpt >Assignee: Felix Meschberger >Priority: Minor > Fix For: configadmin-1.2.0 > > Attachments: Activator.java, ActivatorWithDependencyManager.java > > > When the update of a ManagedServiceFactoryConfiguration, and the registration > of that ManagedServiceFactory are close together or 'crossing', it is > possible that the update is delivered twice to the factory. > This seems to happen because of the following interleaving, with line numbers > from current trunk, rev 763614 > Some notes: > - I would have preferred to add some ascii art MSC, but unfortunately Jira > does not allow this > - Time order is top to bottom; I left out many methods for clarity > User thread: > - createFactoryConfiguration(user code) > - config.update(user code) > - factory.addPID(ConfigurationImpl.java:329) > (preempted) > Managed Service Factory Tracker thread: > - ManagedServiceFactoryTracker.addingService(ConfigurationManager.java:1505) > - cm.configure(ConfigurationManager.java:1512) > - updateThread.schedule(ConfigurationManager.java:622) (Schedules a > ManagedServiceFactoryUpdate task) > - schedule(UpdateThread.java:109) > Update thread: > - task.run(UpdateThread.java:89) > - ManagedServiceFactoryUpdate.run, > cfg.isDelivered()(ConfigurationManager:1096) (is false now) > - cfg.setDelivered( true )(ConfigurationManager:1129) > User thread: > - setDelivered( false )(ConfigurationImpl:338) > - updateThread.schedule(ConfigurationManager:482) > - schedule(UpdateThread.java:109) (Schedules a 'regular' UpdateTask) > Update thread: > - task.run(UpdateThread.java:89) > - UpdateConfiguration.run, config.isDelivered() (is false now, so the > configuration is delivered twice!) > In short, there is a possibility in which the ManagedServiceFactoryUpdate > task and ConfigurationImpl influence the setDelivered in such a way, that > they interfere with eachother. > I do not have a contained testcase at the moment, nor an easy fix. Sorry > about that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1146) ConfigAdmin can deliver updates to a managed service factory more than once
[ https://issues.apache.org/jira/browse/FELIX-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt updated FELIX-1146: Attachment: ActivatorWithDependencyManager.java Activator.java I created a minimal example that shows the described behavior. I also found out that this behavior is more easily reproducable when using the dependency manager (I didn't have the time to find out why). ActivatorWithDependencyManager.java contains a bundle activator that, when used as an activator for a bundle, will demonstrate the problem. Activator.java contains the same situation, just using basic service primitives. > ConfigAdmin can deliver updates to a managed service factory more than once > --- > > Key: FELIX-1146 > URL: https://issues.apache.org/jira/browse/FELIX-1146 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.0.8 > Reporter: Angelo van der Sijpt >Priority: Minor > Attachments: Activator.java, ActivatorWithDependencyManager.java > > > When the update of a ManagedServiceFactoryConfiguration, and the registration > of that ManagedServiceFactory are close together or 'crossing', it is > possible that the update is delivered twice to the factory. > This seems to happen because of the following interleaving, with line numbers > from current trunk, rev 763614 > Some notes: > - I would have preferred to add some ascii art MSC, but unfortunately Jira > does not allow this > - Time order is top to bottom; I left out many methods for clarity > User thread: > - createFactoryConfiguration(user code) > - config.update(user code) > - factory.addPID(ConfigurationImpl.java:329) > (preempted) > Managed Service Factory Tracker thread: > - ManagedServiceFactoryTracker.addingService(ConfigurationManager.java:1505) > - cm.configure(ConfigurationManager.java:1512) > - updateThread.schedule(ConfigurationManager.java:622) (Schedules a > ManagedServiceFactoryUpdate task) > - schedule(UpdateThread.java:109) > Update thread: > - task.run(UpdateThread.java:89) > - ManagedServiceFactoryUpdate.run, > cfg.isDelivered()(ConfigurationManager:1096) (is false now) > - cfg.setDelivered( true )(ConfigurationManager:1129) > User thread: > - setDelivered( false )(ConfigurationImpl:338) > - updateThread.schedule(ConfigurationManager:482) > - schedule(UpdateThread.java:109) (Schedules a 'regular' UpdateTask) > Update thread: > - task.run(UpdateThread.java:89) > - UpdateConfiguration.run, config.isDelivered() (is false now, so the > configuration is delivered twice!) > In short, there is a possibility in which the ManagedServiceFactoryUpdate > task and ConfigurationImpl influence the setDelivered in such a way, that > they interfere with eachother. > I do not have a contained testcase at the moment, nor an easy fix. Sorry > about that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1146) ConfigAdmin can deliver updates to a managed service factory more than once
ConfigAdmin can deliver updates to a managed service factory more than once --- Key: FELIX-1146 URL: https://issues.apache.org/jira/browse/FELIX-1146 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.0.8 Reporter: Angelo van der Sijpt Priority: Minor When the update of a ManagedServiceFactoryConfiguration, and the registration of that ManagedServiceFactory are close together or 'crossing', it is possible that the update is delivered twice to the factory. This seems to happen because of the following interleaving, with line numbers from current trunk, rev 763614 Some notes: - I would have preferred to add some ascii art MSC, but unfortunately Jira does not allow this - Time order is top to bottom; I left out many methods for clarity User thread: - createFactoryConfiguration(user code) - config.update(user code) - factory.addPID(ConfigurationImpl.java:329) (preempted) Managed Service Factory Tracker thread: - ManagedServiceFactoryTracker.addingService(ConfigurationManager.java:1505) - cm.configure(ConfigurationManager.java:1512) - updateThread.schedule(ConfigurationManager.java:622) (Schedules a ManagedServiceFactoryUpdate task) - schedule(UpdateThread.java:109) Update thread: - task.run(UpdateThread.java:89) - ManagedServiceFactoryUpdate.run, cfg.isDelivered()(ConfigurationManager:1096) (is false now) - cfg.setDelivered( true )(ConfigurationManager:1129) User thread: - setDelivered( false )(ConfigurationImpl:338) - updateThread.schedule(ConfigurationManager:482) - schedule(UpdateThread.java:109) (Schedules a 'regular' UpdateTask) Update thread: - task.run(UpdateThread.java:89) - UpdateConfiguration.run, config.isDelivered() (is false now, so the configuration is delivered twice!) In short, there is a possibility in which the ManagedServiceFactoryUpdate task and ConfigurationImpl influence the setDelivered in such a way, that they interfere with eachother. I do not have a contained testcase at the moment, nor an easy fix. Sorry about that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-915) PackageAdmin returns null on getBundle(...) with system classes
[ https://issues.apache.org/jira/browse/FELIX-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt closed FELIX-915. -- Working correctly now, thanks! > PackageAdmin returns null on getBundle(...) with system classes > --- > > Key: FELIX-915 > URL: https://issues.apache.org/jira/browse/FELIX-915 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.4.1 > Reporter: Angelo van der Sijpt >Assignee: Richard S. Hall >Priority: Minor > Fix For: felix-1.6.0 > > > When calling getBundle(clazz) on the PackageAdmin with a class from one of > the system packages, the system bundle should be returned. In stead, > PackageAdmin now returns null. > This applies not only to the 'standard' system classes (e.g., BundleContext > or PackageAdmin), but also to packages in > org.osgi.framework.system.packages.extra. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-609) PreferencesService might return invalid Preferences object for a user
[
https://issues.apache.org/jira/browse/FELIX-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo van der Sijpt closed FELIX-609.
--
It has been a while, but yes, the trunk behavior is now OK.
> PreferencesService might return invalid Preferences object for a user
> -
>
> Key: FELIX-609
> URL: https://issues.apache.org/jira/browse/FELIX-609
> Project: Felix
> Issue Type: Bug
> Components: Preferences Service
> Reporter: Angelo van der Sijpt
>Assignee: Marcel Offermans
>
> When a Preferences object has been obtained for a given user, it can be
> removed using removeNode(). A following call to getUserPreferences(...) will
> then return the old, now invalid, Preferences object, leading to an
> IllegalStateException when trying to add new data to the node. From this
> moment on, it is not possible to obtain a valid Preferences object for this
> user.
> The spec does not provide a definite answer about this case; 106.4 comes
> closest with "getUserPreferences(String) - Return a Preferences object
> associated with the user name that is given as argument. If the user does not
> exist, a new root is created atomically." Intuitively, one might expect that
> removeNode() restores the PreferencesService to the same state it was before
> getUserPreferences(...) was called.
> The invalid Preferences object is caused by caching behavior in
> PreferencesServicesImpl's getUserPreferences(...), which checks whether a
> user's root node has already been created; if so, it will be returned, if
> not, it will be created.
> 91PreferencesImpl result = (PreferencesImpl) this.trees.get(name);
> 92// if the tree does not exist yet, create it
> 93if (result == null) {
> 94result = new PreferencesImpl(new
> PreferencesDescription(this.bundleId, name), this.storeManager);
> 95this.trees.put(name, result);
> 96}
> The most plausible solution is to add an extra clause to the if-statement on
> line 93, stating something like
> 93if (result == null || !result.isValid()) {
> provided that isValid() will then return the valid field of PreferencesImpl.
> An alternative would be to detect the removal of a node which does not have a
> parent (is a root node), and then remove it from the PreferencesServiceImpl's
> trees; this is not that complicated, but requires some extra code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-915) PackageAdmin returns null on getBundle(...) with system classes
PackageAdmin returns null on getBundle(...) with system classes --- Key: FELIX-915 URL: https://issues.apache.org/jira/browse/FELIX-915 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.4.1 Reporter: Angelo van der Sijpt Priority: Minor When calling getBundle(clazz) on the PackageAdmin with a class from one of the system packages, the system bundle should be returned. In stead, PackageAdmin now returns null. This applies not only to the 'standard' system classes (e.g., BundleContext or PackageAdmin), but also to packages in org.osgi.framework.system.packages.extra. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: brain teaser - embedded felix / class cast exception
Hi,
On 8 Jul 2008, at 19:19, Dieter Wimberger wrote:
I guess that 7.0 is the output from the felix classloader. When
allowing parent delegation (what Sahoo suggested), then you get the
result you were looking for.
The 7.0 is indeed the name of the classloader of bundle ID 7 (the 0 is
the version; if the bundle gets updated, this number will be
incremented), which has to be the bundle that exports the
CacheServiceMain object.
On 8 Jul 2008, at 18:47, Sahoo wrote:
My parent is what creates the Felix container, so it is
technically not
in a bundle, but I loaded the same class code in it's jar (since I'm
going to be using it, of course) -- although, design wise, I'm
using the
<> not the <>, but I short circuited the
interface just
to get to the bottom of the riddle...
This seems to be the problem. Felix does not use the class that's
loaded by your code, which is running outside Felix. To fix it, you
have to make both Felix and your code use the same class. Since
your code runs before Felix and you probably don't want to use
reflection to use that class, the only option that I can think of
is to configure Felix to use your class by adding org.craig.cache
to the list of packages exported by the parent class loader. The
property name in config.property is:
org.osgi.framework.system.packages. See OSGi documentation for more
details about this property.
True: Felix is a bundle too (that is why you can get its
BundleContext), the system bundle to be precise. This system bundle
does import the package from bundle 7 as soon as that class would get
used. You can get the service reference for the class you want because
it is possible to resolve the package import from the system bundle
(that is, if it would not be possible because of e.g. versioning, you
would not get the service reference).
If you really want to use the service outside of the Felix instance,
Sahoo's suggestion of delegating to the system classloader seems the
best way to go.
Still, I think I would package whatever it is you want to be using
service with as a bundle, and run all code from inside that bundle.
If neither of these is an option, reflection might help you out. For
instance, if you have a service MyService of which you are sure the
definitions are identical, but just not loaded by the same
classloader, you can use a proxy like such:
final Object object =
bc.getService(bc.getServiceReference(MyService.class.getName()));
MyService service = (MyService)
Proxy.newProxyInstance(MyService.class.getClassLoader(), new Class[]
{ MyService.class },
new InvocationHandler() {
public Object invoke(Object proxy, Method method,
Object[] args) throws Throwable {
Method bridge =
object.getClass().getDeclaredMethod(method.getName(),
method.getParameterTypes());
return bridge.invoke(object, args);
}
});
Hope this helps,
Angelo
[jira] Updated: (FELIX-609) PreferencesService might return invalid Preferences object for a user
[
https://issues.apache.org/jira/browse/FELIX-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo van der Sijpt updated FELIX-609:
---
Description:
When a Preferences object has been obtained for a given user, it can be removed
using removeNode(). A following call to getUserPreferences(...) will then
return the old, now invalid, Preferences object, leading to an
IllegalStateException when trying to add new data to the node. From this moment
on, it is not possible to obtain a valid Preferences object for this user.
The spec does not provide a definite answer about this case; 106.4 comes
closest with "getUserPreferences(String) - Return a Preferences object
associated with the user name that is given as argument. If the user does not
exist, a new root is created atomically." Intuitively, one might expect that
removeNode() restores the PreferencesService to the same state it was before
getUserPreferences(...) was called.
The invalid Preferences object is caused by caching behavior in
PreferencesServicesImpl's getUserPreferences(...), which checks whether a
user's root node has already been created; if so, it will be returned, if not,
it will be created.
91PreferencesImpl result = (PreferencesImpl) this.trees.get(name);
92// if the tree does not exist yet, create it
93if (result == null) {
94result = new PreferencesImpl(new
PreferencesDescription(this.bundleId, name), this.storeManager);
95this.trees.put(name, result);
96}
The most plausible solution is to add an extra clause to the if-statement on
line 93, stating something like
93if (result == null || !result.isValid()) {
provided that isValid() will then return the valid field of PreferencesImpl.
An alternative would be to detect the removal of a node which does not have a
parent (is a root node), and then remove it from the PreferencesServiceImpl's
trees; this is not that complicated, but requires some extra code.
was:
When a Preferences object has been obtained for a given user, it can be removed
using removeNode(). A following call to getUserPreferences(...) will then
return the old, now invalid, Preferences object, leading to an
IllegalStateException when trying to add new data to the node. From this moment
on, it is not possible to obtain a valid Preferences object for this user.
The spec does not provide a definite answer about this case; 106.4 comes
closest with "getUserPreferences(String) - Return a Preferences object
associated with the user name that is given as argument. If the user does not
exist, a new root is created atomically." Intuitively, one might expect that
removeNode() restores the PreferencesService to the same state it was before
getUserPreferences(...) was called.
The invalid Preferences object is caused by caching behavior in
PreferencesServicesImpl's getUserPreferences(...), which checks whether a
user's root node has already been created; if so, it will be returned, if not,
it will be created.
91PreferencesImpl result = (PreferencesImpl) this.trees.get(name);
92// if the tree does not exist yet, create it
93if (result == null) {
94result = new PreferencesImpl(new
PreferencesDescription(this.bundleId, name), this.storeManager);
95this.trees.put(name, result);
96}
The most plausible solution is to add an extra clause to the if-statement on
line 93, stating something like
93if (result == null || result.isValid()) {
provided that isValid() will then return the valid field of PreferencesImpl.
An alternative would be to detect the removal of a node which does not have a
parent (is a root node), and then remove it from the PreferencesServiceImpl's
trees; this is not that complicated, but requires some extra code.
Typo.
> PreferencesService might return invalid Preferences object for a user
> -
>
> Key: FELIX-609
> URL: https://issues.apache.org/jira/browse/FELIX-609
> Project: Felix
> Issue Type: Bug
> Components: Preferences Service
>Reporter: Angelo van der Sijpt
>
> When a Preferences object has been obtained for a given user, it can be
> removed using removeNode(). A following call to getUserPreferences(...) will
> then return the old, now invalid, Preferences object, leading to an
> IllegalStateException when trying to add new data to the node. From this
> moment on, it is not possible to obtain a valid Preferences object for this
> user.
> The spec does not provide a definite answer about this case; 106.4 comes
> closest with "getUserPreferences(String) - Return a Preferences object
> associated with the user name tha
[jira] Created: (FELIX-609) PreferencesService might return invalid Preferences object for a user
PreferencesService might return invalid Preferences object for a user
-
Key: FELIX-609
URL: https://issues.apache.org/jira/browse/FELIX-609
Project: Felix
Issue Type: Bug
Components: Preferences Service
Reporter: Angelo van der Sijpt
When a Preferences object has been obtained for a given user, it can be removed
using removeNode(). A following call to getUserPreferences(...) will then
return the old, now invalid, Preferences object, leading to an
IllegalStateException when trying to add new data to the node. From this moment
on, it is not possible to obtain a valid Preferences object for this user.
The spec does not provide a definite answer about this case; 106.4 comes
closest with "getUserPreferences(String) - Return a Preferences object
associated with the user name that is given as argument. If the user does not
exist, a new root is created atomically." Intuitively, one might expect that
removeNode() restores the PreferencesService to the same state it was before
getUserPreferences(...) was called.
The invalid Preferences object is caused by caching behavior in
PreferencesServicesImpl's getUserPreferences(...), which checks whether a
user's root node has already been created; if so, it will be returned, if not,
it will be created.
91PreferencesImpl result = (PreferencesImpl) this.trees.get(name);
92// if the tree does not exist yet, create it
93if (result == null) {
94result = new PreferencesImpl(new
PreferencesDescription(this.bundleId, name), this.storeManager);
95this.trees.put(name, result);
96}
The most plausible solution is to add an extra clause to the if-statement on
line 93, stating something like
93if (result == null || result.isValid()) {
provided that isValid() will then return the valid field of PreferencesImpl.
An alternative would be to detect the removal of a node which does not have a
parent (is a root node), and then remove it from the PreferencesServiceImpl's
trees; this is not that complicated, but requires some extra code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-471) FilterImpl.toString() does not add escape characters
[
https://issues.apache.org/jira/browse/FELIX-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562403#action_12562403
]
Angelo van der Sijpt commented on FELIX-471:
Works fine, thanks.
> FilterImpl.toString() does not add escape characters
>
>
> Key: FELIX-471
> URL: https://issues.apache.org/jira/browse/FELIX-471
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Reporter: Angelo van der Sijpt
>Assignee: Karl Pauls
> Attachments: FELIX-471.patch
>
>
> FilterImpl.toString() is not a complete representation of the filter string
> that was used to create it: four characters ( '(', ')', '/' and '*' ) should
> be preceded by a '\' if they are to be used in a value.
> For example,
> new FilterImpl("(b=\(*)").toString();
> should return '(b=\(*)', but it returns '(b=(*)'. So, it can happen that a
> correct Filter f, when used in
> new FilterImpl(f.toString());
> causes an InvalidSyntaxException.
> (see
> http://www2.osgi.org/javadoc/r4/org/osgi/framework/Filter.html#toString() for
> what toString() should do).
> See the attached patch for a proposed solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-471) FilterImpl.toString() does not add escape characters
[
https://issues.apache.org/jira/browse/FELIX-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo van der Sijpt closed FELIX-471.
--
> FilterImpl.toString() does not add escape characters
>
>
> Key: FELIX-471
> URL: https://issues.apache.org/jira/browse/FELIX-471
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Reporter: Angelo van der Sijpt
>Assignee: Karl Pauls
> Attachments: FELIX-471.patch
>
>
> FilterImpl.toString() is not a complete representation of the filter string
> that was used to create it: four characters ( '(', ')', '/' and '*' ) should
> be preceded by a '\' if they are to be used in a value.
> For example,
> new FilterImpl("(b=\(*)").toString();
> should return '(b=\(*)', but it returns '(b=(*)'. So, it can happen that a
> correct Filter f, when used in
> new FilterImpl(f.toString());
> causes an InvalidSyntaxException.
> (see
> http://www2.osgi.org/javadoc/r4/org/osgi/framework/Filter.html#toString() for
> what toString() should do).
> See the attached patch for a proposed solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-471) FilterImpl.toString() does not add escape characters
[
https://issues.apache.org/jira/browse/FELIX-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angelo van der Sijpt updated FELIX-471:
---
Attachment: FELIX-471.patch
> FilterImpl.toString() does not add escape characters
>
>
> Key: FELIX-471
> URL: https://issues.apache.org/jira/browse/FELIX-471
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Reporter: Angelo van der Sijpt
> Attachments: FELIX-471.patch
>
>
> FilterImpl.toString() is not a complete representation of the filter string
> that was used to create it: four characters ( '(', ')', '/' and '*' ) should
> be preceded by a '\' if they are to be used in a value.
> For example,
> new FilterImpl("(b=\(*)").toString();
> should return '(b=\(*)', but it returns '(b=(*)'. So, it can happen that a
> correct Filter f, when used in
> new FilterImpl(f.toString());
> causes an InvalidSyntaxException.
> (see
> http://www2.osgi.org/javadoc/r4/org/osgi/framework/Filter.html#toString() for
> what toString() should do).
> See the attached patch for a proposed solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-471) FilterImpl.toString() does not add escape characters
FilterImpl.toString() does not add escape characters
Key: FELIX-471
URL: https://issues.apache.org/jira/browse/FELIX-471
Project: Felix
Issue Type: Bug
Components: Framework
Reporter: Angelo van der Sijpt
FilterImpl.toString() is not a complete representation of the filter string
that was used to create it: four characters ( '(', ')', '/' and '*' ) should be
preceded by a '\' if they are to be used in a value.
For example,
new FilterImpl("(b=\(*)").toString();
should return '(b=\(*)', but it returns '(b=(*)'. So, it can happen that a
correct Filter f, when used in
new FilterImpl(f.toString());
causes an InvalidSyntaxException.
(see http://www2.osgi.org/javadoc/r4/org/osgi/framework/Filter.html#toString()
for what toString() should do).
See the attached patch for a proposed solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-411) Preferences service throws ClassCastException
[ https://issues.apache.org/jira/browse/FELIX-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angelo van der Sijpt closed FELIX-411. -- Works like a charm. Thanks! Angelo > Preferences service throws ClassCastException > - > > Key: FELIX-411 > URL: https://issues.apache.org/jira/browse/FELIX-411 > Project: Felix > Issue Type: Bug > Components: Preferences Service > Reporter: Angelo van der Sijpt >Assignee: Carsten Ziegeler > > The preferences admin throws a ClassCastException when writing its cache. The > exception is > java.lang.ClassCastException: [Lorg.apache.felix.prefs.PreferencesImpl; > cannot be cast to org.apache.felix.prefs.PreferencesImpl > at > org.apache.felix.prefs.impl.PreferencesManager.save(PreferencesManager.java:179) > ... > This seems to have to do with the implementation of PreferencesImpl: in its > constructor, all preferences are loaded. The system preferences are stored, > 61this.systemTree = prefs[i]; > but the user preferences are stored incorrectly: > 63this.trees.put(prefs[i].getDescription().getIdentifier(), prefs); > The full array of prefs is stored, not just prefs[i]; this causes the > classcastexception. > A possible fix could be > 63this.trees.put(prefs[i].getDescription().getIdentifier(), prefs[i]); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-411) Preferences service throws ClassCastException
Preferences service throws ClassCastException - Key: FELIX-411 URL: https://issues.apache.org/jira/browse/FELIX-411 Project: Felix Issue Type: Bug Components: Preferences Service Reporter: Angelo van der Sijpt The preferences admin throws a ClassCastException when writing its cache. The exception is java.lang.ClassCastException: [Lorg.apache.felix.prefs.PreferencesImpl; cannot be cast to org.apache.felix.prefs.PreferencesImpl at org.apache.felix.prefs.impl.PreferencesManager.save(PreferencesManager.java:179) ... This seems to have to do with the implementation of PreferencesImpl: in its constructor, all preferences are loaded. The system preferences are stored, 61this.systemTree = prefs[i]; but the user preferences are stored incorrectly: 63this.trees.put(prefs[i].getDescription().getIdentifier(), prefs); The full array of prefs is stored, not just prefs[i]; this causes the classcastexception. A possible fix could be 63this.trees.put(prefs[i].getDescription().getIdentifier(), prefs[i]); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
