You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Julian Sedding <js...@gmail.com> on 2020/10/24 14:33:56 UTC
Improving support for deploying Repoinit DSL files
Hi all
I am working on "older" Sling setups that do not yet use the feature
model to describe instances. Rather they leverage the OSGi Installer
for deployment of bundles and configurations.
Currently I am looking into using Repoinit for setting up
Service-Users and ACLs, and possibly also paths and groups. The
current implementation of the Repoinit JCR bundle allows setting up
factory configurations with "scripts" and "references". Scripts are
little (or not so little) snippets of Repoinit DSL, references are
URLs to files containing Repoinit DSL. So far so good.
For a maintainable setup, the Repoinit DSL should be checked into Git
(or SCM of choice). However, as Dan already noticed in "SLING-9524 -
Add Support for Bundle URL References", it is not currently possible
to reference bundle resources in a stable fashion. This renders the
"references" Configuration virtually useless (that may be too harsh,
maybe I am missing something). The "scripts" configurations work, but
they require the Repoinit DSL to be embedded in a configuration file,
typically requiring escaping and all on one line.
To improve the situation I have two suggestions.
(1) Add support for a Bundle-Header (e.g. Sling-RepoInit) with a comma
separated list of paths to bundle resources. This would allow
embedding Repoinit Files into bundles, which could be useful for
keeping service-users creation and bundles together. However, this
solution would not lend itself to supplying runmode-specific Repoinit
files. Of course the header could be extended to support a runmode
qualifier, but to me at least it starts to feel a little wrong when
bundles (i.e. code) have to know so much about runmodes (i.e.
deployments).
(2) Add OSGiInstaller support for Repoinit files. I.e. recognize files
in "install" or "config" folders with a ".txt" extension that can be
parsed by the RepoInitParser. This requires separate deployment, e.g.
via a content-package. However, runmode support then comes out of the
box.
I could imagine adding one or both of these solutions to the Repoinit
JCR bundle.
Any thoughts on this? Are there any concerns regarding security or
other objections?
Thanks
Julian
Re: Improving support for deploying Repoinit DSL files
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday, November 2, 2020 3:50:07 PM CET Bertrand Delacretaz wrote:
> Hi,
Hi Bertrand,
> On Sat, Oct 24, 2020 at 4:34 PM Julian Sedding <js...@gmail.com> wrote:
> > ...as Dan already noticed in "SLING-9524 -
> > Add Support for Bundle URL References", it is not currently possible
> > to reference bundle resources in a stable fashion. This renders the
> > "references" Configuration virtually useless...
>
> FWIW, this feature was added to support grabbing repoinit "scripts"
> from the Sling provisioning model using model@repoinit:context:/...
> references [1]. But as noted it is not useful for bundle resources.
It is useful, see my example.
Regards,
O.
> -Bertrand
>
> [1]
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/1ed447ae
> 1daece383a619f564b3263d67f891b43/src/main/java/org/apache/sling/jcr/repoinit
> /impl/RepoinitTextProvider.java#L42
Re: Improving support for deploying Repoinit DSL files
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sat, Oct 24, 2020 at 4:34 PM Julian Sedding <js...@gmail.com> wrote:
> ...as Dan already noticed in "SLING-9524 -
> Add Support for Bundle URL References", it is not currently possible
> to reference bundle resources in a stable fashion. This renders the
> "references" Configuration virtually useless...
FWIW, this feature was added to support grabbing repoinit "scripts"
from the Sling provisioning model using model@repoinit:context:/...
references [1]. But as noted it is not useful for bundle resources.
-Bertrand
[1] https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/1ed447ae1daece383a619f564b3263d67f891b43/src/main/java/org/apache/sling/jcr/repoinit/impl/RepoinitTextProvider.java#L42
Re: Improving support for deploying Repoinit DSL files
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Julian,
Am 29.10.2020 um 15:44 schrieb Julian Sedding:
>
> Carsten Ziegeler wrote on SLING-9862
>> I personally don't like the idea to have repoinit inside a bundle; so if we can
>> come to a solution where no new header is introduced that's probably better.
>> Today, you can install a feature, which references bundles, configurations
>> and repoinit - which I think is a much more flexible way than having everything
>> inside the code bundle. Users of your code might use different users, different
>> content paths (if configurable) etc.
>
> Unfortunately I am in no position to use the feature model. I am
> looking for solutions on how to better leverage repoinit on older
> Sling deployments (namely AEM 6.5 on-prem), where the OSGi installer
> is still the main means for deployment. Or am I missing something and
> it is possible to use the feature model for this?
>
There is a plugin for the feature model:
https://github.com/apache/sling-org-apache-sling-installer-factory-feature/
It supports feature model files as well as feature archives and that of
course includes repoinit.
> My goal is finding a way to maintain repoinit files in a Git
> Repository and have them applied to the instance upon deployment via
> content-packages. The existing "RepositoryInitializerFactory"
> configuration does not quite cut it, as I outlined previously in this
> thread (mainly the "scripts" configs are not maintainable due to
> required escaping within config files and "references" to bundle
> resources are not predictable, see SLING-9524).
>
> I think a bundle developer knows best which permissions a service user
> requires. Therefore I see some value in allowing the bundle to
> transport such information. However, I acknowledge that embedding such
> information in the bundle could take away flexibility for deployments
> to customize the setup. And as you mention, it _is_ possible to use a
> different name for a service-user.
>
> An alternative could be a repoinit installer factory for the OSGi
> Installer. This would allow repoinit files to be deployed via
> content-package, e.g. in an /apps/myapp/config folder.
>
> Also a combination of the two could be worthwhile: the bundle-header
> approach could be opt-in and guarded by a configuration that allows
> whitelisting bundle symbolic names for which embedded repoinit scripts
> should be deployed. A warning could be printed for any bundle that
> contains repoinit scripts but is not whitelisted. And finally, an
> "ignore"-list of bundle symbolic names could allow suppressing the
> warning. The logging would draw a deployer's attention to the fact
> that a bundle embeds repoinit files and ideally prompt them to
> whitelist it or to add it to the ignore list. Even in the case of the
> ignore list, the deployer could extract the repoinit files and modify
> them.
>
> Any custom repoinit configurations could be deployed via OSGi installer.
>
> I am not fixed on either solution, but I would like _a_ way forward.
> I'd also be happy with "just" the repoinit installer factory.
>
This could be done with a feature model just containing repoinit.
Now, authoring repoinit in a feature model directly is not nice either,
but if you use a maven project to create the feature model, you can make
use of
https://issues.apache.org/jira/browse/SLING-9725
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Improving support for deploying Repoinit DSL files
Posted by Julian Sedding <js...@gmail.com>.
Hi
@Carsten: thanks for the pointers, I had missed
o.a.s.installer.factory.feature. After spending some trying, I managed
to get everything set up correctly. However, I encountered SLING-9869,
where a feature JSON file is treated as a feature archive leading to
an exception. I should be able to come up with a fix in the next few
days.
On a related note: I didn't manage to create a FAR with the JSON
included as JSON. I always ended up with the JSON file inside the FAR,
but with a JAR extension. Any pointers?
@Oliver: thank you for the pointers to the paxurl support for
classpath URLs. I may go down this route if all else fails, because it
will certainly work.
After thinking about the problem at hand, I am leaning towards
agreeing with Carsten that repoinit files are a deployment concern and
don't belong inside a bundle. Even though I would be open to allowing
a default/sample repoinit file inside, which could be used based on an
opt-in mechanism.
The feature model installer factory (once fixed) allows indirectly
deploying repoinit files via e.g. content-packages and thus meets my
requirement. For the purpose of "only" deploying repoinit files it
seems like overkill, as it requires the use of the
slingfeature-maven-plugin for inlining the repoinit file into a
feature JSON file. However, it might be interesting to move more
deployment artifacts (e.g. confings, bundles and content-packages)
into a FAR and move the application closer to being "feature-model
ready (TM)".
Regards
Julian
On Thu, Oct 29, 2020 at 4:57 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
>
> On Thursday, October 29, 2020 3:44:35 PM CET Julian Sedding wrote:
> > Hi
>
> Hi *,
>
> > Thank you Oliver for the suggestion. I have attempted using the
> > "classpath" scheme as, but I get "java.lang.IllegalStateException:
> > Unknown protocol: classpath". Maybe Karaf has an additional URLHandler
> > for "classpath"?
>
> Yes, Pax URL which can be used outside of Karaf of course:
> https://ops4j1.jira.com/wiki/spaces/paxurl/overview
>
> And see here for the bundles:
> https://github.com/apache/sling-org-apache-sling-testing-paxexam/blob/master/
> src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L168
>
> Regards,
> O.
>
>
> > Carsten Ziegeler wrote on SLING-9862
> >
> > > I personally don't like the idea to have repoinit inside a bundle; so if
> > > we can come to a solution where no new header is introduced that's
> > > probably better. Today, you can install a feature, which references
> > > bundles, configurations and repoinit - which I think is a much more
> > > flexible way than having everything inside the code bundle. Users of your
> > > code might use different users, different content paths (if configurable)
> > > etc.
> >
> > Unfortunately I am in no position to use the feature model. I am
> > looking for solutions on how to better leverage repoinit on older
> > Sling deployments (namely AEM 6.5 on-prem), where the OSGi installer
> > is still the main means for deployment. Or am I missing something and
> > it is possible to use the feature model for this?
> >
> > My goal is finding a way to maintain repoinit files in a Git
> > Repository and have them applied to the instance upon deployment via
> > content-packages. The existing "RepositoryInitializerFactory"
> > configuration does not quite cut it, as I outlined previously in this
> > thread (mainly the "scripts" configs are not maintainable due to
> > required escaping within config files and "references" to bundle
> > resources are not predictable, see SLING-9524).
> >
> > I think a bundle developer knows best which permissions a service user
> > requires. Therefore I see some value in allowing the bundle to
> > transport such information. However, I acknowledge that embedding such
> > information in the bundle could take away flexibility for deployments
> > to customize the setup. And as you mention, it _is_ possible to use a
> > different name for a service-user.
> >
> > An alternative could be a repoinit installer factory for the OSGi
> > Installer. This would allow repoinit files to be deployed via
> > content-package, e.g. in an /apps/myapp/config folder.
> >
> > Also a combination of the two could be worthwhile: the bundle-header
> > approach could be opt-in and guarded by a configuration that allows
> > whitelisting bundle symbolic names for which embedded repoinit scripts
> > should be deployed. A warning could be printed for any bundle that
> > contains repoinit scripts but is not whitelisted. And finally, an
> > "ignore"-list of bundle symbolic names could allow suppressing the
> > warning. The logging would draw a deployer's attention to the fact
> > that a bundle embeds repoinit files and ideally prompt them to
> > whitelist it or to add it to the ignore list. Even in the case of the
> > ignore list, the deployer could extract the repoinit files and modify
> > them.
> >
> > Any custom repoinit configurations could be deployed via OSGi installer.
> >
> > I am not fixed on either solution, but I would like _a_ way forward.
> > I'd also be happy with "just" the repoinit installer factory.
> >
> > Regards
> > Julian
> >
> > On Sat, Oct 24, 2020 at 5:46 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
> > > On Saturday, October 24, 2020 4:33:56 PM CEST Julian Sedding wrote:
> > > > Hi all
> > >
> > > Hi Julian,
> > >
> > > > I am working on "older" Sling setups that do not yet use the feature
> > > > model to describe instances. Rather they leverage the OSGi Installer
> > > > for deployment of bundles and configurations.
> > > >
> > > > Currently I am looking into using Repoinit for setting up
> > > > Service-Users and ACLs, and possibly also paths and groups. The
> > > > current implementation of the Repoinit JCR bundle allows setting up
> > > > factory configurations with "scripts" and "references". Scripts are
> > > > little (or not so little) snippets of Repoinit DSL, references are
> > > > URLs to files containing Repoinit DSL. So far so good.
> > > >
> > > > For a maintainable setup, the Repoinit DSL should be checked into Git
> > > > (or SCM of choice). However, as Dan already noticed in "SLING-9524 -
> > > > Add Support for Bundle URL References", it is not currently possible
> > > > to reference bundle resources in a stable fashion. This renders the
> > > > "references" Configuration virtually useless (that may be too harsh,
> > > > maybe I am missing something). The "scripts" configurations work, but
> > > > they require the Repoinit DSL to be embedded in a configuration file,
> > > > typically requiring escaping and all on one line.
> > >
> > > Until October 2017 Sling Karaf was using a dedicated bundle for repoinit
> > > files which worked AFAIR quite well (see SLING-7177).
> > > I also do not like the escaped one liners in JSON and will look into this
> > > approach again.
> > >
> > > See also the very last diff entry in
> > > https://github.com/apache/sling-org-apache-sling-karaf-configs/commit/f5d
> > > 9b596e854e91e5f8fc81a575f89beb0082f62
> > >
> > > references=[\
> > >
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt
> > > ",\
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\
> > > "raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\
> > >
> > > ]
> > >
> > > HTH,
> > > O.
> > >
> > > > To improve the situation I have two suggestions.
> > > >
> > > > (1) Add support for a Bundle-Header (e.g. Sling-RepoInit) with a comma
> > > > separated list of paths to bundle resources. This would allow
> > > > embedding Repoinit Files into bundles, which could be useful for
> > > > keeping service-users creation and bundles together. However, this
> > > > solution would not lend itself to supplying runmode-specific Repoinit
> > > > files. Of course the header could be extended to support a runmode
> > > > qualifier, but to me at least it starts to feel a little wrong when
> > > > bundles (i.e. code) have to know so much about runmodes (i.e.
> > > > deployments).
> > > >
> > > > (2) Add OSGiInstaller support for Repoinit files. I.e. recognize files
> > > > in "install" or "config" folders with a ".txt" extension that can be
> > > > parsed by the RepoInitParser. This requires separate deployment, e.g.
> > > > via a content-package. However, runmode support then comes out of the
> > > > box.
> > > >
> > > > I could imagine adding one or both of these solutions to the Repoinit
> > > > JCR bundle.
> > > >
> > > > Any thoughts on this? Are there any concerns regarding security or
> > > > other objections?
> > > >
> > > > Thanks
> > > > Julian
>
>
>
>
Re: Improving support for deploying Repoinit DSL files
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Thursday, October 29, 2020 3:44:35 PM CET Julian Sedding wrote:
> Hi
Hi *,
> Thank you Oliver for the suggestion. I have attempted using the
> "classpath" scheme as, but I get "java.lang.IllegalStateException:
> Unknown protocol: classpath". Maybe Karaf has an additional URLHandler
> for "classpath"?
Yes, Pax URL which can be used outside of Karaf of course:
https://ops4j1.jira.com/wiki/spaces/paxurl/overview
And see here for the bundles:
https://github.com/apache/sling-org-apache-sling-testing-paxexam/blob/master/
src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L168
Regards,
O.
> Carsten Ziegeler wrote on SLING-9862
>
> > I personally don't like the idea to have repoinit inside a bundle; so if
> > we can come to a solution where no new header is introduced that's
> > probably better. Today, you can install a feature, which references
> > bundles, configurations and repoinit - which I think is a much more
> > flexible way than having everything inside the code bundle. Users of your
> > code might use different users, different content paths (if configurable)
> > etc.
>
> Unfortunately I am in no position to use the feature model. I am
> looking for solutions on how to better leverage repoinit on older
> Sling deployments (namely AEM 6.5 on-prem), where the OSGi installer
> is still the main means for deployment. Or am I missing something and
> it is possible to use the feature model for this?
>
> My goal is finding a way to maintain repoinit files in a Git
> Repository and have them applied to the instance upon deployment via
> content-packages. The existing "RepositoryInitializerFactory"
> configuration does not quite cut it, as I outlined previously in this
> thread (mainly the "scripts" configs are not maintainable due to
> required escaping within config files and "references" to bundle
> resources are not predictable, see SLING-9524).
>
> I think a bundle developer knows best which permissions a service user
> requires. Therefore I see some value in allowing the bundle to
> transport such information. However, I acknowledge that embedding such
> information in the bundle could take away flexibility for deployments
> to customize the setup. And as you mention, it _is_ possible to use a
> different name for a service-user.
>
> An alternative could be a repoinit installer factory for the OSGi
> Installer. This would allow repoinit files to be deployed via
> content-package, e.g. in an /apps/myapp/config folder.
>
> Also a combination of the two could be worthwhile: the bundle-header
> approach could be opt-in and guarded by a configuration that allows
> whitelisting bundle symbolic names for which embedded repoinit scripts
> should be deployed. A warning could be printed for any bundle that
> contains repoinit scripts but is not whitelisted. And finally, an
> "ignore"-list of bundle symbolic names could allow suppressing the
> warning. The logging would draw a deployer's attention to the fact
> that a bundle embeds repoinit files and ideally prompt them to
> whitelist it or to add it to the ignore list. Even in the case of the
> ignore list, the deployer could extract the repoinit files and modify
> them.
>
> Any custom repoinit configurations could be deployed via OSGi installer.
>
> I am not fixed on either solution, but I would like _a_ way forward.
> I'd also be happy with "just" the repoinit installer factory.
>
> Regards
> Julian
>
> On Sat, Oct 24, 2020 at 5:46 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
> > On Saturday, October 24, 2020 4:33:56 PM CEST Julian Sedding wrote:
> > > Hi all
> >
> > Hi Julian,
> >
> > > I am working on "older" Sling setups that do not yet use the feature
> > > model to describe instances. Rather they leverage the OSGi Installer
> > > for deployment of bundles and configurations.
> > >
> > > Currently I am looking into using Repoinit for setting up
> > > Service-Users and ACLs, and possibly also paths and groups. The
> > > current implementation of the Repoinit JCR bundle allows setting up
> > > factory configurations with "scripts" and "references". Scripts are
> > > little (or not so little) snippets of Repoinit DSL, references are
> > > URLs to files containing Repoinit DSL. So far so good.
> > >
> > > For a maintainable setup, the Repoinit DSL should be checked into Git
> > > (or SCM of choice). However, as Dan already noticed in "SLING-9524 -
> > > Add Support for Bundle URL References", it is not currently possible
> > > to reference bundle resources in a stable fashion. This renders the
> > > "references" Configuration virtually useless (that may be too harsh,
> > > maybe I am missing something). The "scripts" configurations work, but
> > > they require the Repoinit DSL to be embedded in a configuration file,
> > > typically requiring escaping and all on one line.
> >
> > Until October 2017 Sling Karaf was using a dedicated bundle for repoinit
> > files which worked AFAIR quite well (see SLING-7177).
> > I also do not like the escaped one liners in JSON and will look into this
> > approach again.
> >
> > See also the very last diff entry in
> > https://github.com/apache/sling-org-apache-sling-karaf-configs/commit/f5d
> > 9b596e854e91e5f8fc81a575f89beb0082f62
> >
> > references=[\
> >
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt
> > ",\
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\
> > "raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\
> >
> > ]
> >
> > HTH,
> > O.
> >
> > > To improve the situation I have two suggestions.
> > >
> > > (1) Add support for a Bundle-Header (e.g. Sling-RepoInit) with a comma
> > > separated list of paths to bundle resources. This would allow
> > > embedding Repoinit Files into bundles, which could be useful for
> > > keeping service-users creation and bundles together. However, this
> > > solution would not lend itself to supplying runmode-specific Repoinit
> > > files. Of course the header could be extended to support a runmode
> > > qualifier, but to me at least it starts to feel a little wrong when
> > > bundles (i.e. code) have to know so much about runmodes (i.e.
> > > deployments).
> > >
> > > (2) Add OSGiInstaller support for Repoinit files. I.e. recognize files
> > > in "install" or "config" folders with a ".txt" extension that can be
> > > parsed by the RepoInitParser. This requires separate deployment, e.g.
> > > via a content-package. However, runmode support then comes out of the
> > > box.
> > >
> > > I could imagine adding one or both of these solutions to the Repoinit
> > > JCR bundle.
> > >
> > > Any thoughts on this? Are there any concerns regarding security or
> > > other objections?
> > >
> > > Thanks
> > > Julian
Re: Improving support for deploying Repoinit DSL files
Posted by Julian Sedding <js...@gmail.com>.
Hi
Thank you Oliver for the suggestion. I have attempted using the
"classpath" scheme as, but I get "java.lang.IllegalStateException:
Unknown protocol: classpath". Maybe Karaf has an additional URLHandler
for "classpath"?
Carsten Ziegeler wrote on SLING-9862
> I personally don't like the idea to have repoinit inside a bundle; so if we can
> come to a solution where no new header is introduced that's probably better.
> Today, you can install a feature, which references bundles, configurations
> and repoinit - which I think is a much more flexible way than having everything
> inside the code bundle. Users of your code might use different users, different
> content paths (if configurable) etc.
Unfortunately I am in no position to use the feature model. I am
looking for solutions on how to better leverage repoinit on older
Sling deployments (namely AEM 6.5 on-prem), where the OSGi installer
is still the main means for deployment. Or am I missing something and
it is possible to use the feature model for this?
My goal is finding a way to maintain repoinit files in a Git
Repository and have them applied to the instance upon deployment via
content-packages. The existing "RepositoryInitializerFactory"
configuration does not quite cut it, as I outlined previously in this
thread (mainly the "scripts" configs are not maintainable due to
required escaping within config files and "references" to bundle
resources are not predictable, see SLING-9524).
I think a bundle developer knows best which permissions a service user
requires. Therefore I see some value in allowing the bundle to
transport such information. However, I acknowledge that embedding such
information in the bundle could take away flexibility for deployments
to customize the setup. And as you mention, it _is_ possible to use a
different name for a service-user.
An alternative could be a repoinit installer factory for the OSGi
Installer. This would allow repoinit files to be deployed via
content-package, e.g. in an /apps/myapp/config folder.
Also a combination of the two could be worthwhile: the bundle-header
approach could be opt-in and guarded by a configuration that allows
whitelisting bundle symbolic names for which embedded repoinit scripts
should be deployed. A warning could be printed for any bundle that
contains repoinit scripts but is not whitelisted. And finally, an
"ignore"-list of bundle symbolic names could allow suppressing the
warning. The logging would draw a deployer's attention to the fact
that a bundle embeds repoinit files and ideally prompt them to
whitelist it or to add it to the ignore list. Even in the case of the
ignore list, the deployer could extract the repoinit files and modify
them.
Any custom repoinit configurations could be deployed via OSGi installer.
I am not fixed on either solution, but I would like _a_ way forward.
I'd also be happy with "just" the repoinit installer factory.
Regards
Julian
On Sat, Oct 24, 2020 at 5:46 PM Oliver Lietz <ap...@oliverlietz.de> wrote:
>
> On Saturday, October 24, 2020 4:33:56 PM CEST Julian Sedding wrote:
> > Hi all
>
> Hi Julian,
>
> > I am working on "older" Sling setups that do not yet use the feature
> > model to describe instances. Rather they leverage the OSGi Installer
> > for deployment of bundles and configurations.
> >
> > Currently I am looking into using Repoinit for setting up
> > Service-Users and ACLs, and possibly also paths and groups. The
> > current implementation of the Repoinit JCR bundle allows setting up
> > factory configurations with "scripts" and "references". Scripts are
> > little (or not so little) snippets of Repoinit DSL, references are
> > URLs to files containing Repoinit DSL. So far so good.
> >
> > For a maintainable setup, the Repoinit DSL should be checked into Git
> > (or SCM of choice). However, as Dan already noticed in "SLING-9524 -
> > Add Support for Bundle URL References", it is not currently possible
> > to reference bundle resources in a stable fashion. This renders the
> > "references" Configuration virtually useless (that may be too harsh,
> > maybe I am missing something). The "scripts" configurations work, but
> > they require the Repoinit DSL to be embedded in a configuration file,
> > typically requiring escaping and all on one line.
>
> Until October 2017 Sling Karaf was using a dedicated bundle for repoinit files
> which worked AFAIR quite well (see SLING-7177).
> I also do not like the escaped one liners in JSON and will look into this
> approach again.
>
> See also the very last diff entry in https://github.com/apache/sling-org-apache-sling-karaf-configs/commit/f5d9b596e854e91e5f8fc81a575f89beb0082f62
>
> references=[\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt",\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\
> "raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\
> ]
>
> HTH,
> O.
>
>
> > To improve the situation I have two suggestions.
> >
> > (1) Add support for a Bundle-Header (e.g. Sling-RepoInit) with a comma
> > separated list of paths to bundle resources. This would allow
> > embedding Repoinit Files into bundles, which could be useful for
> > keeping service-users creation and bundles together. However, this
> > solution would not lend itself to supplying runmode-specific Repoinit
> > files. Of course the header could be extended to support a runmode
> > qualifier, but to me at least it starts to feel a little wrong when
> > bundles (i.e. code) have to know so much about runmodes (i.e.
> > deployments).
> >
> > (2) Add OSGiInstaller support for Repoinit files. I.e. recognize files
> > in "install" or "config" folders with a ".txt" extension that can be
> > parsed by the RepoInitParser. This requires separate deployment, e.g.
> > via a content-package. However, runmode support then comes out of the
> > box.
> >
> > I could imagine adding one or both of these solutions to the Repoinit
> > JCR bundle.
> >
> > Any thoughts on this? Are there any concerns regarding security or
> > other objections?
> >
> > Thanks
> > Julian
>
>
>
>
Re: Improving support for deploying Repoinit DSL files
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Saturday, October 24, 2020 4:33:56 PM CEST Julian Sedding wrote:
> Hi all
Hi Julian,
> I am working on "older" Sling setups that do not yet use the feature
> model to describe instances. Rather they leverage the OSGi Installer
> for deployment of bundles and configurations.
>
> Currently I am looking into using Repoinit for setting up
> Service-Users and ACLs, and possibly also paths and groups. The
> current implementation of the Repoinit JCR bundle allows setting up
> factory configurations with "scripts" and "references". Scripts are
> little (or not so little) snippets of Repoinit DSL, references are
> URLs to files containing Repoinit DSL. So far so good.
>
> For a maintainable setup, the Repoinit DSL should be checked into Git
> (or SCM of choice). However, as Dan already noticed in "SLING-9524 -
> Add Support for Bundle URL References", it is not currently possible
> to reference bundle resources in a stable fashion. This renders the
> "references" Configuration virtually useless (that may be too harsh,
> maybe I am missing something). The "scripts" configurations work, but
> they require the Repoinit DSL to be embedded in a configuration file,
> typically requiring escaping and all on one line.
Until October 2017 Sling Karaf was using a dedicated bundle for repoinit files
which worked AFAIR quite well (see SLING-7177).
I also do not like the escaped one liners in JSON and will look into this
approach again.
See also the very last diff entry in https://github.com/apache/sling-org-apache-sling-karaf-configs/commit/f5d9b596e854e91e5f8fc81a575f89beb0082f62
references=[\
"raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\
"raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\
"raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\
"raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\
"raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt",\
"raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\
"raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\
"raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\
]
HTH,
O.
> To improve the situation I have two suggestions.
>
> (1) Add support for a Bundle-Header (e.g. Sling-RepoInit) with a comma
> separated list of paths to bundle resources. This would allow
> embedding Repoinit Files into bundles, which could be useful for
> keeping service-users creation and bundles together. However, this
> solution would not lend itself to supplying runmode-specific Repoinit
> files. Of course the header could be extended to support a runmode
> qualifier, but to me at least it starts to feel a little wrong when
> bundles (i.e. code) have to know so much about runmodes (i.e.
> deployments).
>
> (2) Add OSGiInstaller support for Repoinit files. I.e. recognize files
> in "install" or "config" folders with a ".txt" extension that can be
> parsed by the RepoInitParser. This requires separate deployment, e.g.
> via a content-package. However, runmode support then comes out of the
> box.
>
> I could imagine adding one or both of these solutions to the Repoinit
> JCR bundle.
>
> Any thoughts on this? Are there any concerns regarding security or
> other objections?
>
> Thanks
> Julian