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 <[email protected]> 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 <[email protected]> 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 > > > >
