You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (Created) (JIRA)" <ji...@apache.org> on 2012/01/27 17:46:10 UTC
[jira] [Created] (JCR-3224) SystemSession#createSession should
return SessionImpl again
SystemSession#createSession should return SessionImpl again
-----------------------------------------------------------
Key: JCR-3224
URL: https://issues.apache.org/jira/browse/JCR-3224
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Reporter: angela
a long with the fix of JCR-2890 (revision 1089436) the behavior of SystemSession#createSession has changed to
return a SystemSession instead of SessionImpl as it used to be.
while i basically consider this move to be correct and the better way of dealing with that session-cloning
mechanism as it prevents the user of this method to convert a SystemSession into a regular session
for extra writing operations (such as e.g. access control editing that is not supported with the
system session to prevent chicken-egg-problems on repo startup).
therefore i would like to revert that change for the 2.4 release in order to prevent regressions.
for the time after 2.4 i would however suggest that we finally take the time to clearly define the
usages, abilities and responsibilities of the system session and also review how and where we
expose them to the individual 'modules' of jackrabbit core.. i started working on this but decided
that this is definitely too risky for 2.4 whereas reverting the change mentioned above should
imo impose very limited risk as all usages of those sessions i am aware of use them as "Session"
or "SesssionImpl", most of them not even having access to the SystemSession class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (JCR-3224) SystemSession#createSession should
return SessionImpl again
Posted by "angela (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela reassigned JCR-3224:
---------------------------
Assignee: angela
> SystemSession#createSession should return SessionImpl again
> -----------------------------------------------------------
>
> Key: JCR-3224
> URL: https://issues.apache.org/jira/browse/JCR-3224
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: angela
> Assignee: angela
> Fix For: 2.4
>
>
> a long with the fix of JCR-2890 (revision 1089436) the behavior of SystemSession#createSession has changed to
> return a SystemSession instead of SessionImpl as it used to be.
> while i basically consider this move to be correct and the better way of dealing with that session-cloning
> mechanism as it prevents the user of this method to convert a SystemSession into a regular session
> for extra writing operations (such as e.g. access control editing that is not supported with the
> system session to prevent chicken-egg-problems on repo startup).
> therefore i would like to revert that change for the 2.4 release in order to prevent regressions.
> for the time after 2.4 i would however suggest that we finally take the time to clearly define the
> usages, abilities and responsibilities of the system session and also review how and where we
> expose them to the individual 'modules' of jackrabbit core.. i started working on this but decided
> that this is definitely too risky for 2.4 whereas reverting the change mentioned above should
> imo impose very limited risk as all usages of those sessions i am aware of use them as "Session"
> or "SesssionImpl", most of them not even having access to the SystemSession class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3224) SystemSession#createSession should
return SessionImpl again
Posted by "angela (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved JCR-3224.
-------------------------
Resolution: Fixed
> SystemSession#createSession should return SessionImpl again
> -----------------------------------------------------------
>
> Key: JCR-3224
> URL: https://issues.apache.org/jira/browse/JCR-3224
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: angela
> Assignee: angela
> Fix For: 2.4
>
>
> a long with the fix of JCR-2890 (revision 1089436) the behavior of SystemSession#createSession has changed to
> return a SystemSession instead of SessionImpl as it used to be.
> while i basically consider this move to be correct and the better way of dealing with that session-cloning
> mechanism as it prevents the user of this method to convert a SystemSession into a regular session
> for extra writing operations (such as e.g. access control editing that is not supported with the
> system session to prevent chicken-egg-problems on repo startup).
> therefore i would like to revert that change for the 2.4 release in order to prevent regressions.
> for the time after 2.4 i would however suggest that we finally take the time to clearly define the
> usages, abilities and responsibilities of the system session and also review how and where we
> expose them to the individual 'modules' of jackrabbit core.. i started working on this but decided
> that this is definitely too risky for 2.4 whereas reverting the change mentioned above should
> imo impose very limited risk as all usages of those sessions i am aware of use them as "Session"
> or "SesssionImpl", most of them not even having access to the SystemSession class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3224) SystemSession#createSession should
return SessionImpl again
Posted by "angela (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-3224:
------------------------
Fix Version/s: 2.4
> SystemSession#createSession should return SessionImpl again
> -----------------------------------------------------------
>
> Key: JCR-3224
> URL: https://issues.apache.org/jira/browse/JCR-3224
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: angela
> Assignee: angela
> Fix For: 2.4
>
>
> a long with the fix of JCR-2890 (revision 1089436) the behavior of SystemSession#createSession has changed to
> return a SystemSession instead of SessionImpl as it used to be.
> while i basically consider this move to be correct and the better way of dealing with that session-cloning
> mechanism as it prevents the user of this method to convert a SystemSession into a regular session
> for extra writing operations (such as e.g. access control editing that is not supported with the
> system session to prevent chicken-egg-problems on repo startup).
> therefore i would like to revert that change for the 2.4 release in order to prevent regressions.
> for the time after 2.4 i would however suggest that we finally take the time to clearly define the
> usages, abilities and responsibilities of the system session and also review how and where we
> expose them to the individual 'modules' of jackrabbit core.. i started working on this but decided
> that this is definitely too risky for 2.4 whereas reverting the change mentioned above should
> imo impose very limited risk as all usages of those sessions i am aware of use them as "Session"
> or "SesssionImpl", most of them not even having access to the SystemSession class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira