mmm distribution dependency should be optional. Feel free to track a bug
Le ven. 4 déc. 2020 à 20:36, Carlos Munoz 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.
>
>
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 wrote:
> ha, and looking a bit more at it, "authorizedUsers" is a set of service
>
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.
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
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
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)
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 =
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.
Hi Carlos,
On Wed, 2020-06-10 at 09:19 -0400, Carlos Munoz wrote:
> Thank you both for the ideas. At this point we are thinking of a
> larger
> changes (more than just property mappings or resource type changes),
> so
> Daniel's approach sounds like a better fit.
>
> When you say "pull it down"
Thank you both for the ideas. At this point we are thinking of a larger
changes (more than just property mappings or resource type changes), so
Daniel's approach sounds like a better fit.
When you say "pull it down" do you mean via the REST Api? If not, what
other way to export the data is there?
10 matches
Mail list logo
