You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2006/01/07 15:51:18 UTC
Analyzing the Jackrabbit architecture
Hi,
I just spent a few hours playing with Lattix LDM, a tool for analyzing
software architecture. I used Jackrabbit as the example project and
managed to find a few ideas for possible improvements. The ideas and
details of the analysis (including pictures :-) can be found at:
http://jukkaz.wordpress.com/2006/01/07/analyzing-the-jackrabbit-architecture-with-lattix-ldm/
Of course a tool like that doesn't really understand the semantics of
the analyzed code, so the results should be taken with a grain of
salt. In any case this analysis could provide some good ideas and food
for further thought.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftmanship, JCR consulting, and Java development
Re: Analyzing the Jackrabbit architecture
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 1/10/06, Tobias Bocanegra <to...@day.com> wrote:
> i think, it is vice versa. the classes in the state package depend on
> the *Id classes.
Ah, my mistake, I got the directions mixed up. The problem (the state
-> core dependency, caused in part by the *Id classes) is the same
though.
> 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.
Sounds good.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftmanship, JCR consulting, and Java development
Re: Analyzing the Jackrabbit architecture
Posted by Tobias Bocanegra <to...@day.com>.
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 <ju...@gmail.com> wrote:
> Hi,
>
> On 1/9/06, Tobias Bocanegra <to...@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 >---
Re: Analyzing the Jackrabbit architecture
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 1/9/06, Tobias Bocanegra <to...@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
Re: Analyzing the Jackrabbit architecture
Posted by Tobias Bocanegra <to...@day.com>.
that looks cool. thanks for taking the time. some comments to your suggestions:
- Split the main core package into subpackages
that certainly makes sense, but by what semantics?
- 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.
- 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.
- Make a separate package for the item state managers
that would be: oaj.core.statemgr ?
- Move the NodeId, PropertyId, and ItemId classes to the state package
totally makes sense.
regards, toby
--
-----------------------------------------< 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 >---