Hi,
On Mon, May 17, 2010 at 3:05 PM, Jukka Zitting 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 detailed explanation
Hi,
On Mon, May 17, 2010 at 10:43 AM, Jukka Zitting 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 by which I plan to add
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 (not
Hi,
On Mon, May 17, 2010 at 11:34 AM, Thomas Müller 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 applications as well.
On Mon, May 17, 2010 at 10:16 AM, Jukka Zitting 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 reference for user code ba
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 s
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.
th
Hi,
On Mon, May 17, 2010 at 11:00 AM, Thomas Müller 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 a single
session. By
On Mon, May 17, 2010 at 11:00 AM, Thomas Müller wrote:
> 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 mak
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 a
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 threads
11 matches
Mail list logo
