[
https://issues.apache.org/jira/browse/SLING-5330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thierry Ygé updated SLING-5330:
-------------------------------
Attachment: sample_patch_improve_contentloaderservice.txt
sample patch to improve the ContentLoaderService API
that would eventually also solve the issue too.
One can create a test (test rule most likely) on serverside that then call the
ContentLoaderService via BundleHelper interface, and calling the method
installFromPath(...) which would then call internally the
BundleContentLoader.installFromPath(...) , it would then simply save the
session before returning to the calling test. The list of createdNode would be
filled up. The calling test code can decide to remove the nodes or leave it.
I have also testing this solution and it works too, the only difference is that
we need then here to update the contentloader bundle on our target instances.
cc [~bdelacretaz]
> add a method to include sling initial content rule in the generated manifest
> ----------------------------------------------------------------------------
>
> Key: SLING-5330
> URL: https://issues.apache.org/jira/browse/SLING-5330
> Project: Sling
> Issue Type: Improvement
> Components: Testing
> Affects Versions: JUnit Tests Teleporter 1.0.4
> Reporter: Thierry Ygé
> Attachments: sample_patch_improve_contentloaderservice.txt,
> teleporter_patch.txt
>
>
> As now with the latest improvement to include any resources in the generated
> bundle that is sent over with the ClientSideTeleporter (SLING-5294), we see
> that it could be also nice to include a method to define some
> Sling-Initial-Content value.
> I have tried to implement a simple solution, it works fine in my prototype,
> which I have based on the documentation
> (https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#loading-initial-content-from-bundles)
> Attached is a sample patch, with a junit test for the added class.
> It can then get used in a custom TeleporterRule.Customizer implemented in my
> test framework
> {code}
> public void customize(TeleporterRule teleporterRule, String s) {
> final ClientSideTeleporter cst = (ClientSideTeleporter) teleporterRule;
> CustomizerParameter params = new CustomizerParameter(s);
> for (PathImportOptions options : params.getWithContent()) {
> cst.addImportOption(options);
> }
> {code}
> In that example my customizer receive some parameter value, which it can
> extract the import options. Eventually if could be done at TeleportRule level
> it would be possible to include those with something like:
> {code}
> @Rule
> TeleporterRule teleporter = TeleporterRule.forClass(classUnderTest,
> "Launchpad").withResources("/my_resources/").withContent(myPathImportOptions);
> {code}
> Since I am not sure if this is something that is "generic" enough to be part
> of the TeleporterRule , I have only added it to the ClientSideTeleporter in
> my sample patch.
> Actually it could also be part of a custom implementation if SLING-5329 would
> be available. So that would reduce the required changes to resolve this
> requirement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
