[jira] [Commented] (FELIX-2809) maven-bundle-plugin should automatically add resolution:=optional to imported packages that are in optional maven dependencies.
[ https://issues.apache.org/jira/browse/FELIX-2809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193648#comment-13193648 ] Tuomas Kiviaho commented on FELIX-2809: --- Just reporting my observations here even though the issue has been resolved long time ago. I believe that there are no such things as transitively included optional dependencies, so the latter of the patches wouldn't have an effect that I think was intended. More of a problem is a scenario where Import-Packages ends up with references to optional dependencies of transitive dependencies. resteasy-jaws for instance contains optional TJWS dependency plus classes referencing to it. There is no way that BND could separate packages of these unwanted classes from packages of required classes. It could be possible to seek though the dependency tree and gather optional dependencies of transitive dependencies, pass them to BND as well in such manner that generated possibility of split packages issue is taken care of. Later on packages of gathered dependencies can be removed from list actual packages of project itself and it's transitive dependencies (provided that aftifact files of each required dependency are present) maven-bundle-plugin should automatically add resolution:=optional to imported packages that are in optional maven dependencies. -- Key: FELIX-2809 URL: https://issues.apache.org/jira/browse/FELIX-2809 Project: Felix Issue Type: Improvement Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: maven-bundle-plugin-2.3.4 -- 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] Release Felix Lightweight HTTP Service version 0.1.4
+1 Carsten 2012/1/20 Ken Gilmer kgil...@gmail.com: Hello, We resolved 3 defects and added 3 features in this release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+FELIX+AND+component+%3D+%22Lightweight+HTTP+Service%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESCmode=hide There are currently no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-108/ 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 108 /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. -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (FELIX-3317) Concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193705#comment-13193705 ] Felix Meschberger commented on FELIX-3317: -- Committed a first fix in Rev. 1236123 This implements the second option by checking the consistency before assigning the service registration field: If the state is (still) the same after registering the service and the service registration field is still null (concurrent execution might have already set the field) the field is set. Otherwise a WARN message is logged with the log service and the service is unregistered again. Concurrency issue during Component Service registration --- Key: FELIX-3317 URL: https://issues.apache.org/jira/browse/FELIX-3317 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.6.2 In our Sling-based application we saw the following behavior: The Sling ResourceResolverFactory is a component being activated. Yet every now and then a field of that component seems to become null which is not expected for an activated ResourceResolverFactory component and thus causes a NullPointerException. Upon inspection I saw, that for the same Declarative Services component two Services have been registered where only one was actually expected. Turns out that consumers of the ResoureResovlerFactory where all bound to the same service. The component on the other hand has been cycled due to a configuration update. So one service is backed by a deactivated component (whose field has been reset to null already) and the other service is live. The problem is that the service backed by the deactivated method has not been unregistered and thus all consumers are hooked up to the deactivated instance causing all sorts of problems ... This is what most probably happens in the AbstractComponentManager: * T1 Unsatisfied.activate has set the state to Active already before calling registerService * T1 registerService is called but the service registration field field is not assigned yet during registerService ServiceListeners are called * T2 A Configuration update comes in and Satisfied(Active).deactivate is called * T2 calls unregisterComponentService; does nothing because the service registration field is not assigned * T2 destroys component * T1 assigns field from service registration As a result the deactivated object's service registration may be unregistered later when the component is cycled again and the second service registration will only be unregistered when the providing bundle is restarted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3317) Concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193752#comment-13193752 ] Felix Meschberger commented on FELIX-3317: -- Improved state check in Rev. 1236132: a delayed or service factory component may be really activated during service registration and thus may change the state from Registered to Active. This is perfectly valid and thus must not cause the service registration to be thrown away. Also improved logging of the Service Reference to get some usefull information out of it. Concurrency issue during Component Service registration --- Key: FELIX-3317 URL: https://issues.apache.org/jira/browse/FELIX-3317 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.6.2 In our Sling-based application we saw the following behavior: The Sling ResourceResolverFactory is a component being activated. Yet every now and then a field of that component seems to become null which is not expected for an activated ResourceResolverFactory component and thus causes a NullPointerException. Upon inspection I saw, that for the same Declarative Services component two Services have been registered where only one was actually expected. Turns out that consumers of the ResoureResovlerFactory where all bound to the same service. The component on the other hand has been cycled due to a configuration update. So one service is backed by a deactivated component (whose field has been reset to null already) and the other service is live. The problem is that the service backed by the deactivated method has not been unregistered and thus all consumers are hooked up to the deactivated instance causing all sorts of problems ... This is what most probably happens in the AbstractComponentManager: * T1 Unsatisfied.activate has set the state to Active already before calling registerService * T1 registerService is called but the service registration field field is not assigned yet during registerService ServiceListeners are called * T2 A Configuration update comes in and Satisfied(Active).deactivate is called * T2 calls unregisterComponentService; does nothing because the service registration field is not assigned * T2 destroys component * T1 assigns field from service registration As a result the deactivated object's service registration may be unregistered later when the component is cycled again and the second service registration will only be unregistered when the providing bundle is restarted. -- 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] [Reopened] (FELIX-3268) Cannot build webconsole and webconsole-plugins with JDK 7
[ https://issues.apache.org/jira/browse/FELIX-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev reopened FELIX-3268: - The new native2ascii-maven-plugin actually does nothing. So localization is missing. My own plugins (build with ant) are localized correctly, but webconsole - doesn't show in the language I choose. I looked at the jar file and it seems, that doesn't include any extra resources besides bundle.properties Cannot build webconsole and webconsole-plugins with JDK 7 - Key: FELIX-3268 URL: https://issues.apache.org/jira/browse/FELIX-3268 Project: Felix Issue Type: Bug Components: Web Console Environment: Debian unstable x86_64, JDK 7 from http://jdk7.java.net/download.html, Maven 3.0.3 Reporter: Lionel Debroux Assignee: Felix Meschberger Labels: patch Fix For: webconsole-upnp-plugin-1.0.2, webconsole-shell-plugin-1.0.0, webconsole-obr-plugin-1.0.0, webconsole-ds-plugin-1.0.0, webconsole-deployment-admin-plugin-1.0.0, webconsole-3.2.0, webconsole-event-plugin-1.0.4 A search in JIRA returned no match for native2ascii and no relevant match for native, so I'm creating an issue. When trying to build Felix SVN HEAD with JDK 7, the build process stops when it fails to invoke native2ascii in webconsole. It seems that there was a change between JDK 6 and JDK 7, and the 1.0-alpha-1 version of org.codehaus.mojo:native2ascii-maven-plugin in multiple POMs cannot handle it. However, version 1.0-beta-1 (I obtained that version number by removing the version parameter entirely) can cope with JDK 7. The patch below fixes the build problem in webconsole webconsole-plugins: diff --git a/webconsole-plugins/deppack/pom.xml b/webconsole-plugins/deppack/pom.xml index 0c764e6..e576a57 100644 --- a/webconsole-plugins/deppack/pom.xml +++ b/webconsole-plugins/deppack/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId - version1.0-alpha-1/version + version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/ds/pom.xml b/webconsole-plugins/ds/pom.xml index 40a3224..338f306 100644 --- a/webconsole-plugins/ds/pom.xml +++ b/webconsole-plugins/ds/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId -version1.0-alpha-1/version +version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/event/pom.xml b/webconsole-plugins/event/pom.xml index b257032..2375eab 100644 --- a/webconsole-plugins/event/pom.xml +++ b/webconsole-plugins/event/pom.xml @@ -48,7 +48,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId -version1.0-alpha-1/version +version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/obr/pom.xml b/webconsole-plugins/obr/pom.xml index c4a88f2..3854ca3 100644 --- a/webconsole-plugins/obr/pom.xml +++ b/webconsole-plugins/obr/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId - version1.0-alpha-1/version + version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/shell/pom.xml b/webconsole-plugins/shell/pom.xml index 661d3cd..7f1b428 100644 --- a/webconsole-plugins/shell/pom.xml +++ b/webconsole-plugins/shell/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId - version1.0-alpha-1/version + version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/upnp/pom.xml b/webconsole-plugins/upnp/pom.xml index
[jira] [Assigned] (FELIX-3311) Cookie handling seems not to work anymore
[ https://issues.apache.org/jira/browse/FELIX-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev reassigned FELIX-3311: --- Assignee: Valentin Valchev Cookie handling seems not to work anymore - Key: FELIX-3311 URL: https://issues.apache.org/jira/browse/FELIX-3311 Project: Felix Issue Type: Bug Components: Web Console Reporter: Carsten Ziegeler Assignee: Valentin Valchev Fix For: webconsole-3.2.0 Sorting the bundle list, switching to another tab and going back shows the bundle list in the original sort order but not in the one previously picked As this information is in a cookie I assume that cookie handling does now work differently -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3311) Cookie handling seems not to work anymore
[ https://issues.apache.org/jira/browse/FELIX-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev resolved FELIX-3311. - Resolution: Fixed Fixed in rev.1236136 Cookie handling seems not to work anymore - Key: FELIX-3311 URL: https://issues.apache.org/jira/browse/FELIX-3311 Project: Felix Issue Type: Bug Components: Web Console Reporter: Carsten Ziegeler Assignee: Valentin Valchev Fix For: webconsole-3.2.0 Sorting the bundle list, switching to another tab and going back shows the bundle list in the original sort order but not in the one previously picked As this information is in a cookie I assume that cookie handling does now work differently -- 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: svn commit: r1236136 - in /felix/trunk/webconsole/src/main: java/org/apache/felix/webconsole/internal/servlet/OsgiManager.java resources/res/lib/support.js
Hi,
Am 26.01.2012 um 12:03 schrieb vvalc...@apache.org:
-private static final String COOKIE_LOCALE = felix.webconsole.locale;
//$NON-NLS-1$
+private static final String COOKIE_LOCALE = felix-webconsole-locale;
//$NON-NLS-1$
Sorry, missed that ...
@@ -289,7 +290,7 @@ function setCookie( /* String */name, /*
* @param name The name of the cookie
*/
/* String */ function getCookie(/*String */name) {
-$.cookies.get(felix-webconsole- + name);
+return $.cookies.get(felix-webconsole- + name);
}
Argh ! Stupid me !! Thanks for fixing.
Regards
Felix
Re: [VOTE] Release Felix Lightweight HTTP Service version 0.1.4
The complete bundle includes OSGi classes, but does not list them in the NOTICE file. It's not clear to me if this is a requirement, since they OSGi artifacts themselves don't include a NOTICE, but we generally do include them in the NOTICE file for the framework JARs. Also, I noticed that the DEPs file for the complete bundle was the old format while the core bundle was auto-generated, was there a reason for this? - richard On 1/20/12 0:57, Ken Gilmer wrote: Hello, We resolved 3 defects and added 3 features in this release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+FELIX+AND+component+%3D+%22Lightweight+HTTP+Service%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESCmode=hide There are currently no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-108/ 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 108 /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.
Re: [VOTE] Release Felix Lightweight HTTP Service version 0.1.4
Hi Richard, On Thu, Jan 26, 2012 at 9:32 PM, Richard S. Hall he...@ungoverned.org wrote: The complete bundle includes OSGi classes, but does not list them in the NOTICE file. It's not clear to me if this is a requirement, since they OSGi artifacts themselves don't include a NOTICE, but we generally do include them in the NOTICE file for the framework JARs. In my memory I'd checked the http-bundle module and followed it but now that I check again I can see that it does in fact include the OSGi classes in the NOTICE. I can add that. Also, I noticed that the DEPs file for the complete bundle was the old format while the core bundle was auto-generated, was there a reason for this? That is very strange. It took me a bit to figure out what you meant. On my local machine where I did the build the jars both contain the old format (meaning, not auto generated). But when I download the jars from the repo I can see that the complete bundle has the auto generated DEPENDENCIES file. I was under assumption that what I was building locally was what was being sent to the repo. thx ken - richard On 1/20/12 0:57, Ken Gilmer wrote: Hello, We resolved 3 defects and added 3 features in this release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+FELIX+AND+component+%3D+%22Lightweight+HTTP+Service%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESCmode=hide There are currently no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-108/ 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 108 /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.
Re: [VOTE] Release Felix Lightweight HTTP Service version 0.1.4
On 1/26/12 8:09, Ken Gilmer wrote: Hi Richard, On Thu, Jan 26, 2012 at 9:32 PM, Richard S. Hallhe...@ungoverned.org wrote: The complete bundle includes OSGi classes, but does not list them in the NOTICE file. It's not clear to me if this is a requirement, since they OSGi artifacts themselves don't include a NOTICE, but we generally do include them in the NOTICE file for the framework JARs. In my memory I'd checked the http-bundle module and followed it but now that I check again I can see that it does in fact include the OSGi classes in the NOTICE. I can add that. Also, I noticed that the DEPs file for the complete bundle was the old format while the core bundle was auto-generated, was there a reason for this? That is very strange. It took me a bit to figure out what you meant. On my local machine where I did the build the jars both contain the old format (meaning, not auto generated). But when I download the jars from the repo I can see that the complete bundle has the auto generated DEPENDENCIES file. I was under assumption that what I was building locally was what was being sent to the repo. Yeah, I certainly don't know what's going on...I depend on Karl for releasing stuff. ;-) The DEPs file stuff isn't so important anyway, I only mention for reasons of consistency...my real question is about the NOTICE. If others think it isn't important, then we are probably good to go. Thanks. - richard thx ken - richard On 1/20/12 0:57, Ken Gilmer wrote: Hello, We resolved 3 defects and added 3 features in this release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+FELIX+AND+component+%3D+%22Lightweight+HTTP+Service%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESCmode=hide There are currently no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-108/ 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 108 /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.
Re: [VOTE] Release Felix Lightweight HTTP Service version 0.1.4
On Thu, Jan 26, 2012 at 2:35 PM, Richard S. Hall he...@ungoverned.org wrote: On 1/26/12 8:09, Ken Gilmer wrote: Hi Richard, On Thu, Jan 26, 2012 at 9:32 PM, Richard S. Hallhe...@ungoverned.org wrote: The complete bundle includes OSGi classes, but does not list them in the NOTICE file. It's not clear to me if this is a requirement, since they OSGi artifacts themselves don't include a NOTICE, but we generally do include them in the NOTICE file for the framework JARs. In my memory I'd checked the http-bundle module and followed it but now that I check again I can see that it does in fact include the OSGi classes in the NOTICE. I can add that. Also, I noticed that the DEPs file for the complete bundle was the old format while the core bundle was auto-generated, was there a reason for this? That is very strange. It took me a bit to figure out what you meant. On my local machine where I did the build the jars both contain the old format (meaning, not auto generated). But when I download the jars from the repo I can see that the complete bundle has the auto generated DEPENDENCIES file. I was under assumption that what I was building locally was what was being sent to the repo. Yeah, I certainly don't know what's going on...I depend on Karl for releasing stuff. ;-) The DEPs file stuff isn't so important anyway, I only mention for reasons of consistency...my real question is about the NOTICE. If others think it isn't important, then we are probably good to go. I'd say it is up to the Release Manager (i.e., Ken in this case). The osgi jars don't contain a NOTICE so they don't have to be mentioned. I guess I just fix it in trunk and go ahead with the release unless it is easy for you to re-roll at this time. Just let us know what you want to do... regards, Karl Thanks. - richard thx ken - richard On 1/20/12 0:57, Ken Gilmer wrote: Hello, We resolved 3 defects and added 3 features in this release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+FELIX+AND+component+%3D+%22Lightweight+HTTP+Service%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESCmode=hide There are currently no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-108/ 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 108 /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. -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
Re: [VOTE] Release Felix Lightweight HTTP Service version 0.1.4
Thanks for your feedback Richard and Karl. Well, given my luck with exploding stuff in wonderful strange ways, I'd prefer the fix it in trunk and continue with the given release route. But, I'm also happy to fix the NOTICE and roll a new release if anyone would prefer me to do that. thx, ken On Thu, Jan 26, 2012 at 10:41 PM, Karl Pauls karlpa...@gmail.com wrote: On Thu, Jan 26, 2012 at 2:35 PM, Richard S. Hall he...@ungoverned.org wrote: On 1/26/12 8:09, Ken Gilmer wrote: Hi Richard, On Thu, Jan 26, 2012 at 9:32 PM, Richard S. Hallhe...@ungoverned.org wrote: The complete bundle includes OSGi classes, but does not list them in the NOTICE file. It's not clear to me if this is a requirement, since they OSGi artifacts themselves don't include a NOTICE, but we generally do include them in the NOTICE file for the framework JARs. In my memory I'd checked the http-bundle module and followed it but now that I check again I can see that it does in fact include the OSGi classes in the NOTICE. I can add that. Also, I noticed that the DEPs file for the complete bundle was the old format while the core bundle was auto-generated, was there a reason for this? That is very strange. It took me a bit to figure out what you meant. On my local machine where I did the build the jars both contain the old format (meaning, not auto generated). But when I download the jars from the repo I can see that the complete bundle has the auto generated DEPENDENCIES file. I was under assumption that what I was building locally was what was being sent to the repo. Yeah, I certainly don't know what's going on...I depend on Karl for releasing stuff. ;-) The DEPs file stuff isn't so important anyway, I only mention for reasons of consistency...my real question is about the NOTICE. If others think it isn't important, then we are probably good to go. I'd say it is up to the Release Manager (i.e., Ken in this case). The osgi jars don't contain a NOTICE so they don't have to be mentioned. I guess I just fix it in trunk and go ahead with the release unless it is easy for you to re-roll at this time. Just let us know what you want to do... regards, Karl Thanks. - richard thx ken - richard On 1/20/12 0:57, Ken Gilmer wrote: Hello, We resolved 3 defects and added 3 features in this release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+FELIX+AND+component+%3D+%22Lightweight+HTTP+Service%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESCmode=hide There are currently no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-108/ 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 108 /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. -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
[jira] [Created] (FELIX-3318) NPE in WebConsole when trying to uninstall a bundle
NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Web Console Reporter: Alex Parvulescu Priority: Minor Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- 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-3318) NPE in WebConsole when trying to uninstall a bundle
[ https://issues.apache.org/jira/browse/FELIX-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated FELIX-3318: --- Attachment: FELIX-3318.patch Not sure if this could be better fixed in the framework directly (in PackageAdminImpl), but here's a patch for the WebConsole code that handles the delete. I just basically moved the isFragmentBundle check up, before the delete operation, this seems to fix the issue (or hide it better :) NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Web Console Reporter: Alex Parvulescu Priority: Minor Attachments: FELIX-3318.patch Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- This message is automatically generated by JIRA. If
[jira] [Commented] (FELIX-3318) NPE in WebConsole when trying to uninstall a bundle
[ https://issues.apache.org/jira/browse/FELIX-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193849#comment-13193849 ] Felix Meschberger commented on FELIX-3318: -- I think this is a bug in the PackageAdminImpl.getBundleType method: This calls adapt to get the BundleRevision of the bundle which returns null for uninstalled bundles (probably correctly). Yet this result is not checked in the getBundleType method and thus the NPE. NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Web Console Reporter: Alex Parvulescu Priority: Minor Attachments: FELIX-3318.patch Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- This message is automatically generated by JIRA. If
[jira] [Updated] (FELIX-3318) NPE in WebConsole when trying to uninstall a bundle
[ https://issues.apache.org/jira/browse/FELIX-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-3318: - Component/s: (was: Web Console) Framework Affects Version/s: framework-4.0.2 Reassigning to the framework -- this problem still exists in trunk NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.0.2 Reporter: Alex Parvulescu Priority: Minor Attachments: FELIX-3318.patch Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] [Commented] (FELIX-3318) NPE in WebConsole when trying to uninstall a bundle
[ https://issues.apache.org/jira/browse/FELIX-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193852#comment-13193852 ] Alex Parvulescu commented on FELIX-3318: Oups, forgot to mention that the delete actually happens. The NPE is apparently caused by the response string builder, that is why I moved the isFragmentBundle check up, before the uninstall op. NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.0.2 Reporter: Alex Parvulescu Priority: Minor Attachments: FELIX-3318.patch Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly,
[jira] [Commented] (FELIX-3318) NPE in WebConsole when trying to uninstall a bundle
[ https://issues.apache.org/jira/browse/FELIX-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193853#comment-13193853 ] Felix Meschberger commented on FELIX-3318: -- Hmm, since the PackageAdminImpl.getBundleType method actually wants to have the BundleRevisionImpl class, it should probably ask for it. This should never return null, probably. NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.0.2 Reporter: Alex Parvulescu Priority: Minor Attachments: FELIX-3318.patch Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact
Re: [VOTE] Release Felix Lightweight HTTP Service version 0.1.4
+1 on the release if the NOTICE as soon as it is fixed in trunk. regards, Karl On Thu, Jan 26, 2012 at 2:50 PM, Ken Gilmer kgil...@gmail.com wrote: Thanks for your feedback Richard and Karl. Well, given my luck with exploding stuff in wonderful strange ways, I'd prefer the fix it in trunk and continue with the given release route. But, I'm also happy to fix the NOTICE and roll a new release if anyone would prefer me to do that. thx, ken On Thu, Jan 26, 2012 at 10:41 PM, Karl Pauls karlpa...@gmail.com wrote: On Thu, Jan 26, 2012 at 2:35 PM, Richard S. Hall he...@ungoverned.org wrote: On 1/26/12 8:09, Ken Gilmer wrote: Hi Richard, On Thu, Jan 26, 2012 at 9:32 PM, Richard S. Hallhe...@ungoverned.org wrote: The complete bundle includes OSGi classes, but does not list them in the NOTICE file. It's not clear to me if this is a requirement, since they OSGi artifacts themselves don't include a NOTICE, but we generally do include them in the NOTICE file for the framework JARs. In my memory I'd checked the http-bundle module and followed it but now that I check again I can see that it does in fact include the OSGi classes in the NOTICE. I can add that. Also, I noticed that the DEPs file for the complete bundle was the old format while the core bundle was auto-generated, was there a reason for this? That is very strange. It took me a bit to figure out what you meant. On my local machine where I did the build the jars both contain the old format (meaning, not auto generated). But when I download the jars from the repo I can see that the complete bundle has the auto generated DEPENDENCIES file. I was under assumption that what I was building locally was what was being sent to the repo. Yeah, I certainly don't know what's going on...I depend on Karl for releasing stuff. ;-) The DEPs file stuff isn't so important anyway, I only mention for reasons of consistency...my real question is about the NOTICE. If others think it isn't important, then we are probably good to go. I'd say it is up to the Release Manager (i.e., Ken in this case). The osgi jars don't contain a NOTICE so they don't have to be mentioned. I guess I just fix it in trunk and go ahead with the release unless it is easy for you to re-roll at this time. Just let us know what you want to do... regards, Karl Thanks. - richard thx ken - richard On 1/20/12 0:57, Ken Gilmer wrote: Hello, We resolved 3 defects and added 3 features in this release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+FELIX+AND+component+%3D+%22Lightweight+HTTP+Service%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESCmode=hide There are currently no outstanding issues. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-108/ 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 108 /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. -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
[jira] [Created] (FELIX-3319) Add invalid topics when not accepting EventHandler
Add invalid topics when not accepting EventHandler -- Key: FELIX-3319 URL: https://issues.apache.org/jira/browse/FELIX-3319 Project: Felix Issue Type: Improvement Components: Event Admin Affects Versions: eventadmin-1.2.14 Reporter: Felix Meschberger If an EventHandler is registered with invalid topics, the EventAdmin services logs a message along these lines at WARN level: 26.01.2012 14:07:28.593 *WARN* [FelixStartLevel] org.apache.felix.eventadmin Service [xxx,111] EventAdmin: Invalid EVENT_TOPICS - Ignoring ServiceReference [[xxx] | Bundle(smbolic.name [111])] Could this message be improved indicating what exactly the topics are, which are considered invalid ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3317) Concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3317. -- Resolution: Fixed I think this works now. Will create follow-up issues if problems surface. Concurrency issue during Component Service registration --- Key: FELIX-3317 URL: https://issues.apache.org/jira/browse/FELIX-3317 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.6.2 In our Sling-based application we saw the following behavior: The Sling ResourceResolverFactory is a component being activated. Yet every now and then a field of that component seems to become null which is not expected for an activated ResourceResolverFactory component and thus causes a NullPointerException. Upon inspection I saw, that for the same Declarative Services component two Services have been registered where only one was actually expected. Turns out that consumers of the ResoureResovlerFactory where all bound to the same service. The component on the other hand has been cycled due to a configuration update. So one service is backed by a deactivated component (whose field has been reset to null already) and the other service is live. The problem is that the service backed by the deactivated method has not been unregistered and thus all consumers are hooked up to the deactivated instance causing all sorts of problems ... This is what most probably happens in the AbstractComponentManager: * T1 Unsatisfied.activate has set the state to Active already before calling registerService * T1 registerService is called but the service registration field field is not assigned yet during registerService ServiceListeners are called * T2 A Configuration update comes in and Satisfied(Active).deactivate is called * T2 calls unregisterComponentService; does nothing because the service registration field is not assigned * T2 destroys component * T1 assigns field from service registration As a result the deactivated object's service registration may be unregistered later when the component is cycled again and the second service registration will only be unregistered when the providing bundle is restarted. -- 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-3320) WebConsole UX: actions and status on bundle details don't update properly
[
https://issues.apache.org/jira/browse/FELIX-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated FELIX-3320:
---
Attachment: FELIX-3320.patch
Proposed patch.
Replaced tr.find('td:eq(4)') with tr.children('td:eq(4)').
This handles the case where there are embedded tables and the selector can go
awry.
Be kind to my flaky javascript :)
WebConsole UX: actions and status on bundle details don't update properly
-
Key: FELIX-3320
URL: https://issues.apache.org/jira/browse/FELIX-3320
Project: Felix
Issue Type: Bug
Components: Web Console
Reporter: Alex Parvulescu
Priority: Minor
Attachments: FELIX-3320.patch
When looking at a bundle detail (both inline at /system/console/bundles and
at the dedicated page: /system/console/bundles/id) the actions related to the
bundle don't properly update the status and related actions.
For example:
- I install a bundle 27,
- I navigate to /system/console/bundles/27: Status 'Installed' and under
Actions I can start it (among other things)
- Start the bundle:
- it doesn't update the proper 'Status' column. Instead the Status
remains Installed and the 'Version' label td gets replaced with the new status
- the 'Start' action doesn't get replaced with the 'Stop' action (this
gets lost)
This happens in bundles.js namely because of using find() instead of
children() [0].
Explanation: The .find() and .children() methods are similar, except that
the latter only travels a single level down the DOM tree. (from the jquery
api). This affects bundle details page only, as it has an embedded table
containing the details that is shown only on this page, thus making the
find() calls select wrong components.
Will attach a patch shortly.
[0] http://api.jquery.com/children/
--
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
