[jira] [Resolved] (FELIX-3243) Autoconf does not recognize non-local non-factory OCDs
[
https://issues.apache.org/jira/browse/FELIX-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans resolved FELIX-3243.
-
Resolution: Fixed
Patch applied, thanks Bram.
Autoconf does not recognize non-local non-factory OCDs
--
Key: FELIX-3243
URL: https://issues.apache.org/jira/browse/FELIX-3243
Project: Felix
Issue Type: Bug
Components: Deployment Admin
Affects Versions: autoconf-rp-0.1.0
Reporter: Bram de Kruijff
Assignee: Marcel Offermans
Attachments: autoconf_isFactoryConfig.patch
Small bug means this this never worked:
{code}
private boolean isFactoryConfig(Designate designate) {
String factoryPid = designate.getFactoryPid();
return (factoryPid != null || !.equals(factoryPid));
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3243) Autoconf does not recognize non-local non-factory OCDs
[
https://issues.apache.org/jira/browse/FELIX-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans reassigned FELIX-3243:
---
Assignee: Marcel Offermans
Autoconf does not recognize non-local non-factory OCDs
--
Key: FELIX-3243
URL: https://issues.apache.org/jira/browse/FELIX-3243
Project: Felix
Issue Type: Bug
Components: Deployment Admin
Affects Versions: autoconf-rp-0.1.0
Reporter: Bram de Kruijff
Assignee: Marcel Offermans
Attachments: autoconf_isFactoryConfig.patch
Small bug means this this never worked:
{code}
private boolean isFactoryConfig(Designate designate) {
String factoryPid = designate.getFactoryPid();
return (factoryPid != null || !.equals(factoryPid));
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3328) Apply Filter and Filter all on the bundles page result in errors.
Apply Filter and Filter all on the bundles page result in errors. - Key: FELIX-3328 URL: https://issues.apache.org/jira/browse/FELIX-3328 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Felix Meschberger Fix For: webconsole-3.2.0 When clicking on the Apply Filter button a POST request is sent to the bundles page which cause a 405/METHOD NOT ALLOWED. I would assume that Apply Filter should really be a client side action to apply the filter entered in the search box. Likewise the Filter All button causes a dialog to open reporting an Invalid LDAP filter specified message, which is not helpfull. Entering a filter and hitting enter works perfectly as well as clicking the X icon to clear the filter string. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3329) Allow the autoconf resource processor to defer the setting of the configuration until ConfigurationAdmin is available
Allow the autoconf resource processor to defer the setting of the configuration until ConfigurationAdmin is available - Key: FELIX-3329 URL: https://issues.apache.org/jira/browse/FELIX-3329 Project: Felix Issue Type: Task Reporter: Marcel Offermans Right now, autoconf will always fail if you start out with an empty container and install a deployment package with all your bundles, including configuration data and ConfigurationAdmin, because at the time it tries to find the ConfigurationAdmin service, that won't be started yet. A solution would be to (in that case) defer setting the configuration until the service becomes available. The downside of this is that we never know for sure if this will work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3330) Allow autoconf to somehow resolve which configuration to send to which ConfigurationAdmin in case there is more than one
Allow autoconf to somehow resolve which configuration to send to which ConfigurationAdmin in case there is more than one Key: FELIX-3330 URL: https://issues.apache.org/jira/browse/FELIX-3330 Project: Felix Issue Type: Task Reporter: Marcel Offermans For now, autoconf assumes there is only one single ConfigurationAdmin service available, or if there are more it will pick the best one (according to the normal OSGi rules). However, there might be more than one ConfigurationAdmin service in the framework, and we might want to be able to send specific pieces of configuration to specific ConfigurationAdmin services. This is not defined in the spec, but it would be nice if we can extend our implementation to support this in a compatible way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3331) [gogo] Calling Activator.stop after Activator.start throws an exception
[gogo] Calling Activator.stop after Activator.start throws an exception --- Key: FELIX-3331 URL: https://issues.apache.org/jira/browse/FELIX-3331 Project: Felix Issue Type: Bug Reporter: Krzysztof Daniel https://bugzilla.redhat.com/show_bug.cgi?id=786041 gogo: InterruptedException: sleep interrupted java.lang.InterruptedException: sleep interrupted at java.lang.Thread.sleep(Native Method) at org.apache.felix.gogo.shell.Activator.run(Activator.java:72) at java.lang.Thread.run(Thread.java:722) Thread.sleep() could be try catched and handle interrupted exception as a proper workflow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3329) Allow the autoconf resource processor to defer the setting of the configuration until ConfigurationAdmin is available
[ https://issues.apache.org/jira/browse/FELIX-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans reassigned FELIX-3329: --- Assignee: Marcel Offermans Allow the autoconf resource processor to defer the setting of the configuration until ConfigurationAdmin is available - Key: FELIX-3329 URL: https://issues.apache.org/jira/browse/FELIX-3329 Project: Felix Issue Type: Task Reporter: Marcel Offermans Assignee: Marcel Offermans Right now, autoconf will always fail if you start out with an empty container and install a deployment package with all your bundles, including configuration data and ConfigurationAdmin, because at the time it tries to find the ConfigurationAdmin service, that won't be started yet. A solution would be to (in that case) defer setting the configuration until the service becomes available. The downside of this is that we never know for sure if this will work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3330) Allow autoconf to somehow resolve which configuration to send to which ConfigurationAdmin in case there is more than one
[ https://issues.apache.org/jira/browse/FELIX-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans reassigned FELIX-3330: --- Assignee: Marcel Offermans Allow autoconf to somehow resolve which configuration to send to which ConfigurationAdmin in case there is more than one Key: FELIX-3330 URL: https://issues.apache.org/jira/browse/FELIX-3330 Project: Felix Issue Type: Task Reporter: Marcel Offermans Assignee: Marcel Offermans For now, autoconf assumes there is only one single ConfigurationAdmin service available, or if there are more it will pick the best one (according to the normal OSGi rules). However, there might be more than one ConfigurationAdmin service in the framework, and we might want to be able to send specific pieces of configuration to specific ConfigurationAdmin services. This is not defined in the spec, but it would be nice if we can extend our implementation to support this in a compatible way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-2625) Provide a plugin for the Gogo Shell
[ https://issues.apache.org/jira/browse/FELIX-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-2625: Assignee: Felix Meschberger Provide a plugin for the Gogo Shell --- Key: FELIX-2625 URL: https://issues.apache.org/jira/browse/FELIX-2625 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Felix Meschberger Assignee: Felix Meschberger The Gogo Shell has replaced the simple Felix Shell as the command line tool for OSGi Management. We should provide support for this shell from within the Web Console, too. -- 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-2625) Provide a plugin for the Gogo Shell
[ https://issues.apache.org/jira/browse/FELIX-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196873#comment-13196873 ] Felix Meschberger commented on FELIX-2625: -- Committed a first shot a Felix provided Web Console plugin in Rev. 1238456/1238457. This is basically the Karaf WebConsole plugin mentioned by Guillaume above with some dependencies from Karaf Shell inlined and stripped down. Particularly the blueprint stuff and Felix Gogo internals are removed. Provide a plugin for the Gogo Shell --- Key: FELIX-2625 URL: https://issues.apache.org/jira/browse/FELIX-2625 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Felix Meschberger Assignee: Felix Meschberger The Gogo Shell has replaced the simple Felix Shell as the command line tool for OSGi Management. We should provide support for this shell from within the Web Console, too. -- 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-2625) Provide a plugin for the Gogo Shell
[ https://issues.apache.org/jira/browse/FELIX-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2625. -- Resolution: Fixed Fix Version/s: webconsole-gogo-plugin-1.0.0 Small improvements in Rev. 1238474 - Remove Declarative Services dependency (use plain old Activator) - Remove unneeded logging Resolving this for now. Cleanups and improvements tracked by new issues. Provide a plugin for the Gogo Shell --- Key: FELIX-2625 URL: https://issues.apache.org/jira/browse/FELIX-2625 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: webconsole-gogo-plugin-1.0.0 The Gogo Shell has replaced the simple Felix Shell as the command line tool for OSGi Management. We should provide support for this shell from within the Web Console, too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3332) SCR annotations @Activate @Deactivate @Modified in outer classes also affect nested classes, annotations in nested classes are ignored
SCR annotations @Activate @Deactivate @Modified in outer classes also affect
nested classes, annotations in nested classes are ignored
--
Key: FELIX-3332
URL: https://issues.apache.org/jira/browse/FELIX-3332
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.4, maven-scr-plugin-1.7.2
Reporter: Daniel Faber
Priority: Minor
When maven-scr-plugin processes components that are implemented as nested
classes, SCR annotations @Activate @Deactivate @Modified in these nested
classes are ignored. Annotations in the outer class are used instead:
import org.apache.felix.scr.annotations.Activate;
import org.apache.felix.scr.annotations.Component;
@Component
public class Outer {
@Activate
private void activateOuter() {
}
@Component
public static class Nested1 {
}
@Component
public static class Nested2 {
@Activate
private void activateNested2() {
}
}
}
results in this component description:
?xml version=1.0 encoding=UTF-8?
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0;
scr:component enabled=true name=Outer activate=activateOuter
implementation class=Outer/
property name=service.pid value=Outer/
/scr:component
scr:component enabled=true name=Outer$Nested1 activate=activateOuter
implementation class=Outer$Nested1/
property name=service.pid value=Outer$Nested1/
/scr:component
scr:component enabled=true name=Outer$Nested2 activate=activateOuter
implementation class=Outer$Nested2/
property name=service.pid value=Outer$Nested2/
/scr:component
/components
All components have an activate=activateOuter attribute. Similar problems
occur if the outer class is not a component or does not have an @Activate
annotation:
public class Outer {
@Component
public static class Nested {
@Activate
private void activateNested() {
}
}
}
Here the activate attribute is missing:
?xml version=1.0 encoding=UTF-8?
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=Outer$Nested
implementation class=Outer$Nested/
property name=service.pid value=Outer$Nested/
/scr:component
/components
--
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-3332) SCR annotations @Activate @Deactivate @Modified in outer classes also affect nested classes, annotations in nested classes are ignored
[
https://issues.apache.org/jira/browse/FELIX-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Faber updated FELIX-3332:
Description:
When maven-scr-plugin processes components that are implemented as nested
classes, SCR annotations @Activate @Deactivate @Modified in these nested
classes are ignored. Annotations in the outer class are used instead:
import org.apache.felix.scr.annotations.Activate;
import org.apache.felix.scr.annotations.Component;
@Component
public class Outer {
@Activate
private void activateOuter() {
}
@Component
public static class Nested1 {
}
@Component
public static class Nested2 {
@Activate
private void activateNested2() {
}
}
}
results in this component description:
?xml version=1.0 encoding=UTF-8?
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0;
scr:component enabled=true name=Outer activate=activateOuter
implementation class=Outer/
property name=service.pid value=Outer/
/scr:component
scr:component enabled=true name=Outer$Nested1 activate=activateOuter
implementation class=Outer$Nested1/
property name=service.pid value=Outer$Nested1/
/scr:component
scr:component enabled=true name=Outer$Nested2 activate=activateOuter
implementation class=Outer$Nested2/
property name=service.pid value=Outer$Nested2/
/scr:component
/components
All components have an activate=activateOuter attribute. Similar problems
occur if the outer class is not a component or does not have an @Activate
annotation:
public class Outer {
@Component
public static class Nested {
@Activate
private void activateNested() {
}
}
}
Here the activate attribute is missing:
?xml version=1.0 encoding=UTF-8?
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=Outer$Nested
implementation class=Outer$Nested/
property name=service.pid value=Outer$Nested/
/scr:component
/components
was:
When maven-scr-plugin processes components that are implemented as nested
classes, SCR annotations @Activate @Deactivate @Modified in these nested
classes are ignored. Annotations in the outer class are used instead:
import org.apache.felix.scr.annotations.Activate;
import org.apache.felix.scr.annotations.Component;
@Component
public class Outer {
@Activate
private void activateOuter() {
}
@Component
public static class Nested1 {
}
@Component
public static class Nested2 {
@Activate
private void activateNested2() {
}
}
}
results in this component description:
?xml version=1.0 encoding=UTF-8?
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0;
scr:component enabled=true name=Outer activate=activateOuter
implementation class=Outer/
property name=service.pid value=Outer/
/scr:component
scr:component enabled=true name=Outer$Nested1 activate=activateOuter
implementation class=Outer$Nested1/
property name=service.pid value=Outer$Nested1/
/scr:component
scr:component enabled=true name=Outer$Nested2 activate=activateOuter
implementation class=Outer$Nested2/
property name=service.pid value=Outer$Nested2/
/scr:component
/components
All components have an activate=activateOuter attribute. Similar problems
occur if the outer class is not a component or does not have an @Activate
annotation:
public class Outer {
@Component
public static class Nested {
@Activate
private void activateNested() {
}
}
}
Here the activate attribute is missing:
?xml version=1.0 encoding=UTF-8?
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=Outer$Nested
implementation class=Outer$Nested/
property name=service.pid value=Outer$Nested/
/scr:component
/components
SCR annotations @Activate @Deactivate @Modified in outer classes also affect
nested classes, annotations in nested classes are ignored
--
Key: FELIX-3332
URL: https://issues.apache.org/jira/browse/FELIX-3332
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.2, maven-scr-plugin-1.7.4
Reporter: Daniel Faber
Priority: Minor
When maven-scr-plugin processes components that are implemented as nested
classes, SCR annotations @Activate @Deactivate @Modified in these nested
classes are ignored. Annotations in the outer class are used instead:
[jira] [Updated] (FELIX-3331) [gogo] Calling Activator.stop after Activator.start throws an exception
[ https://issues.apache.org/jira/browse/FELIX-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krzysztof Daniel updated FELIX-3331: Attachment: ignoreActivatorException.patch A patch that ignores InterruptedException [gogo] Calling Activator.stop after Activator.start throws an exception --- Key: FELIX-3331 URL: https://issues.apache.org/jira/browse/FELIX-3331 Project: Felix Issue Type: Bug Reporter: Krzysztof Daniel Attachments: ignoreActivatorException.patch https://bugzilla.redhat.com/show_bug.cgi?id=786041 gogo: InterruptedException: sleep interrupted java.lang.InterruptedException: sleep interrupted at java.lang.Thread.sleep(Native Method) at org.apache.felix.gogo.shell.Activator.run(Activator.java:72) at java.lang.Thread.run(Thread.java:722) Thread.sleep() could be try catched and handle interrupted exception as a proper workflow. -- 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-3334) PreferencesManager can throw NPE after being stopped.
[ https://issues.apache.org/jira/browse/FELIX-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen updated FELIX-3334: Attachment: quickfix.patch A simple fix for this issue. PreferencesManager can throw NPE after being stopped. - Key: FELIX-3334 URL: https://issues.apache.org/jira/browse/FELIX-3334 Project: Felix Issue Type: Bug Components: Preferences Service Affects Versions: prefs-1.0.4 Reporter: J.W. Janssen Labels: patch Attachments: quickfix.patch PreferencesManager#bundleChanged tries to intercept bundles that are uninstalled. However, if the PreferencesManager itself is stopped, it does not unregister itself as bundle listener, causing possible NPEs when other bundles depending on the preferences service are stopped later on, for example during a shutdown. I've got a patch available, will attach it to this issue to be applied. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3334) PreferencesManager can throw NPE after being stopped.
PreferencesManager can throw NPE after being stopped. - Key: FELIX-3334 URL: https://issues.apache.org/jira/browse/FELIX-3334 Project: Felix Issue Type: Bug Components: Preferences Service Affects Versions: prefs-1.0.4 Reporter: J.W. Janssen Attachments: quickfix.patch PreferencesManager#bundleChanged tries to intercept bundles that are uninstalled. However, if the PreferencesManager itself is stopped, it does not unregister itself as bundle listener, causing possible NPEs when other bundles depending on the preferences service are stopped later on, for example during a shutdown. I've got a patch available, will attach it to this issue to be applied. -- 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] [Issue Comment Edited] (FELIX-3334) PreferencesManager can throw NPE after being stopped.
[ https://issues.apache.org/jira/browse/FELIX-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197004#comment-13197004 ] J.W. Janssen edited comment on FELIX-3334 at 1/31/12 4:26 PM: -- A simple fix for this issue is attached. was (Author: jajans): A simple fix for this issue. PreferencesManager can throw NPE after being stopped. - Key: FELIX-3334 URL: https://issues.apache.org/jira/browse/FELIX-3334 Project: Felix Issue Type: Bug Components: Preferences Service Affects Versions: prefs-1.0.4 Reporter: J.W. Janssen Labels: patch Attachments: quickfix.patch PreferencesManager#bundleChanged tries to intercept bundles that are uninstalled. However, if the PreferencesManager itself is stopped, it does not unregister itself as bundle listener, causing possible NPEs when other bundles depending on the preferences service are stopped later on, for example during a shutdown. I've got a patch available, will attach it to this issue to be applied. -- 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 Service Diagnostics Plugin version 0.1.1
+1 The NOTICE file is a little messed up in the plugin, it seems to repeat itself. The copyright year should be updated to 2012 in both NOTICE and DEPENDENCIES. - richard p.s. That's a really big bundle...8.5MB... :-) On 1/20/12 03:59 , Arjun Panday wrote: Hi everyone, Second attempt at releasing the Service Diagnostics WebConsole Plugin. I've simply refactored the POMs by moving the parent role out of the reactor POM. The directory structure seems cleaner. Let me know. Here's the staging repository: https://repository.apache.org/content/repositories/orgapachefelix-110/ 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 010 /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. Thanks, -arjun
Re: [VOTE] Release Service Diagnostics Plugin version 0.1.1
On 31 Jan 2012, at 22:06, Richard S. Hall wrote: +1 The NOTICE file is a little messed up in the plugin, it seems to repeat itself. The copyright year should be updated to 2012 in both NOTICE and DEPENDENCIES. - richard p.s. That's a really big bundle...8.5MB... :-) To be fair ~8mb of that is the Scala runtime... maybe that should be separated into its own bundle in case others want to re-use it? On 1/20/12 03:59 , Arjun Panday wrote: Hi everyone, Second attempt at releasing the Service Diagnostics WebConsole Plugin. I've simply refactored the POMs by moving the parent role out of the reactor POM. The directory structure seems cleaner. Let me know. Here's the staging repository: https://repository.apache.org/content/repositories/orgapachefelix-110/ 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 010 /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. Thanks, -arjun
[jira] [Commented] (FELIX-3334) PreferencesManager can throw NPE after being stopped.
[ https://issues.apache.org/jira/browse/FELIX-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197641#comment-13197641 ] Felix Meschberger commented on FELIX-3334: -- A bundle being stopped is automatically unregistered as a bundle listener but only after having called the stop method of the BundleActivator. Looking at the code, chances are minimal (if there is a concurrency between event handling and handling stop), but this would not be 100% solved by the patch (because an event might still be coming in. A better fix would be to check for the null-situation in the event handler when accessing the store. Did you actually encounter an NPE ? PreferencesManager can throw NPE after being stopped. - Key: FELIX-3334 URL: https://issues.apache.org/jira/browse/FELIX-3334 Project: Felix Issue Type: Bug Components: Preferences Service Affects Versions: prefs-1.0.4 Reporter: J.W. Janssen Labels: patch Attachments: quickfix.patch PreferencesManager#bundleChanged tries to intercept bundles that are uninstalled. However, if the PreferencesManager itself is stopped, it does not unregister itself as bundle listener, causing possible NPEs when other bundles depending on the preferences service are stopped later on, for example during a shutdown. I've got a patch available, will attach it to this issue to be applied. -- 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
