commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: VFS and JNDI
Date Thu, 27 Feb 2003 00:56:09 GMT
Adam Murdoch wrote:

>> JNDI is bundled with JDK1.3+ and is available to JDK1.1. It is well
>> documented ( books, etc ), required ( or strongly supported ) in Servlet
>> environments. I could say it is ubiquous. I can hardly see any reason
>> why someone would use a different API to use a VFS.
> For the same reason you'd use a different API for anything: a better fit
> for the task, and a model that is a better match for the user's mental
> model.
> It's argueable whether the current VFS API achieves this over JNDI.  It
> largely comes down to personal preference, I think.  I certainly prefer
> the VFS API to JNDI for file access.  But I can understand how others
> prefer to use JNDI.  And I can picture cases where I'd rather use JNDI
> too.

For "user mental model" - learning a new  model is usually more painful than
applying a model you know. And most people are used with JNDI and with the 
"content + attributes". 

It is possible to add a wrapper on top of JNDI to provide (or emulate) a
different API if you want. There is one particular case that is not very
well covered by JNDI - random access to a file. That's where some special
extensions or API would be needed. 

> What I'd like to do is see if we can support both.  There's a few
> approaches
> we could take.  My preferred option is to do the interoperability at the
> provider level.  Something like this:

> - Move the provider agnostic stuff into a core framework.  This would
> provide services like caching, replication, event handling, federation,
> and so on. - Sit the framework on top of the providers, using a custom
> provider API (not the JNDI provider API).
> - Sit the VFS API on top of the framework.
> - Sit a JDNI provider adapter on top of the framework.

That is basically wasting the benefits of JNDI... 
- A well-defined standard for implementing providers. 
- ability to do caching/replication in a generic way, not specific to VFS
( a JNDI cache can be used for caching LDAP auth  results for example ).
- built-in event handling, federation, etc.

JNDI is an API - i.e. it provides all those things. 

> This pretty much reflects the current VFS architecture - the missing piece
> is
> the JDNI adapter.  The goal is to minimise the layering between the
> providers and the user API (be that JNDI or VFS), rather than sitting one
> API on top of
> the other.  I think with a bit of reorganising, we can end up with a
> reasonably performant VFS for both APIs.  I'd be willing to bias
> performance in favour of JNDI, if that were necessary.

The architecture of VFS seems close enough to JNDI - so why not use 
JNDI as the API ? 

Something like:
- refactor VFS providers to become JNDI providers
- create a VFS wrapper on top of JNDI - for backward compat and for people
who preffer to use VFS API
- all generic tools will be implemented using JNDI - this way they'll
be usefull in general JNDI, not only for VFS ( like deep copy of a JNDI
tree, replication, caching ). All this can be abolutely standalone
components ( if possible with ant wrappers :-)
- move the fs and cache from tomcat and merge. 

The only "framework" that is needed is a set of base classes and utils
to simplify the implementation of JNDI drivers. ( i.e. utils ).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message