Hi,
As a part of my work on JCR-890, I'm planning to move most of the
session-related classes from o.a.j.core to a new o.a.j.core.session
package. This will make it easier to review and control related
dependencies and code paths, and to ultimately guard them against
access from concurrent
Hi,
I'm not sure if this will help more than it will complicate things.
Disadvantages:
- Isn't almost every class at in o.a.j.core at least somewhat session related?
- If you move classes to other packages, you will have to make many
method public.
Instead of moving session related classes to
Hi,
On Mon, May 17, 2010 at 11:00 AM, Thomas Müller thomas.muel...@day.com wrote:
- If you move classes to other packages, you will have to make many
method public.
My ultimate goal is to track down all these cases and refactor them
away so we can better control all the code paths to and from
Stefan Guggisberg wrote:
i share tomas's concerns.
so do i... in addition i have quite some changes
pending (JCR-2573, JCR-2629), which are not yet ready for commit.
UserPerWorkspaceSecurityManager
(security), DefaultSecurityManager (security),
that doesn't work without major changes.
Hi,
These unrelated classes are mostly things like RepositoryImpl,
TransientRepository, RepositoryCopier, etc. to which many external
codebases are linking, so we can't move them.
SessionImpl is used in my applications as well.
RepositoryImpl,
TransientRepository
I don't think those
On Mon, May 17, 2010 at 10:16 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
These unrelated classes are mostly things like RepositoryImpl,
TransientRepository, RepositoryCopier, etc. to which many external
codebases are linking, so we can't move them.
All class inside core has possible
Hi,
On Mon, May 17, 2010 at 11:34 AM, Thomas Müller thomas.muel...@day.com wrote:
These unrelated classes are mostly things like RepositoryImpl,
TransientRepository, RepositoryCopier, etc. to which many external
codebases are linking, so we can't move them.
SessionImpl is used in my
Hi,
As far as I understand, you want to move the classes so we can add
checkstyle / PMD constraints, and more easily ensure every method call
from an external class is synchronized. I think that's fine.
Having the 'proxy' classes sounds like a solution for the backward
compatibility concerns
Hi,
On Mon, May 17, 2010 at 10:43 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Unless there's a need to wait, I'm planning to commit the changes in
the afternoon today.
This obviously needs more time than I anticipated. I'm sorry about the rush.
I'll prepare a patch and outline the steps
Hi,
On Mon, May 17, 2010 at 3:05 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
I'll prepare a patch and outline the steps by which I plan to address
the issues raised here. I'll commit the changes only when everyone is
happy with the approach.
See JCR-890 for the proposed patch and a more
10 matches
Mail list logo
