[jira] [Resolved] (FELIX-4893) Replace filter registry with path resolvers
[ https://issues.apache.org/jira/browse/FELIX-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4893. - Resolution: Fixed I've improved the filter registry to work with just a single data structure using the same pattern matchers as the servlet registry. Added basic test cases Replace filter registry with path resolvers --- Key: FELIX-4893 URL: https://issues.apache.org/jira/browse/FELIX-4893 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: http.base-3.0.0 The filter registry is using a different code base for matching as the servlet registry. The filter registry should be updated to use the same code (the path resolvers) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4779) Improve request dispatching
[ https://issues.apache.org/jira/browse/FELIX-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-4779: Issue Type: Improvement (was: Sub-task) Parent: (was: FELIX-4060) Improve request dispatching --- Key: FELIX-4779 URL: https://issues.apache.org/jira/browse/FELIX-4779 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Carsten Ziegeler Right now all services (especially filters) are matched against the request, we could improve this -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4864) Implement whiteboard security checks
[ https://issues.apache.org/jira/browse/FELIX-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-4864: --- Assignee: Carsten Ziegeler Implement whiteboard security checks Key: FELIX-4864 URL: https://issues.apache.org/jira/browse/FELIX-4864 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: http.base-3.0.0 The whiteboard specification defines some security checks that need to be performed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4899) Change service id for http service context
Carsten Ziegeler created FELIX-4899: --- Summary: Change service id for http service context Key: FELIX-4899 URL: https://issues.apache.org/jira/browse/FELIX-4899 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: http.base-3.0.0 The servlet context id used by the http service is currently 0 - which is used by the whiteboard service to identify the state of no matching servlet context. We should use -1 for this internal context -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[VOTE] Apache Felix Dependency Manager Release Candidate R3
Hello all, I would like to call for a vote on the Dependency Manager toplevel release R3. We solved the following issues: ** Bug * [FELIX-4858] - DependencyManager: missing createCopy method in timed service dependency * [FELIX-4869] - Callbacks not invoked for dependencies that are added after the component is initialized ** Improvement * [FELIX-4614] - Factory create() method should have access to the component definition * [FELIX-4873] - Enhance DM API to get missing and circular dependencies * [FELIX-4876] - DM Annotations bnd plugin compatibility with Bndtools 2.4.1 / 3.0.0 versions * [FELIX-4877] - DM Annotations should detect service type using more method signatures. * [FELIX-4878] - Support more signatures for Dependency callbacks * [FELIX-4880] - Missing callback instance support for some adapters * [FELIX-4889] - Refactor dm shell command to use the org.apache.dm.diagnostics api ** Wish * [FELIX-4875] - Update DM integration test with latest ConfigAdmin 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 r3 /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
[jira] [Resolved] (FELIX-4899) Change service id for http service context
[ https://issues.apache.org/jira/browse/FELIX-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4899. - Resolution: Fixed Updated the impl to use -1 as the context id Change service id for http service context -- Key: FELIX-4899 URL: https://issues.apache.org/jira/browse/FELIX-4899 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: http.base-3.0.0 The servlet context id used by the http service is currently 0 - which is used by the whiteboard service to identify the state of no matching servlet context. We should use -1 for this internal context -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4897) Dynamic package resolution with fragment package exports can lead to invalid wirings
[ https://issues.apache.org/jira/browse/FELIX-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-4897: - Attachment: FELIX-4897.patch Alternative fix. This fix is likely better because it behaves more closely to the normal resolution flow where processCandidates is called before adding the candidate lists to the Candidates data structure. Dynamic package resolution with fragment package exports can lead to invalid wirings Key: FELIX-4897 URL: https://issues.apache.org/jira/browse/FELIX-4897 Project: Felix Issue Type: Bug Components: Resolver Affects Versions: resolver-1.0.0 Environment: All Reporter: Thomas Watson Attachments: FELIX-4897.patch Similar to FELIX-4428 but the behavior is a regression since the fix for FELIX-4656 was released. The issue is only with dynamic import package resolution. In this case a new CopyOnWriteList is created by Candidates.add(Requirement, ListCapability) from the method Candidates.populateDynamic(ResolveContext, Resource, Requirement, ListCapability) but the original ListCapability list may be modified in the next call to Candidates.processCandidates(ResolveContext, Resource, ListCapability) The issue is that processCandidates is responsible for inserting hosted capabilities into the candidates List. Previously to the fix for FELIX-4656 the passed in List was used as is so modifying it later would effect the list stored in the Candidates data structure also. This is no longer the case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Felix Connect 0.1.0
Thanks for the information Karl. /Pierre On Thu, May 21, 2015 at 11:10 PM, Karl Pauls karlpa...@gmail.com wrote: I think it would be great if you could fix this! To answer the question of Pierre: I don't think we contain all core API in Felix framework nor do we necessarily have to include all in connect IMO. We should however (and do so for framework) include the one we need to run. btw.: there is some bug report here: https://groups.google.com/forum/#!topic/pojosr-discuss/saPAJS25s2Q which I think is still relevant atm. It sounds like it should be pretty straight forward and worthwhile to fix so if you had a moment to do it that would be great (I'm not going to get to it by tomorrow) - otherwise, I'll create a JIRA issue for it and we fix it in a later release. regards, Karl On Thu, May 21, 2015 at 10:13 PM, Guillaume Nodet gno...@apache.org wrote: Yeah, it seems the package is missing, given all the other packages are embedded in the jar. I'll try to cut a new release after adding the missing package tomorrow. 2015-05-20 11:35 GMT+02:00 Pierre De Rop pierre.de...@gmail.com: Hello Guillaume, before voting, I have a question: I was using so far the initial version of Felix connect that was initially committed in the felix-trunk, and this very first release was using using the osgi core 4.3.1 api. So, I just did a non regression test, but got a NoClassDefFoundError on the org/osgi/resource/Capability class because the candidate release is now based on osgi core 5.0.0 api. For example, the org/apache/felix/connect/felix/framework/capabilityset/CapabilitySet.java is importing the org.osgi.resource.Capability. so, I had to include in the classpath the osgi.core-5.0.0.jar and then my non regression test passed OK. but I just wonder if the org/osgi/resource/Capability class should be included in the connect.jar ? and more generally, does the connect.jar contains all the osgi core 5.0.0 API ? (it's the case for the Felix framework, if I'm correct ?) thanks; /Pierre On Mon, May 18, 2015 at 2:49 PM, Guillaume Nodet gno...@apache.org wrote: I've cut a release of Felix Connect 0.1.0 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.connect-0.1.0/ Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1068 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 1068 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Cheers, Guillaume Nodet -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
Re: Strange behaviour with maven bundle plugin 2.5.4
I think it's important that we release Maven Bundle Plugin 2.5.5 soon. If nobody else beats me to it, I'll start a release process early next week. If we don't get a clear testcase for FELIX-4874 soon, then I think we should move that issue to the release after... Cheers, David On 21 May 2015 at 12:07, David Bosschaert david.bosscha...@gmail.com wrote: It would be nice to do a release of the MBP sometime soon. I noticed that there is still this open issue: https://issues.apache.org/jira/browse/FELIX-4874 Does anyone have a testcase for it? Cheers, David On 15 May 2015 at 09:03, Carsten Ziegeler cziege...@apache.org wrote: The reason for this seems to be https://issues.apache.org/jira/browse/FELIX-4882 which I hopefully fixed. Carsten Am 27.04.15 um 19:45 schrieb Carsten Ziegeler: Hi, in the Sling project I noticed a strange behaviour while trying to update the plugin from 2.5.3 to 2.5.4. With the latest version several phases in maven are executed several times, e.g. I see the resources or the SCR plugin running three to four times at the same phase (according to the output). Does anyone experience similar behaviour? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix Connect 0.1.0
Yeah, it seems the package is missing, given all the other packages are embedded in the jar. I'll try to cut a new release after adding the missing package tomorrow. 2015-05-20 11:35 GMT+02:00 Pierre De Rop pierre.de...@gmail.com: Hello Guillaume, before voting, I have a question: I was using so far the initial version of Felix connect that was initially committed in the felix-trunk, and this very first release was using using the osgi core 4.3.1 api. So, I just did a non regression test, but got a NoClassDefFoundError on the org/osgi/resource/Capability class because the candidate release is now based on osgi core 5.0.0 api. For example, the org/apache/felix/connect/felix/framework/capabilityset/CapabilitySet.java is importing the org.osgi.resource.Capability. so, I had to include in the classpath the osgi.core-5.0.0.jar and then my non regression test passed OK. but I just wonder if the org/osgi/resource/Capability class should be included in the connect.jar ? and more generally, does the connect.jar contains all the osgi core 5.0.0 API ? (it's the case for the Felix framework, if I'm correct ?) thanks; /Pierre On Mon, May 18, 2015 at 2:49 PM, Guillaume Nodet gno...@apache.org wrote: I've cut a release of Felix Connect 0.1.0 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.connect-0.1.0/ Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1068 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 1068 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Cheers, Guillaume Nodet
Re: [VOTE] Release Apache Felix Connect 0.1.0
I think it would be great if you could fix this! To answer the question of Pierre: I don't think we contain all core API in Felix framework nor do we necessarily have to include all in connect IMO. We should however (and do so for framework) include the one we need to run. btw.: there is some bug report here: https://groups.google.com/forum/#!topic/pojosr-discuss/saPAJS25s2Q which I think is still relevant atm. It sounds like it should be pretty straight forward and worthwhile to fix so if you had a moment to do it that would be great (I'm not going to get to it by tomorrow) - otherwise, I'll create a JIRA issue for it and we fix it in a later release. regards, Karl On Thu, May 21, 2015 at 10:13 PM, Guillaume Nodet gno...@apache.org wrote: Yeah, it seems the package is missing, given all the other packages are embedded in the jar. I'll try to cut a new release after adding the missing package tomorrow. 2015-05-20 11:35 GMT+02:00 Pierre De Rop pierre.de...@gmail.com: Hello Guillaume, before voting, I have a question: I was using so far the initial version of Felix connect that was initially committed in the felix-trunk, and this very first release was using using the osgi core 4.3.1 api. So, I just did a non regression test, but got a NoClassDefFoundError on the org/osgi/resource/Capability class because the candidate release is now based on osgi core 5.0.0 api. For example, the org/apache/felix/connect/felix/framework/capabilityset/CapabilitySet.java is importing the org.osgi.resource.Capability. so, I had to include in the classpath the osgi.core-5.0.0.jar and then my non regression test passed OK. but I just wonder if the org/osgi/resource/Capability class should be included in the connect.jar ? and more generally, does the connect.jar contains all the osgi core 5.0.0 API ? (it's the case for the Felix framework, if I'm correct ?) thanks; /Pierre On Mon, May 18, 2015 at 2:49 PM, Guillaume Nodet gno...@apache.org wrote: I've cut a release of Felix Connect 0.1.0 http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.connect-0.1.0/ Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1068 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 1068 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Cheers, Guillaume Nodet -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
[jira] [Work started] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[ https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-4883 started by David Bosschaert. --- ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException -- Key: FELIX-4883 URL: https://issues.apache.org/jira/browse/FELIX-4883 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version 1.8.3-R1658944 Reporter: Rob Ryan Assignee: David Bosschaert Priority: Minor Fix For: scr-2.0.0 Attachments: scrtest.zip In our test automation we install a large set of bundles after our also large 'main' app starts up. This causes significant churn as bundles and components are stopped and potentially new versions are started. Unfortunately the coded involved is not open source, so I cannot deliver the full data required to reproduce the failure described here. What I can share is that after all this churn of bundles and components being stopped and started the ScrComponentRuntime service starts to fail with a NullPointerException in getComponentConfigurationDTOs. This was initially noticed as an NPE being reported when visiting the felix console at /system/console/components. The stack at the point of failure is: java.lang.NullPointerException at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205) at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169) at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145) at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119) at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37) ... The NPE occurs because a org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being processed in org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference?) line: 205 has a m_svcObj of null. So even though the bundle is actually available in the object the getBundle() method returns null. [~cziegeler] [~bosschaert] I can investigate further to ideally narrow this down further, but any pointers would be much appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[
https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554007#comment-14554007
]
David Bosschaert commented on FELIX-4883:
-
[~rr...@adobe.com] how should I run your attached test case? It's a test, but
it's in src/main so won't be executed by the maven test running. Moving it to
the test subdirectory gives me a NPE, but I think its a different one:
{code}test(com.robr.incqtest.test.ScrTest) Time elapsed: 0.008 sec ERROR!
java.lang.NullPointerException: null
at
org.apache.sling.junit.annotations.SlingAnnotationsTestRunner.createTest(SlingAnnotationsTestRunner.java:43)
at
org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java{code}
ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
--
Key: FELIX-4883
URL: https://issues.apache.org/jira/browse/FELIX-4883
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version
1.8.3-R1658944
Reporter: Rob Ryan
Assignee: David Bosschaert
Priority: Minor
Fix For: scr-2.0.0
Attachments: scrtest.zip
In our test automation we install a large set of bundles after our also large
'main' app starts up. This causes significant churn as bundles and components
are stopped and potentially new versions are started. Unfortunately the coded
involved is not open source, so I cannot deliver the full data required to
reproduce the failure described here.
What I can share is that after all this churn of bundles and components being
stopped and started the ScrComponentRuntime service starts to fail with a
NullPointerException in getComponentConfigurationDTOs. This was initially
noticed as an NPE being reported when visiting the felix console at
/system/console/components.
The stack at the point of failure is:
java.lang.NullPointerException
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119)
at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37)
...
The NPE occurs because a
org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being
processed in
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference?)
line: 205
has a m_svcObj of null. So even though the bundle is actually available in
the object the getBundle() method returns null.
[~cziegeler] [~bosschaert] I can investigate further to ideally narrow this
down further, but any pointers would be much appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Strange behaviour with maven bundle plugin 2.5.4
It would be nice to do a release of the MBP sometime soon. I noticed that there is still this open issue: https://issues.apache.org/jira/browse/FELIX-4874 Does anyone have a testcase for it? Cheers, David On 15 May 2015 at 09:03, Carsten Ziegeler cziege...@apache.org wrote: The reason for this seems to be https://issues.apache.org/jira/browse/FELIX-4882 which I hopefully fixed. Carsten Am 27.04.15 um 19:45 schrieb Carsten Ziegeler: Hi, in the Sling project I noticed a strange behaviour while trying to update the plugin from 2.5.3 to 2.5.4. With the latest version several phases in maven are executed several times, e.g. I see the resources or the SCR plugin running three to four times at the same phase (according to the output). Does anyone experience similar behaviour? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (FELIX-4895) dead link to FAQ page
[ https://issues.apache.org/jira/browse/FELIX-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554107#comment-14554107 ] David Bosschaert commented on FELIX-4895: - Yeah, seems like its another victim of the website migration effort. You can still see the old version on http://web.archive.org/web/20141029153524/http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html dead link to FAQ page - Key: FELIX-4895 URL: https://issues.apache.org/jira/browse/FELIX-4895 Project: Felix Issue Type: Bug Components: Documentation Reporter: Peter Platek When clicking on FAQ link on: http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html it leads to Page not found -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4860) Revisit HandlerRegistry implementation
[ https://issues.apache.org/jira/browse/FELIX-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554506#comment-14554506 ] Carsten Ziegeler commented on FELIX-4860: - As a first step I've optimized the filter registry: it keeps an immutable data structure which is already sorted by ranking. This allows for effective processing of the filters without any need to later on sort the result set. Revisit HandlerRegistry implementation -- Key: FELIX-4860 URL: https://issues.apache.org/jira/browse/FELIX-4860 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: Thomas Baier Assignee: Carsten Ziegeler Fix For: http.base-3.0.0 The implementation of the HandlerRegistry class needs to be revisited. There is quite some code duplication between the code for the servlet handler registrations and error pages/filter registrations. Also it might be worth checking if the current division into a servlet handler registry and a per context registry is the best solution, also with FELIX-4779 in mind. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4897) Dynamic package resolution with fragment package exports can lead to invalid wirings
[ https://issues.apache.org/jira/browse/FELIX-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554340#comment-14554340 ] David Bosschaert commented on FELIX-4897: - See here for a test case: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=2e359683d0064e3bc331ed25677c8fea128cbfee Dynamic package resolution with fragment package exports can lead to invalid wirings Key: FELIX-4897 URL: https://issues.apache.org/jira/browse/FELIX-4897 Project: Felix Issue Type: Bug Components: Resolver Affects Versions: resolver-1.0.0 Environment: All Reporter: Thomas Watson Fix For: resolver-1.4.0 Attachments: FELIX-4897.patch Similar to FELIX-4428 but the behavior is a regression since the fix for FELIX-4656 was released. The issue is only with dynamic import package resolution. In this case a new CopyOnWriteList is created by Candidates.add(Requirement, ListCapability) from the method Candidates.populateDynamic(ResolveContext, Resource, Requirement, ListCapability) but the original ListCapability list may be modified in the next call to Candidates.processCandidates(ResolveContext, Resource, ListCapability) The issue is that processCandidates is responsible for inserting hosted capabilities into the candidates List. Previously to the fix for FELIX-4656 the passed in List was used as is so modifying it later would effect the list stored in the Candidates data structure also. This is no longer the case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4860) Revisit HandlerRegistry implementation
[ https://issues.apache.org/jira/browse/FELIX-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554393#comment-14554393 ] Carsten Ziegeler commented on FELIX-4860: - I rewrote the handler registration and separated it into three: filter registration, error page registry, servlet registry. The spec has changed and there is no cross context shadowing anymore, which keeps shadowing on a per context base. Revisit HandlerRegistry implementation -- Key: FELIX-4860 URL: https://issues.apache.org/jira/browse/FELIX-4860 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: Thomas Baier Assignee: Carsten Ziegeler Fix For: http.base-3.0.0 The implementation of the HandlerRegistry class needs to be revisited. There is quite some code duplication between the code for the servlet handler registrations and error pages/filter registrations. Also it might be worth checking if the current division into a servlet handler registry and a per context registry is the best solution, also with FELIX-4779 in mind. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4860) Revisit HandlerRegistry implementation
[ https://issues.apache.org/jira/browse/FELIX-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-4860: --- Assignee: Carsten Ziegeler Revisit HandlerRegistry implementation -- Key: FELIX-4860 URL: https://issues.apache.org/jira/browse/FELIX-4860 Project: Felix Issue Type: Sub-task Components: HTTP Service Reporter: Thomas Baier Assignee: Carsten Ziegeler Fix For: http.base-3.0.0 The implementation of the HandlerRegistry class needs to be revisited. There is quite some code duplication between the code for the servlet handler registrations and error pages/filter registrations. Also it might be worth checking if the current division into a servlet handler registry and a per context registry is the best solution, also with FELIX-4779 in mind. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[
https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554518#comment-14554518
]
David Jencks commented on FELIX-4883:
-
I don't understand your suggestion. The code in question:
Bundle[] usingBundles = serviceRef.getUsingBundles();
if (usingBundles != null)
{
long[] usingBundleIds = new long[usingBundles.length];
for (int i = 0; i usingBundles.length; i++)
{
usingBundleIds[i] = usingBundles[i].getBundleId(); NPE!!
}
dto.usingBundles = usingBundleIds;
}
So serviceRef.getUsingBundles(); has returned an array with at least one null.
This is probably incorrect, but it might be wiser to allow for this potential
bug in frameworks and just ignore null bundles?
Bundle[] usingBundles = serviceRef.getUsingBundles();
if (usingBundles != null)
{
long[] usingBundleIds = new long[usingBundles.length];
int i = 0;
for (Bundle usingBundle: usingBundles)
{
if (usingBundle != null) {
usingBundleIds[i++] = usingBundle.getBundleId();
}
}
if (i usingBundleIds.length) {
usingBundleIds = Arrays.copyOf(usingBundleIds, i);
}
dto.usingBundles = usingBundleIds;
}
ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
--
Key: FELIX-4883
URL: https://issues.apache.org/jira/browse/FELIX-4883
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version
1.8.3-R1658944
Reporter: Rob Ryan
Assignee: David Bosschaert
Priority: Minor
Fix For: scr-2.0.0
Attachments: scrtest.zip
In our test automation we install a large set of bundles after our also large
'main' app starts up. This causes significant churn as bundles and components
are stopped and potentially new versions are started. Unfortunately the coded
involved is not open source, so I cannot deliver the full data required to
reproduce the failure described here.
What I can share is that after all this churn of bundles and components being
stopped and started the ScrComponentRuntime service starts to fail with a
NullPointerException in getComponentConfigurationDTOs. This was initially
noticed as an NPE being reported when visiting the felix console at
/system/console/components.
The stack at the point of failure is:
java.lang.NullPointerException
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119)
at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37)
...
The NPE occurs because a
org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being
processed in
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference?)
line: 205
has a m_svcObj of null. So even though the bundle is actually available in
the object the getBundle() method returns null.
[~cziegeler] [~bosschaert] I can investigate further to ideally narrow this
down further, but any pointers would be much appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4897) Dynamic package resolution with fragment package exports can lead to invalid wirings
[ https://issues.apache.org/jira/browse/FELIX-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-4897. Resolution: Fixed Fix Version/s: resolver-1.4.0 The patch looks simple enough, I've applied. Please close if satisfied, thanks! Dynamic package resolution with fragment package exports can lead to invalid wirings Key: FELIX-4897 URL: https://issues.apache.org/jira/browse/FELIX-4897 Project: Felix Issue Type: Bug Components: Resolver Affects Versions: resolver-1.0.0 Environment: All Reporter: Thomas Watson Fix For: resolver-1.4.0 Attachments: FELIX-4897.patch Similar to FELIX-4428 but the behavior is a regression since the fix for FELIX-4656 was released. The issue is only with dynamic import package resolution. In this case a new CopyOnWriteList is created by Candidates.add(Requirement, ListCapability) from the method Candidates.populateDynamic(ResolveContext, Resource, Requirement, ListCapability) but the original ListCapability list may be modified in the next call to Candidates.processCandidates(ResolveContext, Resource, ListCapability) The issue is that processCandidates is responsible for inserting hosted capabilities into the candidates List. Previously to the fix for FELIX-4656 the passed in List was used as is so modifying it later would effect the list stored in the Candidates data structure also. This is no longer the case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Apache Felix Dependency Manager Release Candidate R3
+1 (non binding) Regards JB On 05/21/2015 08:35 PM, Pierre De Rop wrote: Hello all, I would like to call for a vote on the Dependency Manager toplevel release R3. We solved the following issues: ** Bug * [FELIX-4858] - DependencyManager: missing createCopy method in timed service dependency * [FELIX-4869] - Callbacks not invoked for dependencies that are added after the component is initialized ** Improvement * [FELIX-4614] - Factory create() method should have access to the component definition * [FELIX-4873] - Enhance DM API to get missing and circular dependencies * [FELIX-4876] - DM Annotations bnd plugin compatibility with Bndtools 2.4.1 / 3.0.0 versions * [FELIX-4877] - DM Annotations should detect service type using more method signatures. * [FELIX-4878] - Support more signatures for Dependency callbacks * [FELIX-4880] - Missing callback instance support for some adapters * [FELIX-4889] - Refactor dm shell command to use the org.apache.dm.diagnostics api ** Wish * [FELIX-4875] - Update DM integration test with latest ConfigAdmin 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 r3 /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 -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
[jira] [Reopened] (FELIX-4879) ConfigurationDependency should always need instance.
[ https://issues.apache.org/jira/browse/FELIX-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop reopened FELIX-4879: -- ConfigurationDependency should always need instance. -- Key: FELIX-4879 URL: https://issues.apache.org/jira/browse/FELIX-4879 Project: Felix Issue Type: Improvement Components: Dependency Manager Affects Versions: org.apache.felix.dependencymanager-r2 Reporter: Pierre De Rop Assignee: Pierre De Rop Priority: Minor Fix For: org.apache.felix.dependencymanager-r3 Currently, the ConfigurationDependency only specifies that it needs an instance if there is no callback instance. But if there is a callback instance, then the needsInstance method returns false (because we have the callback instance already). So, from one side, it makes sense to not require a component instance if there is a callback instance configured (since we have the callback instance, we don't need the component instance). However, the callback instance is then not able to get access to the component instances while being invoked (the first time), using the Component object. So, the ConfigurationDependency should always have a needsInstance method returning true (always), even if there is a callback instance configured for the Configuration Dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Apache Felix Dependency Manager Release Candidate R3
+1 (non binding) Built from sources, ran tests and did some quick tests in an application. Thanks Pierre! Cheers, Paul On Thu, May 21, 2015 at 8:35 PM Pierre De Rop pierre.de...@gmail.com wrote: Hello all, I would like to call for a vote on the Dependency Manager toplevel release R3. We solved the following issues: ** Bug * [FELIX-4858] - DependencyManager: missing createCopy method in timed service dependency * [FELIX-4869] - Callbacks not invoked for dependencies that are added after the component is initialized ** Improvement * [FELIX-4614] - Factory create() method should have access to the component definition * [FELIX-4873] - Enhance DM API to get missing and circular dependencies * [FELIX-4876] - DM Annotations bnd plugin compatibility with Bndtools 2.4.1 / 3.0.0 versions * [FELIX-4877] - DM Annotations should detect service type using more method signatures. * [FELIX-4878] - Support more signatures for Dependency callbacks * [FELIX-4880] - Missing callback instance support for some adapters * [FELIX-4889] - Refactor dm shell command to use the org.apache.dm.diagnostics api ** Wish * [FELIX-4875] - Update DM integration test with latest ConfigAdmin 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 r3 /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
[jira] [Commented] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[ https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554934#comment-14554934 ] David Bosschaert commented on FELIX-4883: - I guessed that the problem may be there, but rather than guessing I prefer to run your testcase so that I can be sure that the problem is fixed. You have attached a testcase, but I can't run it. I would appreciate if you could tell me how to run the testcase (a simple 'mvn install' didn't work as mentioned above) so that I can expose the problem and then ensure that its fixed. ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException -- Key: FELIX-4883 URL: https://issues.apache.org/jira/browse/FELIX-4883 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version 1.8.3-R1658944 Reporter: Rob Ryan Assignee: David Bosschaert Priority: Minor Fix For: scr-2.0.0 Attachments: scrtest.zip In our test automation we install a large set of bundles after our also large 'main' app starts up. This causes significant churn as bundles and components are stopped and potentially new versions are started. Unfortunately the coded involved is not open source, so I cannot deliver the full data required to reproduce the failure described here. What I can share is that after all this churn of bundles and components being stopped and started the ScrComponentRuntime service starts to fail with a NullPointerException in getComponentConfigurationDTOs. This was initially noticed as an NPE being reported when visiting the felix console at /system/console/components. The stack at the point of failure is: java.lang.NullPointerException at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205) at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169) at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145) at org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119) at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37) ... The NPE occurs because a org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being processed in org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference?) line: 205 has a m_svcObj of null. So even though the bundle is actually available in the object the getBundle() method returns null. [~cziegeler] [~bosschaert] I can investigate further to ideally narrow this down further, but any pointers would be much appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[
https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554543#comment-14554543
]
Rob Ryan edited comment on FELIX-4883 at 5/21/15 3:45 PM:
--
The particular point where this exception was seen was:
private ServiceReferenceDTO serviceReferenceToDTO( ServiceReference?
serviceRef)
{
ServiceReferenceDTO dto = new ServiceReferenceDTO();
Bundle bundle = serviceRef.getBundle(); // -- NPE was here.
This is the kind of context where checking null may be appropriate
defensiveness IMO...
But in the end the bug originates with bad calling of the service registration
APIs where a call to update service registration properties while the service
was unregistered resulted in bad state in the SCR. I can try to reduce the
proprietary code to an example which can be publicly disclosed.
was (Author: rr...@adobe.com):
The particular point where this exception was seen was:
private ServiceReferenceDTO serviceReferenceToDTO( ServiceReference?
serviceRef)
{
ServiceReferenceDTO dto = new ServiceReferenceDTO();
Bundle bundle = serviceRef.getBundle();
This is the kind of context where checking null may be appropriate
defensiveness IMO...
But in the end the bug originates with bad calling of the service registration
APIs where a call to update service registration properties while the service
was unregistered resulted in bad state in the SCR. I can try to reduce the
proprietary code to an example which can be publicly disclosed.
ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
--
Key: FELIX-4883
URL: https://issues.apache.org/jira/browse/FELIX-4883
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version
1.8.3-R1658944
Reporter: Rob Ryan
Assignee: David Bosschaert
Priority: Minor
Fix For: scr-2.0.0
Attachments: scrtest.zip
In our test automation we install a large set of bundles after our also large
'main' app starts up. This causes significant churn as bundles and components
are stopped and potentially new versions are started. Unfortunately the coded
involved is not open source, so I cannot deliver the full data required to
reproduce the failure described here.
What I can share is that after all this churn of bundles and components being
stopped and started the ScrComponentRuntime service starts to fail with a
NullPointerException in getComponentConfigurationDTOs. This was initially
noticed as an NPE being reported when visiting the felix console at
/system/console/components.
The stack at the point of failure is:
java.lang.NullPointerException
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119)
at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37)
...
The NPE occurs because a
org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being
processed in
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference?)
line: 205
has a m_svcObj of null. So even though the bundle is actually available in
the object the getBundle() method returns null.
[~cziegeler] [~bosschaert] I can investigate further to ideally narrow this
down further, but any pointers would be much appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4883) ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
[
https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554543#comment-14554543
]
Rob Ryan commented on FELIX-4883:
-
The particular point where this exception was seen was:
private ServiceReferenceDTO serviceReferenceToDTO( ServiceReference?
serviceRef)
{
ServiceReferenceDTO dto = new ServiceReferenceDTO();
Bundle bundle = serviceRef.getBundle();
This is the kind of context where checking null may be appropriate
defensiveness IMO...
But in the end the bug originates with bad calling of the service registration
APIs where a call to update service registration properties while the service
was unregistered resulted in bad state in the SCR. I can try to reduce the
proprietary code to an example which can be publicly disclosed.
ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
--
Key: FELIX-4883
URL: https://issues.apache.org/jira/browse/FELIX-4883
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version
1.8.3-R1658944
Reporter: Rob Ryan
Assignee: David Bosschaert
Priority: Minor
Fix For: scr-2.0.0
Attachments: scrtest.zip
In our test automation we install a large set of bundles after our also large
'main' app starts up. This causes significant churn as bundles and components
are stopped and potentially new versions are started. Unfortunately the coded
involved is not open source, so I cannot deliver the full data required to
reproduce the failure described here.
What I can share is that after all this churn of bundles and components being
stopped and started the ScrComponentRuntime service starts to fail with a
NullPointerException in getComponentConfigurationDTOs. This was initially
noticed as an NPE being reported when visiting the felix console at
/system/console/components.
The stack at the point of failure is:
java.lang.NullPointerException
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145)
at
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119)
at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37)
...
The NPE occurs because a
org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being
processed in
org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference?)
line: 205
has a m_svcObj of null. So even though the bundle is actually available in
the object the getBundle() method returns null.
[~cziegeler] [~bosschaert] I can investigate further to ideally narrow this
down further, but any pointers would be much appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
