from "executionPermissionResource=/system/sling/permissions/pipes/exec" it seems you are on version 4.0.0 (which is the latest and that's good) in case you are on CQ, you can try that content package https://github.com/adobe/adobe-dx/tree/master/apps/scripts that installs required content for things to work.
Le ven. 4 déc. 2020 à 16:29, Carlos Munoz <camu...@redhat.com> a écrit : > Thanks Nicolas. > > 1 and 3 from your list are checked. > > 2 is the one where there is a problem. I should have added more context to > my previous email: At the point where a reference to the Plumber component > is requested I see the exception. Please see the component status below > this message. > > The problem I was referring to in the SingleComponentManager class, which > is part of the org.apache.felix.scr-2.1.16 bundle, is that when sling tries > to create the instance of the Plumber component it seems to be looking for > a constructor, which it is not finding, hence the NPE. > > 236=[org.apache.sling.pipes.internal.PlumberImpl] > Bundle=org.apache.sling.pipes (163) > State=failed activation > Failure=java.lang.NullPointerException > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:277) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:114) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:982) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:955) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:900) > at > org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347) > at > org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247) > at > org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350) > at org.apache.felix.framework.Felix.getService(Felix.java:3737) > at > org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470) > at org.osgi.framework.BundleContext$getService$0.call(Unknown > Source) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) > at test.run(test.groovy:13) > at > com.composum.sling.core.script.GroovyRunner.run(GroovyRunner.java:105) > at > com.composum.sling.core.script.GroovyRunner.run(GroovyRunner.java:88) > at > com.composum.sling.core.script.GroovyJobExecutor$GroovyRunnerCallable.call(GroovyJobExecutor.java:172) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > > DefaultState=enabled > Activation=delayed > ConfigurationPolicy=optional > ServiceType=singleton > Services=org.apache.sling.pipes.Plumber, > org.apache.sling.event.jobs.consumer.JobConsumer > ServiceId=807 > Reference=distributor, Satisfied > Service Name: org.apache.sling.distribution.Distributor > Cardinality: 0..1 > Policy: dynamic > Policy Option: reluctant > Reference=factory, Satisfied > Service Name: org.apache.sling.api.resource.ResourceResolverFactory > Cardinality: 1..1 > Policy: static > Policy Option: reluctant > Bound Service: ID 680 (Apache Sling Resource Resolver Factory) > Reference=jobManager, Satisfied > Service Name: org.apache.sling.event.jobs.JobManager > Cardinality: 1..1 > Policy: static > Policy Option: reluctant > Bound Service: ID 798 (org.apache.sling.event.impl.jobs.JobManagerImpl) > Properties= > authorizedUsers=[admin] > bufferSize=1000 > component.id=236 > component.name=org.apache.sling.pipes.internal.PlumberImpl > executionPermissionResource=/system/sling/permissions/pipes/exec > job.topics=org/apache/sling/pipes/topic > sleep=0 > > > On Fri, Dec 4, 2020 at 2:57 AM Nicolas Peltier <npelt...@apache.org> > wrote: > > > Hey Carlos, > > > > not sure i know SingleComponentManager nor your way of using an osgi > > service. > > The way i know is > > 1. check that sling pipes bundle is active (it needs sling query > > dependency), > > 2. check that plumberimpl is active > > 3. in your code have plumber as a reference (with the osgi annotation) > > > > Hope this helps > > Nicolas > > > > Le ven. 4 déc. 2020 à 03:36, Carlos Munoz <camu...@redhat.com> a écrit : > > > > > Hi Nicholas, > > > > > > I'm reviving this thread as I have continued to experiment with pipes > > > (specifically version 3.1.0) but I am getting an error when trying to > > get a > > > reference to the Plumber service. I've tracked down the error down to > the > > > class SingleComponentManager, line 277: > > > > > > implementationObject = > > getComponentMethods().getConstructor().newInstance( > > > componentContext, > > > paramMap); > > > > > > The getConstructor() method above is returning null which makes the > > service > > > unavailable to use. I was wondering if you have any ideas here. > > > > > > Regards, > > > > > > Carlos > > > > > > On Thu, Jun 11, 2020 at 3:45 AM Nicolas Peltier < > > peltier.nico...@gmail.com > > > > > > > wrote: > > > > > > > I would kindly disagree here on disqualifying pipes for *lot* of > > changes > > > in > > > > the structures. > > > > I'd say that it's specifically better in those cases (It was first > > > created > > > > for those), as you don't need the hassle of download / reupload and > you > > > > don't have to mess around serialization issues. > > > > > > > > > > > > Le mer. 10 juin 2020 à 14:57, Daniel Klco <dk...@apache.org> a > écrit : > > > > > > > > > I agree with Nicolas' approach, however it depends on the scale > > you're > > > > > attempting to make changes. > > > > > > > > > > If it's fairly straight forward such as resourceType/a => > > > resourceType/b > > > > or > > > > > property mapping, Sling Pipes is a great solution. If you need to > do > > a > > > > > *lot* of > > > > > changes to the structure if your content, you may be better to pull > > it > > > > > down, transform it offline and reload. > > > > > > > > > > On Wed, Jun 10, 2020 at 2:51 AM Nicolas Peltier < > npelt...@apache.org > > > > > > > > wrote: > > > > > > > > > > > Hi Carlos, > > > > > > > > > > > > one approach (not saying it's the best, i'm the main maintainer > of > > > > them) > > > > > is > > > > > > to use a handful of sling pipes [0] and script to kick them off, > or > > > as > > > > > > package hooks. > > > > > > > > > > > > Nicolas > > > > > > > > > > > > [0] > > https://sling.apache.org/documentation/bundles/sling-pipes.html > > > > > > > > > > > > Le mar. 9 juin 2020 à 23:55, Carlos Munoz <camu...@redhat.com> a > > > > écrit : > > > > > > > > > > > > > Hi Sling devs, I was wondering what the best approach would be > to > > > > take > > > > > an > > > > > > > exisiting repository and making changes to the content > structure > > > in a > > > > > > safe > > > > > > > and repeatable way. > > > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > > > > > > > > > > > > > > > > >
