[jira] [Created] (FELIX-3390) Intermittent NPE in ConfigurationManager
Intermittent NPE in ConfigurationManager
Key: FELIX-3390
URL: https://issues.apache.org/jira/browse/FELIX-3390
Project: Felix
Issue Type: Bug
Components: Configuration Admin
Affects Versions: configadmin-1.2.8
Reporter: Marcel Offermans
We are using Configuration Admin in our open source project, where we get the
following exception in our integration tests:
{code}
*ERROR* Unexpected problem executing task
java.lang.NullPointerException: reference and pid must not be null
at
org.osgi.service.cm.ConfigurationEvent.init(ConfigurationEvent.java:120)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1818)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
at java.lang.Thread.run(Thread.java:662)
{code}
I'm not quite sure what is going on, and the NPE does not occur every time, but
it does seem to keep happening often enough to warrant a bug report as the code
that is being executed is not directly invoked by the test. For more
background, look at (for example) this log:
http://bamboo.amdatu.org/bamboo/browse/AMDATUPLATFORM-AMDATUGIT-JOB1-74/log
At least some null checks would be in order, plus maybe a better log message
that tells us which of the two actually was null (I know this is an OSGi class
that's doing the reporting, but we could check ourselves before invoking its
constructor).
--
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-3357) Improve
Improve Key: FELIX-3357 URL: https://issues.apache.org/jira/browse/FELIX-3357 Project: Felix Issue Type: Improvement Components: Deployment Admin Affects Versions: autoconf-rp-0.1.0 Reporter: Marcel Offermans The ambiguous use of resource throughout the code is rather confusing. First there is the deployment resources which are effectively representations of metadata files. Second there are the autoconf resources which are effectively representations of designates. So, for example the DropResource and DeleteResource tasks are entirely different beasts. I think some renaming could help future adventurers. -- 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-3338) Add support for optional attributes in the MetaDataReader as defined in the XML schema for metatype
Add support for optional attributes in the MetaDataReader as defined in the XML schema for metatype --- Key: FELIX-3338 URL: https://issues.apache.org/jira/browse/FELIX-3338 Project: Felix Issue Type: Improvement Components: Metatype Service Affects Versions: metatype-1.0.4 Reporter: Marcel Offermans If you look at the metatype spec, 105.8 shows the XML schema for metatype. We have a parser for it called MetaDataReader, and it basically converts the XML file into a tree of Java objects (MetaData and related). The schema, in several locations, allows you to use optional attributes (scan the schema for anyAttribute /). Our parser currently does not have a way to read such attributes though, but it should! :) -- 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-3336) Exceptions related to the pipe used in deployment admin
Exceptions related to the pipe used in deployment admin --- Key: FELIX-3336 URL: https://issues.apache.org/jira/browse/FELIX-3336 Project: Felix Issue Type: Bug Components: Deployment Admin Reporter: Marcel Offermans Sporadically getting Pipe closed exceptions. Not reproducible yet, but seemingly related to a line containing input.close() in the ExplodingOutputtingInputStream. Needs investigation. -- 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-3264) Dependency manager shell should not print the state of optional dependencies when not all required ones are available
Dependency manager shell should not print the state of optional dependencies when not all required ones are available - Key: FELIX-3264 URL: https://issues.apache.org/jira/browse/FELIX-3264 Project: Felix Issue Type: Improvement Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Reporter: Marcel Offermans Internally, the dependency manager only starts listening to optional dependencies once all required ones are available. That means that optional dependencies will always be listed as unavailable in that scenario. That looks somewhat funny though: a required dependency to A that is available might also be shown as an optional one to A in a different component, and it might seem unavailable there. The fix is to not print the state of (optional) dependencies if they have not been started yet. -- 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-3139) Implement uninstall() for deployment admin.
Implement uninstall() for deployment admin. --- Key: FELIX-3139 URL: https://issues.apache.org/jira/browse/FELIX-3139 Project: Felix Issue Type: Improvement Components: Deployment Admin Reporter: Marcel Offermans Currently, uninstall() is not implemented, even though it's part of the API. The root cause of that is historical, as DA was originally developed for Apache ACE and ACE never uninstalls deployment packages (but instead installs an empty update if you remove all artifacts from a deployment package). -- 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
