Hi, I think you are hitting https://issues.apache.org/jira/browse/KARAF-6162
I fixed that already, it will be included in Cellar 4.1.3/4.2.0. Regards JB On 06/05/2019 14:18, cooshal wrote: > Hi: > > I am using Karaf 4.2.0 and Cellar 4.1.2 > > I am checking the cluster:bundle-* commands right now. The > start/stop/install/uninstall operations are functional and the behaviors are > as expected. But, I had an issue with the bundle-update command. I tried > this with and without stopping the target bundle. > >> cluster:bundle-update workers 181 file:\\\D:\\temp\\stats.jar > > In the logs, I can see that it says "Destroying BlueprintContainer for > bundle ..." and nothing happens after that. > > Then, if I try executing any of the cluster commands associated with this > group, it ends up with null pointer exception. > > karaf@root()> cluster:bundle-list workers > Bundles in cluster group workers > Error executing command: java.lang.NullPointerException > karaf@root()> log:tail > ERROR [Karaf local console user karaf] Exception caught while executing > command > java.lang.NullPointerException: null > at java.util.regex.Matcher.getTextLength(Matcher.java:1283) ~[?:?] > at java.util.regex.Matcher.reset(Matcher.java:309) ~[?:?] > at java.util.regex.Matcher.<init>(Matcher.java:229) ~[?:?] > at java.util.regex.Pattern.matcher(Pattern.java:1093) ~[?:?] > at > org.apache.karaf.cellar.core.CellarSupport.wildCardMatch(CellarSupport.java:220) > ~[?:?] > at > org.apache.karaf.cellar.core.CellarSupport.isAllowed(CellarSupport.java:189) > ~[?:?] > at > org.apache.karaf.cellar.bundle.shell.ListBundleCommand.doExecute(ListBundleCommand.java:142) > ~[?:?] > at > org.apache.karaf.cellar.core.shell.CellarCommandSupport.execute(CellarCommandSupport.java:62) > ~[?:?] > at > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) > ~[?:?] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) > ~[?:?] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) > ~[?:?] > at > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:571) ~[?:?] > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:497) > ~[?:?] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:386) > ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417) ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?] > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > ~[?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > ~[?:?] > at java.lang.Thread.run(Thread.java:745) [?:?] > > In the same cluster, executing the same command for a different group > produces the intended result. > > By any chance, did bundle-update corrupt the group information? > > Regards, > Cooshal. > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
