Paul Smith wrote:
Yeah, that might work. If the current xml parsing code can deal with theOK, no new dependencies, leave it to the client code to configure the system as needet.
default xml file included in the dist that is accessed via the
VFS.getInstance() method, then if they need to load their own custom xml
file they could load it them selves... Perhaps that's the answer, don't
even bother making digester/beanutils an optional dependancy, if the default
instance of FileSystemManager is not enough to meet you're needs, then just
require the config object to be loaded by the client code, and leave it up
to the client code to 'digest' their own custom xml file into the config
object.
I we decide to go this way, this brings me to another question - why not drop providers.xml at all.
We could save 100KB if we avoid the dependency of xml-apis (which might in fact only be needet if one use jdk <= 1.2 ?)
What if we put the providers.xml into some easily derivatable (is this the right word?) code?
The con of this might be to have ONE way how to configure vfs - no need to confuse the user to use providers.xml to configure the possible filesystems and to force them to use client-code to configure other aspects of vfs.
Has anyone of changed the providers.xml and - if so - dont want to do this in code?
-- Mario
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
