ha, and looking a bit more at it, "authorizedUsers" is a set of service users, and if non void, it will indeed try to fetch that service user and do stuff out of it. This is meant for asynchronous runs, and not necessarily what you are testing right now, so please just remove that configuration.
Le ven. 4 déc. 2020 à 17:22, Nicolas Peltier <peltier.nico...@gmail.com> a écrit : > 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! >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
