You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Carlos Munoz <ca...@redhat.com> on 2020/12/03 21:35:59 UTC
Re: Sling data migrations
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 <pe...@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 <np...@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 <ca...@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!
> > > >
> > >
> >
>
Re: Sling data migrations
Posted by Nicolas Peltier <pe...@gmail.com>.
mmm distribution dependency should be optional. Feel free to track a bug
Le ven. 4 déc. 2020 à 20:36, Carlos Munoz <ca...@redhat.com> a écrit :
> Ok, I finally debugged it enough to find that the component initialization
> for Plumber fails silently if the sling-distribution karaf feature is not
> installed.
>
> On Fri, Dec 4, 2020 at 11:32 AM Nicolas Peltier <np...@apache.org>
> wrote:
>
> > 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 <pe...@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 <ca...@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 <np...@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 <ca...@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.nicolas@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 <
> > >> npeltier@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 <
> camunoz@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!
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Sling data migrations
Posted by Carlos Munoz <ca...@redhat.com>.
Ok, I finally debugged it enough to find that the component initialization
for Plumber fails silently if the sling-distribution karaf feature is not
installed.
On Fri, Dec 4, 2020 at 11:32 AM Nicolas Peltier <np...@apache.org> wrote:
> 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 <pe...@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 <ca...@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 <np...@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 <ca...@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.nicolas@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 <
> >> npeltier@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 <camunoz@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!
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: Sling data migrations
Posted by Nicolas Peltier <np...@apache.org>.
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 <pe...@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 <ca...@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 <np...@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 <ca...@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.nicolas@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 <
>> npeltier@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 <ca...@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!
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: Sling data migrations
Posted by Nicolas Peltier <pe...@gmail.com>.
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 <ca...@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 <np...@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 <ca...@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.nicolas@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 <
> npeltier@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 <ca...@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!
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Sling data migrations
Posted by Nicolas Peltier <pe...@gmail.com>.
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 <ca...@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 <np...@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 <ca...@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.nicolas@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 <
> npeltier@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 <ca...@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!
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Sling data migrations
Posted by Carlos Munoz <ca...@redhat.com>.
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 <np...@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 <ca...@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.nicolas@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 <npeltier@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 <ca...@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!
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Sling data migrations
Posted by Carlos Munoz <ca...@redhat.com>.
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 <np...@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 <ca...@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.nicolas@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 <npeltier@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 <ca...@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!
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Sling data migrations
Posted by Nicolas Peltier <np...@apache.org>.
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 <ca...@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.nicolas@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 <np...@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 <ca...@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!
> > > > >
> > > >
> > >
> >
>
Re: Sling data migrations
Posted by Nicolas Peltier <np...@apache.org>.
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 <ca...@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.nicolas@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 <np...@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 <ca...@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!
> > > > >
> > > >
> > >
> >
>