commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [vfs] new dependencies
Date Mon, 17 May 2004 06:51:12 GMT
Mario Ivankovits wrote:

> If this might make a serious problem in your environment, please let 
> me know.

Received three misgivings - how bad :-(

Tim Reilly wrote:

>My personal thought on this is that 200+K is a lot. Is something like
>osjava's gj-xml sufficient?
No - digester is much more than just an xml-parser. It automates the 
process of reading the xml and build the necessary java object(s). xml 
attributes/element data is set on those using reflection.
Any change to the configuration file could easily be mapped to the 
according java object.

Paul Smith wrote:

>it does seem like a large dependancy just to parse a
>single configuration file.  Is it much work to modify the current parsing
>class to include the new element support?
For sure it might not be much work to modify the current parsing, but 
with every new option the code gets larger and larger, and every line of 
code is simple copy&past - with some minor modification so that it cant 
be reused.
My experience is to leave such a way of how the code goes as early as 
possible, as it is much more work if this is done if it is too late.

Anthony Goubard wrote:

> Note that it would increase the size of vfs from about 200K to 400K.

Those 200K you only have if you do not use any of the ftp,http,... 

> Is there a way to keep the old manual xml parsing even is not attached 
> to the code in case someone doesn't want ot use <globals> , he would 
> then need to change a bit of code and recompiles vfs.

Gotcha! This brings me back to the idea to how vfs works - try to see if 
a class is available and configure the system accordingly.

What do you think about making these dependencies optional.
If digester&beanutils are available, vfs will use them and you could use 
the new <globals> sections, else you are stick to the old parsing with 
their limitations (which might get more and more in the future).
In the case of "globals" it could be possible to set them from within 
the application as long as init() on the FilesystemManager wasnt called. 
If one use VFS.getInstance() then this might not be possible, but it is 
not much work to instanciate the StandardFilesystemManager directly instead.

To create really small distributions i recommend to have a look at a 
jar-builder which is able to find and jar only needet classes.

-- Mario

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

View raw message