[
https://issues.apache.org/jira/browse/SLING-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15769483#comment-15769483
]
Timothee Maret commented on SLING-4753:
---------------------------------------
bq. the longer I think about it, the longer I have the impression, that this
change should be reverted.
[~amitgupt], [~fmeschbe] I think that keeping the pre-{{r1681937}} behaviour
makes sense for the reasons [~fmeschbe] mentioned and because the
{{o.a.s.t.s.TenantCustomizer}} is deprecated in favour of
{{o.a.s.t.s.TenantManagerHook}} which does not pass the resolver through the
spi (and then the pre-tenant-customizer-commit does not make sense anymore).
A pragmatic approach may be to allow configuring this pre-commit behaviour and
have it disabled (no pre-commit) by default.
bq. Do we really close issues before a release has been cut ?
As far as I understand from [0] and looking current running releases, issues
are {{Resolved Fixed}} before cutting the release and {{Closed Fixed}} once the
release has been cut. I mistakenly wrote {{close}} when I meant {{resolve}}.
[0]
https://sling.apache.org/documentation/development/release-management.html#update-jira
> Commit the Resource Resolver before passing it to Tenant Customizers for
> setting up their own customizations
> ------------------------------------------------------------------------------------------------------------
>
> Key: SLING-4753
> URL: https://issues.apache.org/jira/browse/SLING-4753
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Tenant 1.1.0
> Reporter: Agraj Mangal
> Assignee: Amit Gupta
> Fix For: Tenant 1.1.0
>
>
> We should commit the Resource Resolver after creating the Tenant Resource and
> before passing it on to the Tenant Customizers.
> One possible issue is that one of the Tenant Customizers calls some APIs like
> PageManager##createPage that does a session.refresh() and rollbacks all the
> un-committed changes on the resolver so far. That could also include the
> tenant resource itself.
> Ideally the TenantCustomizers should not call commit on the resolver and let
> TenantProvider commit the changes, but it would be a good protection against
> all such cases where we could prevent the tenant resource from getting
> modified if the TenantCustomizer failed and tried to refresh the session.
> We are experiencing this issue in
> https://jira.corp.adobe.com/browse/MAC-25410
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
