Are you going to replace DirContext ? If yes - great, but please first send a quick summary comparing your API with the other VFS around in apache. I think commons has few targets, including a hdfs, I remember there are more.
If no - not sure what's the point of replacing java.io impl, I assume you just need to add a DirContext for hadoop. I remember many years back I was arguing in favor of DirContext - pro arguments were "it's a standard", bundled in JDK, probably more target implementations will be available, etc. I think Remy was arguing that it's too complex and not a perfect fit. I guess he was right :-) Costin On Fri, Oct 15, 2010 at 12:02 AM, Mladen Turk <mt...@apache.org> wrote: > Hi, > > > I'm working for quite some time on the light-weight > VFS layer (with the java.io.* as the only provider at > the moment) to be used as the Tomcat's physical file > system access. The ultimate goal is to be able to run > the Tomcat on top of things like Hadoop or similar distributed > file systems (eg. GFS) by just using the provider module. > > Now, the amount of changes is pretty huge but it involves > mostly changing the java.io.* with the o.a.t.vfs.* > counterparts. > Since this "Pseudo VFS" has exactly the same API > (with the Java7 additions), no functional code change is needed. > Sure there are some additional config directives used > to define which parts are using which vfs provider as default. > (or by just using the > root="file://web/apps" or hdfs://<host>:<port>/web/apps > notion for non-clustered environments) > > I'd like to create a sandbox project for that > (was thinking of /sandbox/tomcat-vfs) > > Comments? > > > Regards > -- > ^TM > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
