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!
> > > > > >
> > > > >
> > > >
> > >
> >
>
