> That there has to be a local filesystem is a invalid premise. That this is
> required for
> deployment currently is a criticism of our deployment mechanism, not a
> justification for requiring a filesystem. We need to be able to run
> configurations
> of JBoss in environments where there is no fileystem(embedded systems,
> firewalls,
> other restricted systems, J2ME, etc.). Sure some services will require a
> filesystem,
> but this is no different from a service that requires JNDI or JMS.
Lets not fall into the trap Sun did with Java and *limit* the API based on
what plafroms do not support.
I agree that JNDI is a good choice for look up of such resources, but it is
clear that the java.io.File crap is not sufficent for robust file
system access.
Some thing like the NetBeans FileSystem API:
http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/api.html
Not that I have looked into it much, but the concept is solid. Map a fs to
a cvs repo, a website (read-only|put, read-write|get&put)...
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
