Issues with Attachments: week of 2014-01-13
KARAF - Monday, January 13, 2014 7 Issues with Attachments (sorted oldest to newest) [KARAF-1027] Have cave:update-repository work with proxy repositories - Created: 2011-11-20 - Updated: 2014-01-09 - Type: Improvement - Fix Versions: [cave-2.3.1] - Reporter: Glen Mazza - Assigned: Jean-Baptiste Onofré - Attachments: [proxyupdate.patch] - https://issues.apache.org/jira/browse/KARAF-1027 [KARAF-1056] Enhancements to cave:upload-artifact command - Created: 2011-11-28 - Updated: 2014-01-09 - Type: Improvement - Fix Versions: [cave-2.3.1] - Reporter: Glen Mazza - Assigned: Jean-Baptiste Onofré - Attachments: [uploadArtifact.patch] - https://issues.apache.org/jira/browse/KARAF-1056 [KARAF-1954] NullPointerException on custom Karaf shell command: ClassNotFoundException: org.apache.felix.service.command.Function not found - Created: 2012-10-19 - Updated: 2013-12-23 - Type: Bug - Fix Versions: [] - Reporter: Hendy Irawan - Assigned: Jean-Baptiste Onofré - Attachments: [karaf1954.zip] - https://issues.apache.org/jira/browse/KARAF-1954 [KARAF-1972] karaf-maven-plugin should respect scope - Created: 2012-10-24 - Updated: 2013-12-17 - Type: Bug - Fix Versions: [3.0.1] - Reporter: Andrei Pozolotin - Assigned: Unassigned - Attachments: [0001-Fixing-the-scope-handling.patch, KARAF-1972.patch] - https://issues.apache.org/jira/browse/KARAF-1972 [KARAF-2395] karaf:features-generate-descriptor fails with Maven 3.1.0 : No implementation for org.sonatype.aether.RepositorySystem was bound - Created: 2013-07-16 - Updated: 2013-12-18 - Type: Bug - Fix Versions: [] - Reporter: Robert Munteanu - Assigned: Jean-Baptiste Onofré - Attachments: [maven-3.1.0.patch, maven_upgrade.patch] - https://issues.apache.org/jira/browse/KARAF-2395 [KARAF-2630] GenerateDescriptorMojo does not resolve conflicts - Created: 2013-12-17 - Updated: 2014-01-04 - Type: Bug - Fix Versions: [3.0.1] - Reporter: Maarten Winkels - Assigned: Jean-Baptiste Onofré - Attachments: [karaf-2630.patch] - https://issues.apache.org/jira/browse/KARAF-2630 [KARAF-2676] Editing properties in configuration files managed via MangedServiceFactories leads to corrupt property file - Created: 2014-01-09 - Updated: 2014-01-12 - Type: Improvement - Fix Versions: [] - Reporter: Achim Finke - Assigned: Christian Schneider - Attachments: [ConfigManagedServiceFactoryTest.java] - https://issues.apache.org/jira/browse/KARAF-2676
Ideas for config admin with factories
Hi all, I have been working on https://issues.apache.org/jira/browse/KARAF-2676 . The problem described in the issue is that you can not edit factory based configs using their file name like you might expect as a user. I first thought this should be solveable easily but the core problem is deep in the config admin spec. Spec side: The spec handles factory based configs very differently from normal configs. For a normal config you have a user defined pid that you know in advance. We make use of this in the config:edit command where we specify a fixed pid and save this later in the conig:update command. For factory based configs the spec defines that you create such a config using createFactoryConfiguration with the factory pid as the parameter. The real pid is then named factoryPid.generated id. So there is no way to know this id beforehand. Felix config admin side: When reading a factory based config from etc felix config admin suports a file name scheme factorypid-id. So if felix config admin finds such a file it creates a config. The config pid does not match the scheme given though. It will always have a generated id. So it is difficult find it later. Karaf side: Currently we support creating a factory config in the update command if the pid defined in config:edit is like factoryPid-any string. The problem is that the string after the hyphen can not be given to config admin service. So the created config always looks like factoryPid.generated id. Felix config admin will also not be able to create a file for this config. Idea: So my idea is to do two things. In config:edit I would add an option --factory. If it is set then the pid given is treated as a factory pid. The edit then starts with an empty config and on config:update a new factory config is created and the pid is returned. I also would like to print if config:edit is called for a non existent config. Like: No config present with pid=pid. Creating new config on update. The idea behind this is to make it more obvious for users that intend to edit an existing config that they are not hitting the correct config. For the jira issue in the start this would have helped immensely to see what it going wrong. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Ideas for config admin with factories
+1 for me. Maybe the support of regex in config:edit can help too (to be able to find the first occurrence of a config matching a regexp). Regards JB On 01/13/2014 01:55 PM, Christian Schneider wrote: Hi all, I have been working on https://issues.apache.org/jira/browse/KARAF-2676 . The problem described in the issue is that you can not edit factory based configs using their file name like you might expect as a user. I first thought this should be solveable easily but the core problem is deep in the config admin spec. Spec side: The spec handles factory based configs very differently from normal configs. For a normal config you have a user defined pid that you know in advance. We make use of this in the config:edit command where we specify a fixed pid and save this later in the conig:update command. For factory based configs the spec defines that you create such a config using createFactoryConfiguration with the factory pid as the parameter. The real pid is then named factoryPid.generated id. So there is no way to know this id beforehand. Felix config admin side: When reading a factory based config from etc felix config admin suports a file name scheme factorypid-id. So if felix config admin finds such a file it creates a config. The config pid does not match the scheme given though. It will always have a generated id. So it is difficult find it later. Karaf side: Currently we support creating a factory config in the update command if the pid defined in config:edit is like factoryPid-any string. The problem is that the string after the hyphen can not be given to config admin service. So the created config always looks like factoryPid.generated id. Felix config admin will also not be able to create a file for this config. Idea: So my idea is to do two things. In config:edit I would add an option --factory. If it is set then the pid given is treated as a factory pid. The edit then starts with an empty config and on config:update a new factory config is created and the pid is returned. I also would like to print if config:edit is called for a non existent config. Like: No config present with pid=pid. Creating new config on update. The idea behind this is to make it more obvious for users that intend to edit an existing config that they are not hitting the correct config. For the jira issue in the start this would have helped immensely to see what it going wrong. What do you think? Christian -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Ideas for config admin with factories
Alternatively we could support an ldap filter for edit like we already do for list. If the ldap query matches exactly one config we could edit it. Christian On 13.01.2014 14:08, Jean-Baptiste Onofré wrote: +1 for me. Maybe the support of regex in config:edit can help too (to be able to find the first occurrence of a config matching a regexp). Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Ideas for config admin with factories
Yes, good idea. Regards JB On 01/13/2014 02:27 PM, Christian Schneider wrote: Alternatively we could support an ldap filter for edit like we already do for list. If the ldap query matches exactly one config we could edit it. Christian On 13.01.2014 14:08, Jean-Baptiste Onofré wrote: +1 for me. Maybe the support of regex in config:edit can help too (to be able to find the first occurrence of a config matching a regexp). Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Having commands for scheduler module
Hi guys There is a module in Karaf named scheduler. It's a simple scheduler implemented using java.util.Timer, contains only 4 classes and registers a TaskScheduler service manually. There is no dependency to this module in Karaf. Here is my questions: 1. Why this module registers its only service (TaskScheduler) manually in Activator class (not using blueprint.xml like other modules) and the service has no interface (just the implementation class)? I Don't know whether this is intentional or not! If there is some reasons behind this design, what are they and if it has been designed this way just because its an old module, is it possible to refactor it and make it consistent with other modules? 2. Why there isn't any command to interact with scheduler? The scheduler bundle have a ServiceListener which listens for any changes in services and if a service class is an instance of Runnable (that means it's a Thread), adds it to the list of task schedulers and tries to run it in given time periods. So there is no way to stop a repetitive task other than undeploying the service implementing it. Also it seems that it would be reasonable to have an option to change the repeating pattern or pause it and etc. I Think we can have a command module to implement these options and let the user to have more control over the scheduler. I've tried to implement such command and I like to know your ideas about this topic before finalizing implementation. Regards. - E.Z.Moghaddam zaerymoghad...@gmail.com -- View this message in context: http://karaf.922171.n3.nabble.com/Having-commands-for-scheduler-module-tp4030991.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Problem wiith build 3.0.1-SNAPSHOT
Hi, after build the latest version , I execute karaf , the application waits indefinitely , here are the logs : NFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.jaas.modules is waiting for namespace handlers [ http://karaf.apache.org/xmlns/ jaas/v1.0.0 ] 2014-01-14 00:11:15,534 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.shell.console is waiting for dependencies [ (objectClass = org.apache.felix.service.threadio.ThreadIO ) (objectClass = org.apache.felix.service.command.CommandProcessor ) ] 2014-01-14 00:11:15,549 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.shell.help is waiting for dependencies [ (objectClass = org.apache.felix.service.threadio.ThreadIO ) ] 2014-01-14 00:11:15,555 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.system.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,611 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.shell.commands is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,663 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.bundle.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,670 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.features.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,682 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.region.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.0.0 ] 2014-01-14 00:11:15,721 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.config.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] - CTO , JeetConsulting. Analyze now your Maven Java projects' dependencies , here -- View this message in context: http://karaf.922171.n3.nabble.com/Problem-wiith-build-3-0-1-SNAPSHOT-tp4030992.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Problem wiith build 3.0.1-SNAPSHOT
Hi, do you have an internet connection when you run Karaf ? All namespace handlers don't look to be there. I try if the problem is on Jenkins (I tested on my machine without problem). Regards JB On 01/14/2014 12:25 AM, nseb wrote: Hi, after build the latest version , I execute karaf , the application waits indefinitely , here are the logs : NFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.jaas.modules is waiting for namespace handlers [ http://karaf.apache.org/xmlns/ jaas/v1.0.0 ] 2014-01-14 00:11:15,534 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.shell.console is waiting for dependencies [ (objectClass = org.apache.felix.service.threadio.ThreadIO ) (objectClass = org.apache.felix.service.command.CommandProcessor ) ] 2014-01-14 00:11:15,549 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.shell.help is waiting for dependencies [ (objectClass = org.apache.felix.service.threadio.ThreadIO ) ] 2014-01-14 00:11:15,555 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.system.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,611 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.shell.commands is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,663 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.bundle.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,670 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.features.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] 2014-01-14 00:11:15,682 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.region.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.0.0 ] 2014-01-14 00:11:15,721 | INFO | FelixStartLevel | BlueprintContainerImpl | 6 - org.apache.aries.blueprint.core - 1.3.0 | Bundle org.apache.karaf.config.command is waiting for namespace handlers [ http :/ / karaf.apache.org/xmlns/shell/v1.1.0 ] - CTO , JeetConsulting. Analyze now your Maven Java projects' dependencies , here -- View this message in context: http://karaf.922171.n3.nabble.com/Problem-wiith-build-3-0-1-SNAPSHOT-tp4030992.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Having commands for scheduler module
Hi, the scheduler module is a very simple scheduler, that we added as a kind of PoC. It should be extended and enhanced. We are open to proposal to add new features and extend the scheduler. Regards JB On 01/13/2014 11:02 PM, zaerymoghaddam wrote: Hi guys There is a module in Karaf named scheduler. It's a simple scheduler implemented using java.util.Timer, contains only 4 classes and registers a TaskScheduler service manually. There is no dependency to this module in Karaf. Here is my questions: 1. Why this module registers its only service (TaskScheduler) manually in Activator class (not using blueprint.xml like other modules) and the service has no interface (just the implementation class)? I Don't know whether this is intentional or not! If there is some reasons behind this design, what are they and if it has been designed this way just because its an old module, is it possible to refactor it and make it consistent with other modules? 2. Why there isn't any command to interact with scheduler? The scheduler bundle have a ServiceListener which listens for any changes in services and if a service class is an instance of Runnable (that means it's a Thread), adds it to the list of task schedulers and tries to run it in given time periods. So there is no way to stop a repetitive task other than undeploying the service implementing it. Also it seems that it would be reasonable to have an option to change the repeating pattern or pause it and etc. I Think we can have a command module to implement these options and let the user to have more control over the scheduler. I've tried to implement such command and I like to know your ideas about this topic before finalizing implementation. Regards. - E.Z.Moghaddam zaerymoghad...@gmail.com -- View this message in context: http://karaf.922171.n3.nabble.com/Having-commands-for-scheduler-module-tp4030991.html Sent from the Karaf - Dev mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
