jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tobias.bocane...@day.com>
Subject Re: Analyzing the Jackrabbit architecture
Date Tue, 10 Jan 2006 09:09:44 GMT
hi jukka,
i just thought again about your NodeId, PropertyId, ItemId refactoring
suggestions.
in your article you state:

[...]
Looking at the virtual core.B package we find that only the NodeId, PropertyId,
and ItemId classes depend on the state package:
[...]

i think, it is vice versa. the classes in the state package depend on
the *Id classes. those classes are used widely in jackrabbit as
identifying objects for the actual items or item states. internally,
the path is used seldomly for that purpose. thinking about a possible
jackrabbit API, the *Id classes certainly should be a part of it. For
example the o.a.j.core.security.AccessManager, which could be seen as
part of the 'API' or 'SPI', makes use of those, an so do the
persistence managers.

as for the API (and/or a possible jcr-283 extension) we could get rid
of the very loosly defined UUID of type String and probably introduce
the NodeId, PropertyId, ItemId and make it part of the jcr API. i
would love to have:
Session.getNode(NodeId id) and Node.getId()

so if i would need to move the *Id classes, i would put them to
org.apache.jackrabbit.* and make them part of the (yet non-existent
:-) API.

regards, toby

On 1/9/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 1/9/06, Tobias Bocanegra <tobias.bocanegra@day.com> wrote:
> > - Split the main core package into subpackages
> > that certainly makes sense, but by what semantics?
>
> Good question, I didn't really focus on that very much. It seems that
> at least the hierarchy and namespace stuff could quite easily be moved
> to a separate package (or two) as a somewhat coherent set of classes.
>
> > - Move the nodetype.virtual package to a higher level
> > we could put those into the oaj.core.virtual package. btw: there are
> > plans to remove the virtual states completely and add a more
> > sophisticated approach.
>
> OK, then I think we could leave it as is for now.
>
> > - Move the state subpackages to a separate package
> > as far as i can tell, most of the state subpackages are implementation
> > of persistencemanagers. so i suggest to create a
> > oaj.core.persistencemgr package.
>
> Sounds good. The persistence manager concept is a pretty visible one,
> so moving the PersistenceManager interface and the implementation
> packages to a dedicated package could clarify things.
>
> Currently there are troublesome dependencies from PersistenceManager
> to the Id classes in o.a.j.core and from the SharedItemStateManager to
> PersistenceManager. Moving the Id classes to o.a.j.core.state and the
> item state managers to a new package would clean these up quite
> nicely, making this part of the dependency structure linear: statemgr
> -> persistencemgr -> state.
>
> > - Make a separate package for the item state managers
> > that would be: oaj.core.statemgr  ?
>
> Sounds good.
>
> PS. I was contacted by Neeraj Sangal from Lattix and he's also taking
> a look at Jackrabbit architecture. I'll report back when I get more
> feedback from him.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftmanship, JCR consulting, and Java development
>


--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message