geronimo-dev mailing list archives

I've been reviewing the Wiki discussions on looking for a JNDI
implementation. There are several places where it looks like various
levels of JNDI support are desired or at least being considered - of
course some places where it's required as well.
I'd like to propose a high-level design/architecural model for a
consistent JNDI implementation within the Geronimo framework. This
email is fairly large, but I wasn't sure exactly how to float this
idea. To keep it as short as possible, I've quickly summarized the four
main points of the model. I open these for comment and suggestion.
Specification Support: at the highest level, we would determine what
constructs of the specification we want to support. The end goal would
be for complete implementation, but, for example, issues like federation
support may be lower priority items and held off for later releases.
Persistence Layer: a consistent interface for interacting with various
persistence mechanisms when desired.
Caching Layer: an interface that sits on top of a persistance layer, if
desired. Issues to consider would be write-thru, delayed write, etc.
Distributed Layer: an interface that coordinates a distributed JNDI
hierarchy. It would work in conjunction with the persistence and
caching layers.
Data Access Layer: presents a consistent interface to the classes
implementing the specification shielding them from the persistence,
caching and distributed layers.
Under the covers, some or all of these layers may use some existing
componentry, frameworks or subsystems that supply the desired
functionality. The key would be to define the interface and interaction
in such a way that it is pluggable.
I have looked through some of the existing implementations discussed in
the Wiki and there may some value in "mining" them or bringing them
together into a single implementation under this construct.
Is is too soon to start looking at this stuff? I'm willing to begin
working on it or just continue the discussion if a decision is made to
pursue it further.
Thanks,
Ray Elenteny