Re: karaf-3.0.2 Problem with console
Hi I've the same problem with 3.0.2-SNAPSHOT and 4.0.0-SNAPSHOT on Windows 7 (32-bit). I downloaded the apache-karaf-3.0.1.zip from project's website and it works fine. my mvn -version output is: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 17:21:28+0330) Maven home: E:\Programs\apache-maven-3.0.5 Java version: 1.7.0, vendor: Oracle Corporation Java home: E:\Softwares\JDK1.7\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: x86, family: windows Regards - Ehsan Zaery Moghaddam zaerymoghad...@gmail.com developmentor.blogspot.com -- View this message in context: http://karaf.922171.n3.nabble.com/karaf-3-0-2-Problem-with-console-tp4034304p4034312.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Karaf 4.0.0-SNAPSHOT hang on startup
Hi I've cloned the 4.0.0-SNAPSHOT repository and built it from scratch. When I try to run it, it hangs on startup with following message in karaf.log: 2014-07-17 12:29:16,235 | ERROR | pool-1-thread-1 | BootFeaturesInstaller | 6 - org.apache.karaf.features.core - 4.0.0.SNAPSHOT | Error installing boot features org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=management; type=karaf.feature; version=[4.0.0.SNAPSHOT,4.0.0.SNAPSHOT]; filter:=((osgi.identity=management)(type=karaf.feature)(version=4.0.0.SNAPSHOT)(version=4.0.0.SNAPSHOT)) [caused by: Unable to resolve management/4.0.0.SNAPSHOT: missing requirement [management/4.0.0.SNAPSHOT] osgi.identity; osgi.identity=org.apache.aries.jmx.core; type=osgi.bundle; version=[1.1.2,1.1.2]; resolution:=mandatory [caused by: Unable to resolve org.apache.aries.jmx.core/1.1.2: missing requirement [org.apache.aries.jmx.core/1.1.2] osgi.service; effective:=active; filter:=(objectClass=javax.management.MBeanServer)]] at org.apache.felix.resolver.Candidates.populateResource(Candidates.java:285)[6:org.apache.karaf.features.core:4.0.0.SNAPSHOT] at org.apache.felix.resolver.Candidates.processCandidates(Candidates.java:454)[6:org.apache.karaf.features.core:4.0.0.SNAPSHOT] at org.apache.felix.resolver.Candidates.populateResource(Candidates.java:266)[6:org.apache.karaf.features.core:4.0.0.SNAPSHOT] . . . . Base on older discussions, I tried different values for *respectStartLvlDuringFeatureStartup* and *featuresBootAsynchronous* properties but nothing happened. The org.apache.aries.jmx.core/1.1.2 already exists in users's maven repository as well as karaf/system repository. I'm using Windows 7 32bit, JDK 1.7 HotSpot. Is there any necessary configuration or installation hint that I missed? Regards - Ehsan Zaery Moghaddam zaerymoghad...@gmail.com developmentor.blogspot.com -- View this message in context: http://karaf.922171.n3.nabble.com/Karaf-4-0-0-SNAPSHOT-hang-on-startup-tp4034268.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
RAT plugin error on ssh key files
Hi Last night I was trying to rebuild the latest branches of the project from ground up (master, 3.0.x and 2.3.x). I noticed there is an error in RAT plugin while checking SSH key files. I created a JIRA issue ( KARAF-3129 https://issues.apache.org/jira/browse/KARAF-3129 ) and attached an appropriate patch for each branch to fix it by adding *.key pattern to RAT plugin's exclude list. Regards - Ehsan Zaery Moghaddam zaerymoghad...@gmail.com developmentor.blogspot.com -- View this message in context: http://karaf.922171.n3.nabble.com/RAT-plugin-error-on-ssh-key-files-tp4034281.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Having commands for scheduler module
Hi imho we have two option: 1. Extend the scheduler service and its related commands using classes in java.util.concurrent package, we can provide more advanced scheduling capabilities like dynamically adding/removing/suspending/resuming scheduled tasks. It can have commands and options like these: scheduler:list lists already scheduled tasks scheduler:schedule schedules given task base on delay or repeating parameters scheduler:unschedule removes given scheduled task from the list scheduler:suspend suspends given task scheduler:resume resumes an already suspended task 2. Define a new Karaf Feature to have Quartz scheduler in Karaf Currently there is an OSGi wrapper for Quartz in Apache ServiceMix (org.apache.servicemix.bundles.quartz) that may be useful to provide advanced scheduling capabilities. I think both options have their own pros and cons. The first option would be enough for most basic situations and no additional dependencies will be added to the project. The second one is a must have for any enterprise level project due to large number of options and features provided by Quartz. So a Karaf Feature to install Quartz bundles into container (like Spring Feature) could be devised in near future. Regards - E.Z.Moghaddam zaerymoghad...@gmail.com -- View this message in context: http://karaf.922171.n3.nabble.com/Having-commands-for-scheduler-module-tp4030991p4031001.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Having commands for scheduler module
roedll: Thanks for your info I had checked Apache Sling but I didn't mentioned your previous conversations in forum. I've read the discussion http://karaf.922171.n3.nabble.com/Task-scheduler-in-Karaf-td4028481.html and also checked the KARAF-751 https://issues.apache.org/jira/browse/KARAF-751 . The overall idea behind reusing modified version of sling bundle for scheduler to prevent reinventing the wheel seems good. But I'm unable to summarize the debate about the SCR vs Blueprint in KARAF-751 comments. The SCR is part of OSGi spec and there is no reason not to use it. About a month ago, there was a similar discussion about having A Blueprint Free Karaf http://karaf.922171.n3.nabble.com/A-Blueprint-Free-Karaf-td4030521.html in forum. @iocanel had developed a version of Karaf by replacing Blueprint with Felix SCR. But currently, all the modules in Karaf have implemented using Blueprint, and I think it would be better to keep this design for now and if someday in future, project committee decided to replace Blueprint with SCR, all modules will be changed in one step (like what @iocanel did). JB: What's your opinion? Regards - E.Z.Moghaddam zaerymoghad...@gmail.com -- View this message in context: http://karaf.922171.n3.nabble.com/Having-commands-for-scheduler-module-tp4030991p4031026.html Sent from the Karaf - Dev mailing list archive at Nabble.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.
Missing dependency to pax-web-spi:jar:3.0.5-SNAPSHOT
Hi When I try to build the trunk, it gives me the following error: Could not find artifact org.ops4j.pax.web:pax-web-spi:jar:3.0.5-SNAPSHOT The error is on HTTP Core module. There is no such pax-web-spi version in maven repositories (including http://oss.sonatype.org/content/repositories/ops4j-snapshots) or even in pax-web github releases history. It's current version is 4.0.0-SNAPSHOT. The last one is 3.0.4. I want to know whether it's my fault or not. Does it need some manual configuration? Regards Ehsan Zaery Moghaddam - E.Z.Moghaddam zaerymoghad...@gmail.com -- View this message in context: http://karaf.922171.n3.nabble.com/Missing-dependency-to-pax-web-spi-jar-3-0-5-SNAPSHOT-tp4030638.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Missing dependency to pax-web-spi:jar:3.0.5-SNAPSHOT
Hi As I said, I've tested this repository and nothing happened. I've also checked the https://oss.sonatype.org/content/repositories/ops4j-snapshots from browser, and there is no 3.0.5-SNAPSHOT version. Actually there is 2.0.3-SNAPSHOT and then 4.0.0-SNAPSHOT. No 3.x version exists at all. Seems you guys have this version in your local repositories. Regards Ehsan - E.Z.Moghaddam zaerymoghad...@gmail.com -- View this message in context: http://karaf.922171.n3.nabble.com/Missing-dependency-to-pax-web-spi-jar-3-0-5-SNAPSHOT-tp4030638p4030641.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Which config.properties and startup.properties with admin:create ?
Hi guys Isn't it possible having an option on admin:create to decide whether to create a new plain instance or use root instance configurations? For example: 'admin:create -c'. which '-c' could mean clone root instance's configuration. Regards Ehsan - E.Z.Moghaddam zaerymoghad...@gmail.com -- View this message in context: http://karaf.922171.n3.nabble.com/Which-config-properties-and-startup-properties-with-admin-create-tp4030050p4030137.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Build failure on Karaf trunk...
Hi all I've installed a new clean version of Ubuntu 13.01 with Maven 3.0.5, JRockit 1.6.0.45 . I've checked out a fresh copy of trunk and tried to build an eclipse project using mvn eclipse:eclipse and it gives me this error: [ERROR] Plugin org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT or one of its dependencies could not be resolved: Could not find artifact org.apache.karaf.tooling:karaf-maven-plugin:jar:3.0.0-SNAPSHOT - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT or one of its dependencies could not be resolved: Could not find artifact org.apache.karaf.tooling:karaf-maven-plugin:jar:3.0.0-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:140) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateLifecycleMappings(DefaultLifecycleExecutionPlanCalculator.java:280) at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateForkedLifecycle(DefaultLifecycleExecutionPlanCalculator.java:520) at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateForkedExecutions(DefaultLifecycleExecutionPlanCalculator.java:494) at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecution(DefaultLifecycleExecutionPlanCalculator.java:166) at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecutions(DefaultLifecycleExecutionPlanCalculator.java:139) at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:116) at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:129) at org.apache.maven.lifecycle.internal.BuilderCommon.resolveBuildPlan(BuilderCommon.java:92) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:60) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:354) Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact org.apache.karaf.tooling:karaf-maven-plugin:jar:3.0.0-SNAPSHOT at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:538) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:193) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:286) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:136) ... 28 more Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact org.apache.karaf.tooling:karaf-maven-plugin:jar:3.0.0-SNAPSHOT at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:528) at
