[jira] [Resolved] (FELIX-3360) Bundle location is statically set for dynamically bound bundles
[ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3360. -- Resolution: Fixed I have applied my patch along with an integration test intended to validate dynamic binding semantics in Rev. 1513740: - getConfiguration(pid) binds dynamically - createConfiguration(pid) binds dynamically - add integration tests to validate removal of dynamic bindings - make sure dynamic binding is cleared if static binding is set Bundle location is statically set for dynamically bound bundles --- Key: FELIX-3360 URL: https://issues.apache.org/jira/browse/FELIX-3360 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.2.8 Reporter: Julian Sedding Assignee: Felix Meschberger Fix For: configadmin-1.6.2 Attachments: FELIX-3360.patch, FELIX-3360.patch The method ConfigurationAdminImpl#getConfiguration(pid) dynamically sets the configuration's bundle location if it is null. However, it uses ConfigurationImpl#setStaticBundleLocation(location) in order to do so. This should be changed to set the dynamic location. Attached is a proposed patch. The issue I observed, that lead me to this bug, was as follows: 1. Installed a number of factory configurations and the bundle (version 1.0.0, bundle location: jcrinstall:/apps/sample/install/bundle-1.0.0.jar) providing the service implementation (using SCR) via Sling's OSGi Installer 2. Uninstalled the bundle. 3. Installed the bundle (version 1.0.2, bundle location: jcrinstall:/apps/sample/install/bundle-1.0.2.jar) After this, the factory configurations were not bound to the bundle any longer, because they were still bound to the no longer existing bundle location jcrinstall:/apps/sample/install/bundle-1.0.0.jar. This basically leaves stale configurations and a badly configured system. While Sling's OSGi Installer handles updates without changing the bundle location normally, the above scenario differs in that instead of an update, there is an uninstall + re-install happening. The Configuration Admin Service Specification 1.3 clearly states (in 104.4.1 Location Binding): When this dynamically bound bundle is subsequently uninstalled, the Configuration object's bundle location must be set to null again so it can be bound again later. Note: in the patch I also changed the return type of ConfigurationImpl#tryBindLocation() from boolean to void. Before, it always returned true, so the return value is meaningless. I almost ended up using it in an if statement because of the return type, which made me believe that it returns true if the bundle location is set and false otherwise. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-4165) FilePersistenceManager fails to rename configuration file
[ https://issues.apache.org/jira/browse/FELIX-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-4165: Assignee: Felix Meschberger FilePersistenceManager fails to rename configuration file - Key: FELIX-4165 URL: https://issues.apache.org/jira/browse/FELIX-4165 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Martin Lichtin Assignee: Felix Meschberger Quite frequently a file move fails. The symptom is: java.io.IOException: Failed to rename configuration file from 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config2019338524809240991.tmp' to 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config at org.apache.felix.cm.file.FilePersistenceManager._store(FilePersistenceManager.java:640)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.file.FilePersistenceManager.store(FilePersistenceManager.java:582)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.DynamicBindings.putLocation(DynamicBindings.java:116)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager.setDynamicBundleLocation(ConfigurationManager.java:461)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.setDynamicBundleLocation(ConfigurationImpl.java:281)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.tryBindLocation(ConfigurationImpl.java:304)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1705)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[5:org.apache.felix.configadmin:1.6.0] at java.lang.Thread.run(Thread.java:724)[:1.7.0_25] Perhaps the file exists and cannot be deleted (could report return value of the delete() on line 634). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4165) FilePersistenceManager fails to rename configuration file
[ https://issues.apache.org/jira/browse/FELIX-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4165: - Fix Version/s: configadmin-1.6.2 FilePersistenceManager fails to rename configuration file - Key: FELIX-4165 URL: https://issues.apache.org/jira/browse/FELIX-4165 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Martin Lichtin Assignee: Felix Meschberger Fix For: configadmin-1.6.2 Quite frequently a file move fails. The symptom is: java.io.IOException: Failed to rename configuration file from 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config2019338524809240991.tmp' to 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config at org.apache.felix.cm.file.FilePersistenceManager._store(FilePersistenceManager.java:640)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.file.FilePersistenceManager.store(FilePersistenceManager.java:582)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.DynamicBindings.putLocation(DynamicBindings.java:116)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager.setDynamicBundleLocation(ConfigurationManager.java:461)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.setDynamicBundleLocation(ConfigurationImpl.java:281)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.tryBindLocation(ConfigurationImpl.java:304)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1705)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[5:org.apache.felix.configadmin:1.6.0] at java.lang.Thread.run(Thread.java:724)[:1.7.0_25] Perhaps the file exists and cannot be deleted (could report return value of the delete() on line 634). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4165) FilePersistenceManager fails to rename configuration file
[ https://issues.apache.org/jira/browse/FELIX-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739373#comment-13739373 ] Felix Meschberger commented on FELIX-4165: -- Thanks for reporting the issue. I have added a check for the result of the delete operation in Rev. 1513753. Unfortunately Java just reports success or failure. So, the only thing that can be done at that level is to throw an IOException and fail the store operation. The reason for failure to delete a file (or rename a file by that matter) on windows is generally related to the file still being open. Both should not be the case to the best of my knowledge here. As for your follow-up comment: The code extract is unrelated to the original report. But you mention, that an IOException should be thrown here instead of catching and logging it. I disagree in this context because the factory.store() operation is an internal maintenance task not related to the actual creation of a factory configuration. As such me thinks this exception should not exposed to the consumer because the consumer can do even less. In addition, regardless of the success or failure in this particular situation, the task of the consumer (creating a factory configuration) has been done. FilePersistenceManager fails to rename configuration file - Key: FELIX-4165 URL: https://issues.apache.org/jira/browse/FELIX-4165 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Martin Lichtin Assignee: Felix Meschberger Fix For: configadmin-1.6.2 Quite frequently a file move fails. The symptom is: java.io.IOException: Failed to rename configuration file from 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config2019338524809240991.tmp' to 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config at org.apache.felix.cm.file.FilePersistenceManager._store(FilePersistenceManager.java:640)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.file.FilePersistenceManager.store(FilePersistenceManager.java:582)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.DynamicBindings.putLocation(DynamicBindings.java:116)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager.setDynamicBundleLocation(ConfigurationManager.java:461)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.setDynamicBundleLocation(ConfigurationImpl.java:281)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.tryBindLocation(ConfigurationImpl.java:304)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1705)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[5:org.apache.felix.configadmin:1.6.0] at java.lang.Thread.run(Thread.java:724)[:1.7.0_25] Perhaps the file exists and cannot be deleted (could report return value of the delete() on line 634). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739376#comment-13739376 ] Felix Meschberger commented on FELIX-4088: -- I think this is not related to Config Admin 1.2.8. Do you mind if I move the reference from the affects field to the environment field ? NPE from SCR service unregistration --- Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Configuration Admin, Declarative Services (SCR), Framework Affects Versions: framework-4.2.0, configadmin-1.2.8, scr-1.6.0 Environment: MacOSX 8 processors Reporter: Timothy Ward When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at
[jira] [Assigned] (FELIX-4039) Add Permissions file in ConfigAdmin bundle
[ https://issues.apache.org/jira/browse/FELIX-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-4039: Assignee: Felix Meschberger Add Permissions file in ConfigAdmin bundle --- Key: FELIX-4039 URL: https://issues.apache.org/jira/browse/FELIX-4039 Project: Felix Issue Type: Improvement Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Romain Dubois Assignee: Felix Meschberger Priority: Minor Labels: security Fix For: configadmin-1.6.2 Most of felix bundles should have a permissions file. For ConfigAdmin bundle, I suggest the following content for OSGI-INF/permissions.perm file: # Apache Felix Configuration Admin Service # Bundle permissions # # Imported/Exported packages # - MANIFEST.MF (org.osgi.framework.PackagePermission org.osgi.service.log import) (org.osgi.framework.PackagePermission org.osgi.framework import) (org.osgi.framework.PackagePermission org.osgi.service.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm.file import,exportonly) # General bundle permissions (java.util.PropertyPermission felix.cm.* read) (org.osgi.framework.ServicePermission org.apache.felix.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.log.LogService get) # Manage configurations # - ConfigurationAdminImpl (org.osgi.framework.AdminPermission * metadata) (org.osgi.service.cm.ConfigurationPermission* configure,target) # Handle persistent configuration files # - FilePersistenceManager (java.util.PropertyPermission user.dir read) (java.io.FilePermission - read,write,execute,delete) # - ConfigurationManager (org.osgi.framework.ServicePermission org.apache.felix.cm.PersistenceManagerregister) Note: I have extracted those permissions from code analysis then tested the suggested file in simple examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4039) Add Permissions file in ConfigAdmin bundle
[ https://issues.apache.org/jira/browse/FELIX-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4039: - Fix Version/s: configadmin-1.6.2 Add Permissions file in ConfigAdmin bundle --- Key: FELIX-4039 URL: https://issues.apache.org/jira/browse/FELIX-4039 Project: Felix Issue Type: Improvement Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Romain Dubois Priority: Minor Labels: security Fix For: configadmin-1.6.2 Most of felix bundles should have a permissions file. For ConfigAdmin bundle, I suggest the following content for OSGI-INF/permissions.perm file: # Apache Felix Configuration Admin Service # Bundle permissions # # Imported/Exported packages # - MANIFEST.MF (org.osgi.framework.PackagePermission org.osgi.service.log import) (org.osgi.framework.PackagePermission org.osgi.framework import) (org.osgi.framework.PackagePermission org.osgi.service.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm.file import,exportonly) # General bundle permissions (java.util.PropertyPermission felix.cm.* read) (org.osgi.framework.ServicePermission org.apache.felix.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.log.LogService get) # Manage configurations # - ConfigurationAdminImpl (org.osgi.framework.AdminPermission * metadata) (org.osgi.service.cm.ConfigurationPermission* configure,target) # Handle persistent configuration files # - FilePersistenceManager (java.util.PropertyPermission user.dir read) (java.io.FilePermission - read,write,execute,delete) # - ConfigurationManager (org.osgi.framework.ServicePermission org.apache.felix.cm.PersistenceManagerregister) Note: I have extracted those permissions from code analysis then tested the suggested file in simple examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4039) Add Permissions file in ConfigAdmin bundle
[ https://issues.apache.org/jira/browse/FELIX-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739377#comment-13739377 ] Felix Meschberger commented on FELIX-4039: -- Thanks for reporting and providing the file. The contents sounds reasonable to me. Add Permissions file in ConfigAdmin bundle --- Key: FELIX-4039 URL: https://issues.apache.org/jira/browse/FELIX-4039 Project: Felix Issue Type: Improvement Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Romain Dubois Assignee: Felix Meschberger Priority: Minor Labels: security Fix For: configadmin-1.6.2 Most of felix bundles should have a permissions file. For ConfigAdmin bundle, I suggest the following content for OSGI-INF/permissions.perm file: # Apache Felix Configuration Admin Service # Bundle permissions # # Imported/Exported packages # - MANIFEST.MF (org.osgi.framework.PackagePermission org.osgi.service.log import) (org.osgi.framework.PackagePermission org.osgi.framework import) (org.osgi.framework.PackagePermission org.osgi.service.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm.file import,exportonly) # General bundle permissions (java.util.PropertyPermission felix.cm.* read) (org.osgi.framework.ServicePermission org.apache.felix.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.log.LogService get) # Manage configurations # - ConfigurationAdminImpl (org.osgi.framework.AdminPermission * metadata) (org.osgi.service.cm.ConfigurationPermission* configure,target) # Handle persistent configuration files # - FilePersistenceManager (java.util.PropertyPermission user.dir read) (java.io.FilePermission - read,write,execute,delete) # - ConfigurationManager (org.osgi.framework.ServicePermission org.apache.felix.cm.PersistenceManagerregister) Note: I have extracted those permissions from code analysis then tested the suggested file in simple examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4165) FilePersistenceManager fails to rename configuration file
[ https://issues.apache.org/jira/browse/FELIX-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739384#comment-13739384 ] Martin Lichtin commented on FELIX-4165: --- Thanks for having a look and the check. As mentioned elsewhere, it is likely related to Windows and a virus scanner (Kaspersky in my case). I excluded the Karaf run directories from getting scanned by KAV and don't see the issue since then (fingers crossed). FilePersistenceManager fails to rename configuration file - Key: FELIX-4165 URL: https://issues.apache.org/jira/browse/FELIX-4165 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Martin Lichtin Assignee: Felix Meschberger Fix For: configadmin-1.6.2 Quite frequently a file move fails. The symptom is: java.io.IOException: Failed to rename configuration file from 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config2019338524809240991.tmp' to 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config at org.apache.felix.cm.file.FilePersistenceManager._store(FilePersistenceManager.java:640)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.file.FilePersistenceManager.store(FilePersistenceManager.java:582)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.DynamicBindings.putLocation(DynamicBindings.java:116)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager.setDynamicBundleLocation(ConfigurationManager.java:461)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.setDynamicBundleLocation(ConfigurationImpl.java:281)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.tryBindLocation(ConfigurationImpl.java:304)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1705)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[5:org.apache.felix.configadmin:1.6.0] at java.lang.Thread.run(Thread.java:724)[:1.7.0_25] Perhaps the file exists and cannot be deleted (could report return value of the delete() on line 634). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4039) Add Permissions file in ConfigAdmin bundle
[ https://issues.apache.org/jira/browse/FELIX-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739386#comment-13739386 ] Felix Meschberger commented on FELIX-4039: -- Added the file to the source tree in Rev. 1513754. Add Permissions file in ConfigAdmin bundle --- Key: FELIX-4039 URL: https://issues.apache.org/jira/browse/FELIX-4039 Project: Felix Issue Type: Improvement Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Romain Dubois Assignee: Felix Meschberger Priority: Minor Labels: security Fix For: configadmin-1.6.2 Most of felix bundles should have a permissions file. For ConfigAdmin bundle, I suggest the following content for OSGI-INF/permissions.perm file: # Apache Felix Configuration Admin Service # Bundle permissions # # Imported/Exported packages # - MANIFEST.MF (org.osgi.framework.PackagePermission org.osgi.service.log import) (org.osgi.framework.PackagePermission org.osgi.framework import) (org.osgi.framework.PackagePermission org.osgi.service.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm.file import,exportonly) # General bundle permissions (java.util.PropertyPermission felix.cm.* read) (org.osgi.framework.ServicePermission org.apache.felix.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.log.LogService get) # Manage configurations # - ConfigurationAdminImpl (org.osgi.framework.AdminPermission * metadata) (org.osgi.service.cm.ConfigurationPermission* configure,target) # Handle persistent configuration files # - FilePersistenceManager (java.util.PropertyPermission user.dir read) (java.io.FilePermission - read,write,execute,delete) # - ConfigurationManager (org.osgi.framework.ServicePermission org.apache.felix.cm.PersistenceManagerregister) Note: I have extracted those permissions from code analysis then tested the suggested file in simple examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4039) Add Permissions file in ConfigAdmin bundle
[ https://issues.apache.org/jira/browse/FELIX-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4039. -- Resolution: Fixed The file looks reasonable and our own as well as the OSGi CT tests all pass, so I assume this properly works and I resolve this issue. Add Permissions file in ConfigAdmin bundle --- Key: FELIX-4039 URL: https://issues.apache.org/jira/browse/FELIX-4039 Project: Felix Issue Type: Improvement Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Romain Dubois Assignee: Felix Meschberger Priority: Minor Labels: security Fix For: configadmin-1.6.2 Most of felix bundles should have a permissions file. For ConfigAdmin bundle, I suggest the following content for OSGI-INF/permissions.perm file: # Apache Felix Configuration Admin Service # Bundle permissions # # Imported/Exported packages # - MANIFEST.MF (org.osgi.framework.PackagePermission org.osgi.service.log import) (org.osgi.framework.PackagePermission org.osgi.framework import) (org.osgi.framework.PackagePermission org.osgi.service.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm import,exportonly) (org.osgi.framework.PackagePermission org.apache.felix.cm.file import,exportonly) # General bundle permissions (java.util.PropertyPermission felix.cm.* read) (org.osgi.framework.ServicePermission org.apache.felix.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.cm.* get,register) (org.osgi.framework.ServicePermission org.osgi.service.log.LogService get) # Manage configurations # - ConfigurationAdminImpl (org.osgi.framework.AdminPermission * metadata) (org.osgi.service.cm.ConfigurationPermission* configure,target) # Handle persistent configuration files # - FilePersistenceManager (java.util.PropertyPermission user.dir read) (java.io.FilePermission - read,write,execute,delete) # - ConfigurationManager (org.osgi.framework.ServicePermission org.apache.felix.cm.PersistenceManagerregister) Note: I have extracted those permissions from code analysis then tested the suggested file in simple examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4165) FilePersistenceManager fails to rename configuration file
[ https://issues.apache.org/jira/browse/FELIX-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4165. -- Resolution: Fixed Thanks to the quick feedback. So I resolve this issue for now. You may want to create a new one (relating to this) if the issue occurs again. FilePersistenceManager fails to rename configuration file - Key: FELIX-4165 URL: https://issues.apache.org/jira/browse/FELIX-4165 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.6.0 Reporter: Martin Lichtin Assignee: Felix Meschberger Fix For: configadmin-1.6.2 Quite frequently a file move fails. The symptom is: java.io.IOException: Failed to rename configuration file from 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config2019338524809240991.tmp' to 'C:\Users\mli\nuc\env\master\karaf\karaf\karaf-deploy-std\target\karaf\data\cache\bundle5\data\config\org_apache_felix_cm_impl_DynamicBindings.config at org.apache.felix.cm.file.FilePersistenceManager._store(FilePersistenceManager.java:640)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.file.FilePersistenceManager.store(FilePersistenceManager.java:582)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.DynamicBindings.putLocation(DynamicBindings.java:116)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager.setDynamicBundleLocation(ConfigurationManager.java:461)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.setDynamicBundleLocation(ConfigurationImpl.java:281)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationImpl.tryBindLocation(ConfigurationImpl.java:304)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1705)[5:org.apache.felix.configadmin:1.6.0] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[5:org.apache.felix.configadmin:1.6.0] at java.lang.Thread.run(Thread.java:724)[:1.7.0_25] Perhaps the file exists and cannot be deleted (could report return value of the delete() on line 634). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3360) Bundle location is statically set for dynamically bound bundles
[ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739441#comment-13739441 ] Julian Sedding commented on FELIX-3360: --- Thanks for the fix, Felix. Thinking of implicitly binding a configuration rather than dynamically binding it makes sense to me and makes it easier to understand the spec/contract. Bundle location is statically set for dynamically bound bundles --- Key: FELIX-3360 URL: https://issues.apache.org/jira/browse/FELIX-3360 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.2.8 Reporter: Julian Sedding Assignee: Felix Meschberger Fix For: configadmin-1.8.0 Attachments: FELIX-3360.patch, FELIX-3360.patch The method ConfigurationAdminImpl#getConfiguration(pid) dynamically sets the configuration's bundle location if it is null. However, it uses ConfigurationImpl#setStaticBundleLocation(location) in order to do so. This should be changed to set the dynamic location. Attached is a proposed patch. The issue I observed, that lead me to this bug, was as follows: 1. Installed a number of factory configurations and the bundle (version 1.0.0, bundle location: jcrinstall:/apps/sample/install/bundle-1.0.0.jar) providing the service implementation (using SCR) via Sling's OSGi Installer 2. Uninstalled the bundle. 3. Installed the bundle (version 1.0.2, bundle location: jcrinstall:/apps/sample/install/bundle-1.0.2.jar) After this, the factory configurations were not bound to the bundle any longer, because they were still bound to the no longer existing bundle location jcrinstall:/apps/sample/install/bundle-1.0.0.jar. This basically leaves stale configurations and a badly configured system. While Sling's OSGi Installer handles updates without changing the bundle location normally, the above scenario differs in that instead of an update, there is an uninstall + re-install happening. The Configuration Admin Service Specification 1.3 clearly states (in 104.4.1 Location Binding): When this dynamically bound bundle is subsequently uninstalled, the Configuration object's bundle location must be set to null again so it can be bound again later. Note: in the patch I also changed the return type of ConfigurationImpl#tryBindLocation() from boolean to void. Before, it always returned true, so the return value is meaningless. I almost ended up using it in an if statement because of the return type, which made me believe that it returns true if the bundle location is set and false otherwise. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739450#comment-13739450 ] Timothy Ward commented on FELIX-4088: - That's fine with me. NPE from SCR service unregistration --- Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Configuration Admin, Declarative Services (SCR), Framework Affects Versions: framework-4.2.0, configadmin-1.2.8, scr-1.6.0 Environment: MacOSX 8 processors Reporter: Timothy Ward When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
[jira] [Updated] (FELIX-4088) NPE from SCR service unregistration
[ https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4088: - Component/s: (was: Configuration Admin) Environment: MacOSX 8 processors; Felix Configuration Admin 1.2.8 (was: MacOSX 8 processors) Affects Version/s: (was: configadmin-1.2.8) Thanks [~timothyjward]. Done. NPE from SCR service unregistration --- Key: FELIX-4088 URL: https://issues.apache.org/jira/browse/FELIX-4088 Project: Felix Issue Type: Bug Components: Declarative Services (SCR), Framework Affects Versions: framework-4.2.0, scr-1.6.0 Environment: MacOSX 8 processors; Felix Configuration Admin 1.2.8 Reporter: Timothy Ward When uninstalling a set of bundles I get the following exception. ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152) at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247) at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832) at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104) at java.lang.Thread.run(Thread.java:722) ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: Error during dispatch. (java.lang.NullPointerException) java.lang.NullPointerException at org.apache.felix.framework.util.Util.getWire(Util.java:335) at org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493) at org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401) at org.apache.felix.framework.Felix.access$000(Felix.java:74) at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) at com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37) at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074) at
[jira] [Resolved] (FELIX-3304) request forwarding doesn't work
[ https://issues.apache.org/jira/browse/FELIX-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-3304. - Resolution: Duplicate Closing this one as duplicate of FELIX-2774. Please follow that issue for future updates... request forwarding doesn't work --- Key: FELIX-3304 URL: https://issues.apache.org/jira/browse/FELIX-3304 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Martin Zdila Priority: Critical In the servlet with alias /original/path the call request.getRequestDispatcher(/new/path).forward(request, response) is called. In ServletPipeline on line 85 the request is wrapped to RequestWrapper that overrides getRequestURI and returns URI of the request dispatcher. No other method is overriden and so every other call is forwarded to the original Request. Later a ServletHandler with alias /new/path is called and it tests if this alias matches against the wrapped request getPathInfo(). As mentioned in previous paragraph, this method has not been overriden and so the /original/path is returned causing matches() to return false. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3048) HttpContext getResource(name) called without preceeding slash
[ https://issues.apache.org/jira/browse/FELIX-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-3048. - Resolution: Duplicate Closing this issue in favour of FELIX-2386. HttpContext getResource(name) called without preceeding slash - Key: FELIX-3048 URL: https://issues.apache.org/jira/browse/FELIX-3048 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Bram de Kruijff ServletContextImpl#normalizePath explicitly strips the preceeding slash from a resource request before calling HttpContext#getResource. This behavior is different from the Pax Web implementation. Not sure that the HttpContext specification is conclusive, but at least this is inconsistent with ServletContext#getResource that states: Returns a URL to the resource that is mapped to a specified path. The path must begin with a / and is interpreted as relative to the current context root. Originally reported under As reported under https://issues.apache.org/jira/browse/ACE-156 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4087) Jetty HTTP Service: Support random port (0) and publish the one really used
[ https://issues.apache.org/jira/browse/FELIX-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-4087. - Resolution: Duplicate I'll try to merge the best parts of both patches. Thanks for the proposed fix, please follow FELIX-2786 for future progress... Jetty HTTP Service: Support random port (0) and publish the one really used --- Key: FELIX-4087 URL: https://issues.apache.org/jira/browse/FELIX-4087 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Thomas Calmant Attachments: http_service.patch When a port number is set to 0, let Jetty use a random port and show it in the service properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-1140) Starting HTTP service on Asus WL500G-P with OpenWrt (Kernel 2.4)
[ https://issues.apache.org/jira/browse/FELIX-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-1140. - Resolution: Won't Fix Issue is more than 4 years old, using old versions of Felix Framework HTTP service. If this issue still persists with the current versions, please reopen this issue. Starting HTTP service on Asus WL500G-P with OpenWrt (Kernel 2.4) Key: FELIX-1140 URL: https://issues.apache.org/jira/browse/FELIX-1140 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: framework-1.6.1 Environment: Router Asus WL500G-Premium with Kamikaze 8.09 (Kernel 2.4) Using JamVM 1.5.3 with GNU Classpath 0.98 to run the Felix Framework Reporter: Flávio Sá I have the following bundles installed: System Bundle (1.6.1) Apache Felix Shell Service (1.2.0) Apache Felix Shell TUI (1.2.0) Apache Felix Bundle Repository (1.4.0) Apache Felix Configuration Admin Service (1.0.10) Apache Felix Dependency Manager (2.0.1) Apache Felix Log Service (1.0.0) Apache Felix Prefrences Service (1.0.2) OSGi R4 Compendium Bundle (4.1.0) HTTP Service (1.0.0) When starting HTTP Service i get this: Ex1: Service of type org.osgi.service.cm.ManagedService registered. Exception in thread Jetty HTTP Service Launcher java.lang.ExceptionInInitializerError at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.apache.felix.http.jetty.Activator.initializeJetty(Activator.java:391) at org.apache.felix.http.jetty.Activator.startJetty(Activator.java:205) at org.apache.felix.http.jetty.Activator.run(Activator.java:248) at java.lang.Thread.run(Thread.java:745) Caused by: java.nio.channels.UnresolvedAddressException at gnu.java.nio.SocketChannelImpl.connect(SocketChannelImpl.java:160) at gnu.java.net.PlainSocketImpl.connect(PlainSocketImpl.java:281) at java.net.Socket.connect(Socket.java:454) at java.net.Socket.connect(Socket.java:414) at gnu.java.net.protocol.http.HTTPConnection.getSocket(HTTPConnection.java:721) at gnu.java.net.protocol.http.HTTPConnection.getOutputStream(HTTPConnection.java:802) at gnu.java.net.protocol.http.Request.dispatch(Request.java:292) at gnu.java.net.protocol.http.HTTPURLConnection.connect(HTTPURLConnection.java:219) at gnu.java.net.protocol.http.HTTPURLConnection.getHeaderField(HTTPURLConnection.java:582) at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:426) at java.net.URLConnection.getContentLength(URLConnection.java:302) at gnu.java.net.loader.RemoteURLLoader.getResource(RemoteURLLoader.java:79) at java.net.URLClassLoader.findURLResource(URLClassLoader.java:682) at java.net.URLClassLoader.findResource(URLClassLoader.java:697) at java.lang.ClassLoader.getResource(ClassLoader.java:608) at org.apache.felix.framework.searchpolicy.ModuleImpl.searchDynamicImports(ModuleImpl.java:1238) at org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:515) at org.apache.felix.framework.searchpolicy.ModuleImpl.getResourceByDelegation(ModuleImpl.java:434) at org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.getResource(ModuleImpl.java:1590) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:730) at java.util.ResourceBundle.tryBundle(ResourceBundle.java:499) at java.util.ResourceBundle.tryBundle(ResourceBundle.java:568) at java.util.ResourceBundle.getBundle(ResourceBundle.java:418) at java.util.ResourceBundle.getBundle(ResourceBundle.java:234) at org.mortbay.jetty.MimeTypes.clinit(MimeTypes.java:106) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509) ...5 more Im not sure if this a bug, or simply im missing some bundle, but i think all the necessary bundles are installed, otherwise the HTTP bundle wouldn't register org.osgi.service.cm.ManagedService. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2714) Registered servlet throws java.net.ConnectException or returns 404 after updating the portnr using Config Admin
[ https://issues.apache.org/jira/browse/FELIX-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-2714. - Resolution: Cannot Reproduce Please reopen if this is still an issue with the latest snapshot of felix-http. Registered servlet throws java.net.ConnectException or returns 404 after updating the portnr using Config Admin --- Key: FELIX-2714 URL: https://issues.apache.org/jira/browse/FELIX-2714 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Ivo Ladage-van Doorn Attachments: portswitchtest.zip When the org.osgi.service.http.port property is updated using Config Admin, without effectively changing it (so setting it to 8080 while the default is also 8080), it seems that subsequent servlet registrations fail. A HTTP GET to this servlet either results in a java.net.ConnectException: Connection refused: connect or it returns a 404. Changing it to any other port number results in exactly the same error. Attached is a bundle that reproduces the issue, depending on a HttpService and ConfigurationAdmin implementation. The issue can be reproduced by using the Felix httpservice and Felix config admin deployed on a Felix framework. Summarized this is the use case: - Start HttpService and wait for it to become available (runs on 8080 by default) - Update the org.osgi.service.http.port to 8080 using Config Admin (so effectively nothing is changed) - Register a servlet - Open a URL connection to this servlet Now the very first time, this error appears in the console: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:525) at java.net.Socket.connect(Socket.java:475) at sun.net.NetworkClient.doConnect(NetworkClient.java:163) at sun.net.www.http.HttpClient.openServer(HttpClient.java:394) at sun.net.www.http.HttpClient.openServer(HttpClient.java:529) at sun.net.www.http.HttpClient.init(HttpClient.java:233) at sun.net.www.http.HttpClient.New(HttpClient.java:306) at sun.net.www.http.HttpClient.New(HttpClient.java:323) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:860) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:726) at org.amdatu.test.PortSwitchTest.checkURL(PortSwitchTest.java:86) at org.amdatu.test.PortSwitchTest.test(PortSwitchTest.java:50) at org.amdatu.test.Activator.addingService(Activator.java:30) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840) at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733) at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662) at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3721) at org.apache.felix.framework.Felix.access$000(Felix.java:80) at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:717) at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107) at org.apache.felix.framework.Felix.registerService(Felix.java:2842) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251) at org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:64) at org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:41) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) at
[jira] [Resolved] (FELIX-3737) HttpFilter service.ranking is not evaluated properly under some circumstances
[
https://issues.apache.org/jira/browse/FELIX-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.W. Janssen resolved FELIX-3737.
-
Resolution: Fixed
Fixed in rev.1402499, solved a failing JUnit in rev.1512329.
HttpFilter service.ranking is not evaluated properly under some circumstances
-
Key: FELIX-3737
URL: https://issues.apache.org/jira/browse/FELIX-3737
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.2.0
Reporter: Philipp Marx
Assignee: Felix Meschberger
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
If a Http-Filter is registered with a service.ranking of Interger.MAX_VALUE
and another Http-Filter is registered with a negative service.ranking (like
org.apache.sling.i18n.impl.I18NFilter which has -700) the evaluation of the
sorting order (mostly) fails.
The problem is FilterHandler's compareTo method which leads to an overflow in
this case:
public int compareTo(FilterHandler other)
{
return other.ranking - this.ranking;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2905) Update Jetty version to 6.1.26
[ https://issues.apache.org/jira/browse/FELIX-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-2905. - Resolution: Fixed Upgraded to latest Jetty 7 in rev.1512342, I presume this is not a problem? If so, reopen this issue. Update Jetty version to 6.1.26 -- Key: FELIX-2905 URL: https://issues.apache.org/jira/browse/FELIX-2905 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Rob Walker Assignee: Rob Walker Priority: Minor Noticed during some testing here that there is a slightly newer Jetty version, 6.1.26 Assuming there's no objections I'll commit the updated POM if my tests here all work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-773) Jetty 6 version seems to throw exceptions when streams end e.g. on browser exit or navigation away
[ https://issues.apache.org/jira/browse/FELIX-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-773. Resolution: Unresolved I've not seen this with the latest snapshot of felix-http. Please reopen if the issue is reproduceable in the latest snapshot. Jetty 6 version seems to throw exceptions when streams end e.g. on browser exit or navigation away -- Key: FELIX-773 URL: https://issues.apache.org/jira/browse/FELIX-773 Project: Felix Issue Type: Bug Components: HTTP Service Reporter: Rob Walker Priority: Minor Exceptions of the kind shown below seem to get thrown and show on the console In the main, the trigger for these seems to be browse exit or navigation away from Jetty served pages Note: the above issue may in fact be specific GWT / GWT RPC and related to the way it expects Http connections/streams to operate, so may not in fact be a Jetty or HttpService issue. --+ /:Exception while dispatching incoming RPC call org.mortbay.jetty.EofException at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:787) at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:566) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:908) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:650) at org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:587) at com.google.gwt.user.server.rpc.RPCServletUtils.writeResponse(RPCServletUtils.java:234) at com.google.gwt.user.server.rpc.RemoteServiceServlet.writeResponse(RemoteServiceServlet.java:379) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.OsgiServletHolder.handle(OsgiServletHolder.java:101) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363) at org.mortbay.jetty.servlet.OsgiServletHandler.handle(OsgiServletHandler.java:117) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:840) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:657) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:377) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:499) Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host at sun.nio.ch.SocketDispatcher.writev0(Native Method) at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:37) at sun.nio.ch.IOUtil.write(IOUtil.java:164) at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:365) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:388) at java.nio.channels.SocketChannel.write(SocketChannel.java:360) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:232) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:211) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:710) ... 24 more org.mortbay.log:/VtWebUi/EventService/1wg1avy57ellz~0 java.lang.IllegalStateException: STREAM at org.mortbay.jetty.Response.getWriter(Response.java:586) at com.google.gwt.user.server.rpc.RPCServletUtils.writeResponseForUnexpectedFailure(RPCServletUtils.java:255) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doUnexpectedFailure(RemoteServiceServlet.java:285) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:99) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at
[jira] [Created] (FELIX-4194) Add authorization support to web console
Carsten Ziegeler created FELIX-4194: --- Summary: Add authorization support to web console Key: FELIX-4194 URL: https://issues.apache.org/jira/browse/FELIX-4194 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Carsten Ziegeler We should add some sort of authorization support to the web console, to further restrict the possibilities. The main idea is to support the reading and the writing use cases, so some user should only get read (informational) access, while others have the ability to change things. Started a thread in the mailing list to discuss the details further -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DS/SCR] Configuration Binding
Hi Thanks for the discussions. To wrap this up: turns out I was wrong and so I fixed the issue as part of FELIX-3360 in the Configuration Admin service implementation. Regards Felix Am 12.08.2013 um 10:39 schrieb Julian Sedding: See FELIX-3360, where I raised the same issue and provided a patch. The patch may be outdated by now, I didn't check recently. Regards Julian [0] https://issues.apache.org/jira/browse/FELIX-3360 On Mon, Aug 12, 2013 at 9:42 AM, Marcel Offermans marcel.offerm...@luminis.nl wrote: I don't think you're missing something. The spec states CA should be doing that already, so if our implementation is not, we should raise a bug. Greetings, Marcel On Aug 12, 2013, at 9:40 , David Jencks david_jen...@yahoo.com wrote: Hi, I was under the impression that setting the location of the configuration to null when the bundle that owns the configuration is uninstalled was the responsibility of config admin. Config admin sets the location when you call getConfiguration using the bundle's CA, surely it is also CA's responsibility to track the bundle and undo the locations when the bundle is uninstalled. Am I missing something? I don't see how it could affect this but I have a few tests and bug fixes for location binding and targeted pids that I hope to finish up and commit in the next couple of days. thanks david jencks On Aug 12, 2013, at 12:34 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi Am 12.08.2013 um 08:16 schrieb Marcel Offermans: Hello Felix, On Aug 12, 2013, at 7:52 AM, Felix Meschberger fmesc...@adobe.com wrote: Currently our Declarative Services implementation statically binds configuration to the using bundle when such configuration is used to configure a component. The intent was to follow the Configuration Admin specification which also statically binds configuration to ManagedService[Factory] when first supplying configuration which is not previously bound. In fact, the spec calls this dynamic binding when you supply a configuration that will be bound to the first bundle that registers a MS[F] with that PID. If this is indeed what you're talking about then I don't really get the problem you're describing as the spec already states (4.3 compendium 104.4.2): When this dynamically bound Bundle is subsequently uninstalled, configurations that are bound to this bundle must be released. That means that for such Configuration object’s the bundle location must be set to null again so it can be bound again to another bundle. Yes, that would be my solution (2) ;-) This mechanism works really nicely but has a problematic drawback: When the owning bundle is uninstalled, configurations remain bound. If a new version of the same bundle is installed later, configuration will thus not be supplied because, presumably, the bundle will have a new bundle location and thus does not own the configuration. I could imagine two solutions to this problem: (1) DS does not statically bind configuration any longer. So, if unbound configuration is supplied to a component, it just remains unbound. In my understanding, this bends on the semantics defined by the Configuration Admin specification. (2) DS maintains a list of configurations which it has statically bound. On Bundle UNINSTALLED events the location of the uninstalled bundle is matched against the bindings of the configurations in the list and if such bindings exists, it is removed again. In my understanding, this would be the correct solution but is somewhat more complicated to implement. WDYT ? Just exploring the possible solutions: (3) make sure you always set the location for the bundle with the same value, even after a re-install (for example, deployment admin uses the BSN as the location, which nicely solves this problem) You can only set the location from Bundle.getLocation() and DS has no influence on that. Other installers may use the actual source URL from which the bundle was installed. (4) if you target 4.3 you could look into using the multi-location feature (although that might be bending the spec a bit as well) Right. That's a thread for the Web Console for example: If configuration is created with the Web Console it should use the generic ?* location by default if the appropriate Configuration Admin API is wired. Regards Felix Greetings, Marcel
[jira] [Commented] (FELIX-3846) Felix + Felix HTTP Jetty causes IllegalStateException during start up
[ https://issues.apache.org/jira/browse/FELIX-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739814#comment-13739814 ] J.W. Janssen commented on FELIX-3846: - I'm not sure that the proposed fix is even necessary with the upgrade to Jetty 7. I am able to reproduce the problem with Jetty 6, but never with Jetty 7. Can somebody confirm this? Felix + Felix HTTP Jetty causes IllegalStateException during start up - Key: FELIX-3846 URL: https://issues.apache.org/jira/browse/FELIX-3846 Project: Felix Issue Type: Bug Components: Framework, HTTP Service Affects Versions: framework-4.0.3, http-2.2.0 Environment: Java version: 1.6.0_37, vendor: Apple Inc. All operating systems Reporter: Ronald Chen Attachments: felix-http-jetty-2.2.0-fix-illegal-state-exception.patch There is a race condition during the activation of the felix http jetty bundle when used within a felix container. During the activation of the felix http jetty bundle you will intermittently see: java.lang.IllegalStateException: Can only register services while bundle is active or activating. at org.apache.felix.framework.Felix.registerService(Felix.java:3209) ~[na:na] at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) ~[na:na] at org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135) ~[org.apache.felix.http.jetty_2.2.0.jar:na] at org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48) ~[org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.jetty.Server.doStart(Server.java:224) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115) [org.apache.felix.http.jetty_2.2.0.jar:na] at org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290) [org.apache.felix.http.jetty_2.2.0.jar:na] at java.lang.Thread.run(Thread.java:680) [na:1.6.0_37] I debugged into line Felix.java:3209 and discovered the cause by is thrown by Felix.java:4875 which is: throw new IllegalStateException(Unable to acquire bundle lock, thread interrupted.); I dug around and discovered the thread which acquired the lock was the one created on JettyService.java:75 Looking at usages of the thread field, I think I discovered the source of the interrupt on line JettyService.java:75. What I think is happening is this: 1. felix container starts jetty bundle 2. jetty activator is run which creates a new jetty service 3. jetty service creates a new thread and initializes jetty 4. jetty attempts to register the http service to the felix container and obtains the felix bundle lock (Felix.java:4871) 5. at the same time something calls JettyService.update(Dictionary) which interrupts the thread in attempts to restart the jetty server 6. this causes the felix bundle lock to be interrupted and IllegalStateException is thrown At which point the http service is not registered and we sob quietly. To fix this issue I think the thread jetty service creates should never leave the jetty space. When it needs to register the http service a new thread should be created so it doesn't allow the possibility of the jetty service thread to obtain a lock it shouldn't. Alternatively in stop using interrupt() to signal change as
[jira] [Resolved] (FELIX-3265) AJAX Error: Request Failed: FULL head
[ https://issues.apache.org/jira/browse/FELIX-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-3265. - Resolution: Fixed I assume that the fix is sufficient; closing this issue. If not, please reopen it... AJAX Error: Request Failed: FULL head - Key: FELIX-3265 URL: https://issues.apache.org/jira/browse/FELIX-3265 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.0 Environment: Windows Vista x86, Java 6 Reporter: Deniz Acay Labels: buffer, felix, jetty I have been using Web Console for a while to configure my DS components. But recently, one of my component's metatype.xml file got larger due to increase in configuration options for the component. Suddenly, now when I try to configure that component, even without changing a value, I get an AJAX error. Although sometimes there is no message inside the AJAX Error dialog at all, I frequently get a Request failed: FULL head message in the AJAX Error modal dialog. I have searched around the internet and it looks like the cause of this is about the size of the Jetty's header buffer (http://jira.codehaus.org/browse/JETTY-336). Any fix is appreciated as this prevents me from debugging configuration of my component. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
